Foundry service catalog

Designing of a catalog & data model to drive utilization of Ginkgo’s platform

Design challenge

A platform to offer and request scientific services

  • Ginkgo runs R&D projects for customers
  • Project work gets distributed across teams of specialized and generalized scientists
  • Generalized teams often request work from specialized teams
  • We call these work units “services”

Scientists didn’t have a single place to go and learn about the resources available to them

From past user research, I learned:

  • It was impossible to know how many scientific services existed (across all the teams)
  • It was difficult to find out what any service actually does
  • Services had playful names that weren’t descriptive, making it difficult to tell them apart
  • Most service documentation was written by specialized scientists and required too much background knowledge to understand

How might we catalog scientific services with an eye towards increasing the utilization of Ginkgo’s platform?

  • We heard rumors that teams were opting to go “DIY” and not use other team’s services
  • These rumors were concerning because it defeated the purpose of Ginkgo’s scale economics business model, and made some projects more expensive to run

Actions taken

  1. Generative workshop
  2. Vision concepts
  3. Concept testing & synthesis
  4. Card sort study
  5. Dashboard design

I organized and facilitated a workshop

  • This project wasn’t an assignment, I had a big idea for Ginkgo so I set off to explore it
  • I started with a workshop as a lightweight, low risk way to get ideas flowing

Workshop activities

I used the book Gamestorming to quickly put together a workshop agenda. For the most part I ran each activity “by the book.” I chose the following activities based on my learning goals:

  • Open card sort - I printed cards with the names of as many services as I could find. I instructed the team to sort the cards into groups and label each group
  • Empathy map - I had the team make empathy maps for several key stakeholder groups
  • Atomize - I challenged the team to take a single service and break it down into it’s atomic components

Workshop participants

  • 2 scientists
  • 2 software developers
  • 1 engineering manager
  • 1 product manager

Leading a workshop activity

The workshop uncovered several unmet needs, I was keen to translate our ideas into a concept vision

  • The workshop team came up with an innovative way to categorize services
  • I wanted to get their idea onto paper and in front of users as quickly as possible
  • I mocked up a “menu” of services, incorporating a number of ideas from the workshop activities
  • At the time, the idea of shopping for services was a novel concept to many groups of stakeholders

Concept art I shared for user feedback

I showed the concept menu to our target scientific users

  • I printed out the concept menu and made it into a booklet
  • I wrote an interview guide designed to uncover how teams work with each other
  • I gave each participant a marker and encouraged them to write on the menu as they answered questions
  • I took notes during each session, synthesized the data, and wrote a report

I learned the scientists didn’t have enough info to find the services they needed

  • They said it was difficult to locate information and choose the right service, it was often easier to just do the work themselves
  • They had a hard time keeping track of all the available services
  • New employees struggled most, it could take months before they felt comfortable collaborating with other teams

I advocated for the research findings and secured resources to keep working on the problem

  • I brought the research findings to the Product team and secured time on the quarterly roadmap
  • I worked with scientific leadership to establish KPIs we could hold ourselves accountable to
  • I advocated for adoption-based KPIs because the product wouldn’t deliver value unless people chose to use it
  • At this point I felt confident in the product market fit and wanted to push the concept forward

We needed an information architecture for the catalog

  • I knew the effectiveness of the catalog would hinge on how well it was organized
  • Information architecture would be key to the success of this new product
  • The workshop uncovered a handful of categories I could use as a starting point

I ran a closed card sort study

  • I included 37 cards sorted into 10 pre-determined categories (categories came from the workshop)
  • Each card contained the name of 1 service
  • I recruited 10 participants (scientists across a mix of teams)
  • Sorting was done digitally using Mural - I gave each participant their own white board with the cards and categories, they had 1 hour to sort
  • I exported each whiteboard as a CSV, cleaned the data, and joined into a single spreadsheet
  • I imported the spreadsheet into Tableau and plotted a heat map

Results from the card sort study

The card sort gave me the insights I needed to move forward

  • The card sort resulted in a number of categories I could confidently build a design upon
  • Other categories were still rough around the edges, however I felt the best way forward was to build a functional prototype and populate it with real data

Quotes from the study:

  • "I didn't know we have this" 
  • "Sequencing makes more sense than sequence strains"
  • "Characterize a sample… that seems sufficiently vague"
  • "I honestly don't know where the protein stuff is gonna go"
  • "Design a protein... does that mean design DNA?"

I made a functional catalog prototype and asked science teams to fill out the content

  • I worked with the Data team to set up an easy way for scientists to start populating data
  • I wrote guidelines on best practices for filling out the catalog information. The best practices were inspired by insights gleaned from prior rounds of user feedback
  • I worked with Ginkgo’s science leaders to encourage their teams to populate the new catalog. Once the leadership team was bought in, it was easy to convince scientists to populate the dashboard

Functional prototype dashboard

Outcomes

The dashboard was a cheap solution with an outsized impact

  • The dashboard used existing Ginkgo tooling and required almost zero engineering resources
  • The dashboard gave users access to info that was never written down in a single place
  • Prior to having a catalog, they used to track down this information via Slack and team meetings
  • I was invited to share the dashboard to the entire company at a town hall meeting which generated lots of excitement from both scientists and c-suite leadership

We hit our target KPIs for catalog adoption

  • I had previously worked with Ginkgo’s leadership to establish target KPIs for catalog adoption
  • One KPI measured percent of information filled out - we knocked this one out of the park thanks to the collaborative working relationship I established with scientific leaders
  • Our other KPI measured page views - we also hit this target. However, spiky traffic indicated a need for more awareness building through Product Management support

I handed off the catalog to a dedicated product owner

  • This project started off as a self-driven “side quest”. Nobody asked me to do it, but user research highlighted an unmet need so I secured the resources to solve the problem
  • The catalog eventually grew into more than a “side quest” and required a dedicated owner to ensure continued maintenance and adoption
  • Luckily, a product manager from a science team was eager to take over the catalog and grow the product
  • She has since integrated the catalog with other data sources and made further user-facing improvements
  • Today the catalog is widely considered an indispensable source of information at Ginkgo
  • I firmly believe the product worked because it’s creation was grounded in human centered design practices
Darek Bittner

Next case study

Foundry service catalog

Designing of a catalog & data model to drive utilization of Ginkgo’s platform

Design challenge

A platform to offer and request scientific services

  • Ginkgo runs R&D projects for customers
  • Project work gets distributed across teams of specialized and generalized scientists
  • Generalized teams often request work from specialized teams
  • We call these work units “services”

Scientists didn’t have a single place to go and learn about the resources available to them

From past user research, I learned:

  • It was impossible to know how many scientific services existed (across all the teams)
  • It was difficult to find out what any service actually does
  • Services had playful names that weren’t descriptive, making it difficult to tell them apart
  • Most service documentation was written by specialized scientists and required too much background knowledge to understand

How might we catalog scientific services with an eye towards increasing the utilization of Ginkgo’s platform?

  • We heard rumors that teams were opting to go “DIY” and not use other team’s services
  • These rumors were concerning because it defeated the purpose of Ginkgo’s scale economics business model, and made some projects more expensive to run

Actions taken

  1. Generative workshop
  2. Vision concepts
  3. Concept testing & synthesis
  4. Card sort study
  5. Dashboard design

I organized and facilitated a workshop

  • This project wasn’t an assignment, I had a big idea for Ginkgo so I set off to explore it
  • I started with a workshop as a lightweight, low risk way to get ideas flowing

Workshop activities

I used the book Gamestorming to quickly put together a workshop agenda. For the most part I ran each activity “by the book.” I chose the following activities based on my learning goals:

  • Open card sort - I printed cards with the names of as many services as I could find. I instructed the team to sort the cards into groups and label each group
  • Empathy map - I had the team make empathy maps for several key stakeholder groups
  • Atomize - I challenged the team to take a single service and break it down into it’s atomic components

Workshop participants

  • 2 scientists
  • 2 software developers
  • 1 engineering manager
  • 1 product manager

Leading a workshop activity

The workshop uncovered several unmet needs, I was keen to translate our ideas into a concept vision

  • The workshop team came up with an innovative way to categorize services
  • I wanted to get their idea onto paper and in front of users as quickly as possible
  • I mocked up a “menu” of services, incorporating a number of ideas from the workshop activities
  • At the time, the idea of shopping for services was a novel concept to many groups of stakeholders

Concept art I shared for user feedback

I showed the concept menu to our target scientific users

  • I printed out the concept menu and made it into a booklet
  • I wrote an interview guide designed to uncover how teams work with each other
  • I gave each participant a marker and encouraged them to write on the menu as they answered questions
  • I took notes during each session, synthesized the data, and wrote a report

I learned the scientists didn’t have enough info to find the services they needed

  • They said it was difficult to locate information and choose the right service, it was often easier to just do the work themselves
  • They had a hard time keeping track of all the available services
  • New employees struggled most, it could take months before they felt comfortable collaborating with other teams

I advocated for the research findings and secured resources to keep working on the problem

  • I brought the research findings to the Product team and secured time on the quarterly roadmap
  • I worked with scientific leadership to establish KPIs we could hold ourselves accountable to
  • I advocated for adoption-based KPIs because the product wouldn’t deliver value unless people chose to use it
  • At this point I felt confident in the product market fit and wanted to push the concept forward

We needed an information architecture for the catalog

  • I knew the effectiveness of the catalog would hinge on how well it was organized
  • Information architecture would be key to the success of this new product
  • The workshop uncovered a handful of categories I could use as a starting point

I ran a closed card sort study

  • I included 37 cards sorted into 10 pre-determined categories (categories came from the workshop)
  • Each card contained the name of 1 service
  • I recruited 10 participants (scientists across a mix of teams)
  • Sorting was done digitally using Mural - I gave each participant their own white board with the cards and categories, they had 1 hour to sort
  • I exported each whiteboard as a CSV, cleaned the data, and joined into a single spreadsheet
  • I imported the spreadsheet into Tableau and plotted a heat map

Results from the card sort study

The card sort gave me the insights I needed to move forward

  • The card sort resulted in a number of categories I could confidently build a design upon
  • Other categories were still rough around the edges, however I felt the best way forward was to build a functional prototype and populate it with real data

Quotes from the study:

  • "I didn't know we have this" 
  • "Sequencing makes more sense than sequence strains"
  • "Characterize a sample… that seems sufficiently vague"
  • "I honestly don't know where the protein stuff is gonna go"
  • "Design a protein... does that mean design DNA?"

I made a functional catalog prototype and asked science teams to fill out the content

  • I worked with the Data team to set up an easy way for scientists to start populating data
  • I wrote guidelines on best practices for filling out the catalog information. The best practices were inspired by insights gleaned from prior rounds of user feedback
  • I worked with Ginkgo’s science leaders to encourage their teams to populate the new catalog. Once the leadership team was bought in, it was easy to convince scientists to populate the dashboard

Functional prototype dashboard

Outcomes

The dashboard was a cheap solution with an outsized impact

  • The dashboard used existing Ginkgo tooling and required almost zero engineering resources
  • The dashboard gave users access to info that was never written down in a single place
  • Prior to having a catalog, they used to track down this information via Slack and team meetings
  • I was invited to share the dashboard to the entire company at a town hall meeting which generated lots of excitement from both scientists and c-suite leadership

We hit our target KPIs for catalog adoption

  • I had previously worked with Ginkgo’s leadership to establish target KPIs for catalog adoption
  • One KPI measured percent of information filled out - we knocked this one out of the park thanks to the collaborative working relationship I established with scientific leaders
  • Our other KPI measured page views - we also hit this target. However, spiky traffic indicated a need for more awareness building through Product Management support

I handed off the catalog to a dedicated product owner

  • This project started off as a self-driven “side quest”. Nobody asked me to do it, but user research highlighted an unmet need so I secured the resources to solve the problem
  • The catalog eventually grew into more than a “side quest” and required a dedicated owner to ensure continued maintenance and adoption
  • Luckily, a product manager from a science team was eager to take over the catalog and grow the product
  • She has since integrated the catalog with other data sources and made further user-facing improvements
  • Today the catalog is widely considered an indispensable source of information at Ginkgo
  • I firmly believe the product worked because it’s creation was grounded in human centered design practices
Darek Bittner

Next case study

Foundry service catalog

Designing of a catalog & data model to drive utilization of Ginkgo’s platform

Design challenge

A platform to offer and request scientific services

  • Ginkgo runs R&D projects for customers
  • Project work gets distributed across teams of specialized and generalized scientists
  • Generalized teams often request work from specialized teams
  • We call these work units “services”

Scientists didn’t have a single place to go and learn about the resources available to them

From past user research, I learned:

  • It was impossible to know how many scientific services existed (across all the teams)
  • It was difficult to find out what any service actually does
  • Services had playful names that weren’t descriptive, making it difficult to tell them apart
  • Most service documentation was written by specialized scientists and required too much background knowledge to understand

How might we catalog scientific services with an eye towards increasing the utilization of Ginkgo’s platform?

  • We heard rumors that teams were opting to go “DIY” and not use other team’s services
  • These rumors were concerning because it defeated the purpose of Ginkgo’s scale economics business model, and made some projects more expensive to run

Actions taken

  1. Generative workshop
  2. Vision concepts
  3. Concept testing & synthesis
  4. Card sort study
  5. Dashboard design

I organized and facilitated a workshop

  • This project wasn’t an assignment, I had a big idea for Ginkgo so I set off to explore it
  • I started with a workshop as a lightweight, low risk way to get ideas flowing

Workshop activities

I used the book Gamestorming to quickly put together a workshop agenda. For the most part I ran each activity “by the book.” I chose the following activities based on my learning goals:

  • Open card sort - I printed cards with the names of as many services as I could find. I instructed the team to sort the cards into groups and label each group
  • Empathy map - I had the team make empathy maps for several key stakeholder groups
  • Atomize - I challenged the team to take a single service and break it down into it’s atomic components

Workshop participants

  • 2 scientists
  • 2 software developers
  • 1 engineering manager
  • 1 product manager

Leading a workshop activity

The workshop uncovered several unmet needs, I was keen to translate our ideas into a concept vision

  • The workshop team came up with an innovative way to categorize services
  • I wanted to get their idea onto paper and in front of users as quickly as possible
  • I mocked up a “menu” of services, incorporating a number of ideas from the workshop activities
  • At the time, the idea of shopping for services was a novel concept to many groups of stakeholders

Concept art I shared for user feedback

I showed the concept menu to our target scientific users

  • I printed out the concept menu and made it into a booklet
  • I wrote an interview guide designed to uncover how teams work with each other
  • I gave each participant a marker and encouraged them to write on the menu as they answered questions
  • I took notes during each session, synthesized the data, and wrote a report

I learned the scientists didn’t have enough info to find the services they needed

  • They said it was difficult to locate information and choose the right service, it was often easier to just do the work themselves
  • They had a hard time keeping track of all the available services
  • New employees struggled most, it could take months before they felt comfortable collaborating with other teams

I advocated for the research findings and secured resources to keep working on the problem

  • I brought the research findings to the Product team and secured time on the quarterly roadmap
  • I worked with scientific leadership to establish KPIs we could hold ourselves accountable to
  • I advocated for adoption-based KPIs because the product wouldn’t deliver value unless people chose to use it
  • At this point I felt confident in the product market fit and wanted to push the concept forward

We needed an information architecture for the catalog

  • I knew the effectiveness of the catalog would hinge on how well it was organized
  • Information architecture would be key to the success of this new product
  • The workshop uncovered a handful of categories I could use as a starting point

I ran a closed card sort study

  • I included 37 cards sorted into 10 pre-determined categories (categories came from the workshop)
  • Each card contained the name of 1 service
  • I recruited 10 participants (scientists across a mix of teams)
  • Sorting was done digitally using Mural - I gave each participant their own white board with the cards and categories, they had 1 hour to sort
  • I exported each whiteboard as a CSV, cleaned the data, and joined into a single spreadsheet
  • I imported the spreadsheet into Tableau and plotted a heat map

Results from the card sort study

The card sort gave me the insights I needed to move forward

  • The card sort resulted in a number of categories I could confidently build a design upon
  • Other categories were still rough around the edges, however I felt the best way forward was to build a functional prototype and populate it with real data

Quotes from the study:

  • "I didn't know we have this" 
  • "Sequencing makes more sense than sequence strains"
  • "Characterize a sample… that seems sufficiently vague"
  • "I honestly don't know where the protein stuff is gonna go"
  • "Design a protein... does that mean design DNA?"

I made a functional catalog prototype and asked science teams to fill out the content

  • I worked with the Data team to set up an easy way for scientists to start populating data
  • I wrote guidelines on best practices for filling out the catalog information. The best practices were inspired by insights gleaned from prior rounds of user feedback
  • I worked with Ginkgo’s science leaders to encourage their teams to populate the new catalog. Once the leadership team was bought in, it was easy to convince scientists to populate the dashboard

Functional prototype dashboard

Outcomes

The dashboard was a cheap solution with an outsized impact

  • The dashboard used existing Ginkgo tooling and required almost zero engineering resources
  • The dashboard gave users access to info that was never written down in a single place
  • Prior to having a catalog, they used to track down this information via Slack and team meetings
  • I was invited to share the dashboard to the entire company at a town hall meeting which generated lots of excitement from both scientists and c-suite leadership

We hit our target KPIs for catalog adoption

  • I had previously worked with Ginkgo’s leadership to establish target KPIs for catalog adoption
  • One KPI measured percent of information filled out - we knocked this one out of the park thanks to the collaborative working relationship I established with scientific leaders
  • Our other KPI measured page views - we also hit this target. However, spiky traffic indicated a need for more awareness building through Product Management support

I handed off the catalog to a dedicated product owner

  • This project started off as a self-driven “side quest”. Nobody asked me to do it, but user research highlighted an unmet need so I secured the resources to solve the problem
  • The catalog eventually grew into more than a “side quest” and required a dedicated owner to ensure continued maintenance and adoption
  • Luckily, a product manager from a science team was eager to take over the catalog and grow the product
  • She has since integrated the catalog with other data sources and made further user-facing improvements
  • Today the catalog is widely considered an indispensable source of information at Ginkgo
  • I firmly believe the product worked because it’s creation was grounded in human centered design practices
Darek Bittner

Next case study