Leading a Redesign of a Core Piece of Scientific Software

Product Management Skills Case Study: Using user insights and mental models to drive planning a software redesign

Skills: Discovery Interviews, Roadmapping, UX Strategy, Stakeholder Management

Background

A Liquid Transfer is a fundamental operation in molecular biology

  • Scientists move liquid (known as samples) in different combinations to create reactions and measure the outcomes. 

  • Samples are liquid that can be mixed and moved can be DNA, cells, chemical reagents, controls, etc. 

  • A Liquid Transfer operation can be made up of many individual transfers that are grouped in a meaningful way. For example,  you’re pouring a bottle of water out for your friends at dinner. Technically, each pour is a transfer of liquid, but the act of you filling all of your friends’ glasses with water is a meaningful grouping of liquid transfers

Ginkgo scientists create over 1000 new liquid transfer operations every day and need software that allows them to quickly and easily record what samples they want to transfer and where

  • Scientists can make 1 transfer at a time with a single channel pipette, but most often are able to perform multiple transfers in parallel with the help of robots. (Hence why referring to a liquid transfer as a group of transfers is more helpful)

  • Scientists at Ginkgo use these robots to mix tiny amounts of liquid inside containers. Containers typically have 1, 24, 96, 384, or 1536 wells, laid out in a grid

  • Some scientists work with 1 container at a time, whereas others work with 20 or 30 containers in one experiment!

Scientists can use many different types of robots to do their transferring for them, and need a way to instruct when and where to mix each sample

A screen recording of setting up a transfer in the 2016 liquid transfer

A video of an automated liquid handler performing 96 individual liquid transfers at once. The white blocks are containers

Because Ginkgo scientists perform so many liquid transfers a day, inefficiencies in setup add up quickly 

Spending even an extra 3 minutes per transfer can waste valuable time
1000 x 3 minutes wasted = 50 hours a day!

Ginkgo developers designed and built a tool from 2012-2016 to allow users to program their liquid transfer setup

  • The original software was designed fully by software developers prior to the creation of the Product team

  • Their solution for creating liquid transfers worked great for a small, tight-knit, less than 200 person company

  • There is a big difference between building software that solves specific problems, vs. a cohesive and seamless software that is easy to use and intuitive. As software scales and grows we need to be conscious of usability and UX issues as it is not possible to directly reach out to every user and train them

An image of the 2016 liquid transfer menu. A user needed to learn all of the options and know exactly when to use each one

Challenge

Users are expressing difficulty in learning and using the 2016 Liquid Transfer tool. What are all of their pain points and how do we use hindsight to build a better product? As the company is rapidly growing, how do we build a tool that is easy to maintain and easy to learn?

Actions

I conducted 17 user interviews across the organization to understand the use cases and current pain points around using software developed in house in 2012-2016.

  • At the time of original development, Ginkgo Bioworks was operating at a much smaller level and the software was more than sufficient. There were around 100 users, and software engineers were embedded on scientific teams

  • As Ginkgo was rapidly growing after going public, efficiency gains in software became more and more important

  • I asked questions about their goals, what are their common workflows are, how they use the software in those workflows, when they choose to bypass using the software, and what works well and not well.

I analyzed all of the interviews, and found themes in pain points across users. I aggregated the themes in a google spreadsheet

While analyzing the user research in google docs (before we started using dovetail), I color coded recurring pain points

I summarized my insights in a google sheet

The research found that the prior solution was too rigid, had a difficult learning curve, a lack of integration with automation, and a disconnect from user mental models 

  • There were over a dozen different types of transfers and sub transfers, and users were required to understand the exact nuances to use them properly. 

  • Because of the rigidity of the software, users had to model certain protocol steps backwards in order to simplify their software setup time

  • Well selection for liquid transfers involved many tedious clicks for non-templated transfer types, and the templated transfer types didn’t allow for variables or modification

  • Common user flows were not captured, and it was difficult on the development team to add new transfer types

“ I might allocate 2-4 hours to set up a larger or more complex dev experiment with organick.”

The cool thing about this project is that while we are building something from scratch, we have a head start due to the learnings from the 2016 version

  • We already know all of the use cases that users are trying to accomplish and many of the pitfalls to avoid

  • The 2016 remains live as we are building the new version, so we can spend more time focusing on designing and building the new version with the best practices

  • Although it could be a double-edged sword that people will have access to the direct comparison tool, it will keep us in line to make sure we continue to build towards parity and make sure we actively build it better so that people will voluntarily switch over

In this redesign, I wanted to emphasize re-establishing the most basic definition of a transfer so that it would be easy to build upon

  • I thought about the problem like establishing a language. You first need your core alphabet (a single well to well transfer). From there, you can build words and sentences.

  • If you have a consistent alphabet, forming words becomes easier, forming sentences from words becomes easier, and so forth. I wanted to redefine the basic transfer was flexible yet sturdy so that we could abstract as we built out more complex transfers later on.

  • I worked closely with the product designer and developers to nail down concrete definitions that matched user mental models and were easy to build upon

  • Additionally, a major pain point in the 2016 version was that there was a separate transfer type for transferring into an empty container, mixing a liquid into another liquid AND mixing liquid together into an empty container. You could not do a combination of those transfers at once. In the redesign, a user should be able to move any liquid into any well, regardless of mixing or not

An graphic illustrating the building blocks of re-establishing the basics

Redesigning and building a core piece of software is a major lift. I built a roadmap around starting with strong foundations and building upwards and onwards

  • Phase 1 (MVP): Introduce a new software design and create consensus amongst basic transfers

  • Phase 2: Using the foundations in Phase 1, design a pattern to handle transfers between multiple plates to build out transfer templates to support current use cases (View my design work for this phase in this case study)

  • Phase 3: Using the patterns and components in Phase 2, build out transfer templates to support cases unsupported by the 2016 version

  • Phase 4: Stress post-usability testing and focus on quality of life improvements to drive adoption

  • Phase 5: Using patterns and components in Phase 3, abstract further and allow users to group transfer templates and reuse transfers by providing shortcuts to setup

  • Phase 6: Find ways to speed up the execution of liquid transfers

  • Phase 7: Using patterns and concepts from all previous phases, abstract further and leverage AI to create transfers for users based on their past experiments and goals

A screenshot of the phases roadmap

Each phase of the project was its own initiative and encompassed 1 development cycle to deliver sizeable value

  • Each phase (except phase 4) would build on the previous one, adding incremental improvements and a new level of abstraction

  • Each phase is it’s own development cycle from discovery research, to prototyping, to development, to post-release testing. It also has its own project charter, risks, and measures of success

  • Things quickly change at Ginkgo, and software projects don’t always get funding post-MVP. This roadmap not only communicated the long-term plan to leadership, but also ensured that the project had good stopping points between each initiative

  • Each initiative had it’s own defined value, whether introducing a new suite of functionality, or significantly speeding up users

I also emphasized collaboration with engineers

  • I worked to form close relationships with them It was valuable and fruitful to discuss implementation details and their ideas to incorporate into the product. We collaborated to solve difficult interactions and to learn more about what is a reasonable ask or not.

  • I hosted a free-form biweekly meeting where anyone working on the project could review non-urgent user feedback, raise concerns, or discuss ideas to improve the project

  • We worked together to identify and address edge cases for each design. During development we dedicated time to thinking of as many edge cases as we could

Screenshot of a project charter

Within the phases, I worked closely with engineers to plan the order of the stories and provided guidance and feedback 

  • Throughout the course of the project, we have had a total of 4 engineers touch parts of the code

  • Prioritization was based on number of users impacted and time saved. Also, the quality of workaround influenced the order of work completed.

  • I made myself available to answer questions, and functionally test prior to release

  • To ease rollout, we advertised features to users in channels and would reserve time to address any immediate concerns or bugs

  • Additionally, we had a “minor improvements” board to collect smaller feature requests that would take less than 1 sprint to implement, and we aimed to complete at least 1 or 2 of these tickets each sprint

A screenshot of the Minor Improvements JIRA board

Screenshot of a slack discussion with a developer during functional testing prior to release

“I’ve had the pleasure of working with Hanna on a major project for the past year. She is talented at recognizing user needs, prototyping features, and working collaboratively with us engineers to iterate on the product. Hanna is proactive and thorough in researching the design for features and communicating needs to software developers. I will miss her organization and efficiency.”
— Software Engineer

In each phase, there was a strong emphasis on user input and feedback

  • Some users were bought into the development process from the very beginning, and even gave me slide decks with their ideas for the product

  • Each phase included discovery research, multiple rounds of prototype testing, and at least one form of post-release testing. Each round of research would uncover pain points and user needs that were folded into the design

  • I looped in a few early adopters in each research sprint

A screenshot of a Dovetail canvas from one of the prototype tests

I worked to continually engage with users in between releases

  • I made sure to provide updates throughout the process in a dedicated slack channel. I also used the channel to occasionally poll users to encourage engagement

  • Users would also suggest feature requests and bugs in the dedicated slack channel. I made sure to respond to each comment to learn more about their problem, and would respond with our ability to address. Alas we couldn’t address every request in a timely manner, and would figure out a workaround for users if we couldn’t get to it

  • Upon releasing new features, we allowed users to bypass our #help-software channel to directly report bugs and requests to us. We would allocate a week or 2 after every release to swiftly address concerns

  • Our minor improvement board worked at providing incremental value on smaller issues to continue to support users, even if we couldn’t work on a major initiative at the time

Screenshot of a slack discussion with users in the dedicated user engagement slack channel

Solutions and Results

We created an MVP focused on implementing strong basics

  • This was one of my first large product management projects, so I had support from another product manager

  • I also worked together with a Product Designer and two engineers. My product designer, Darek, talks about this work in his portfolio!

  • The MVP built out a new interaction design, as well as a different approach to setting up transfers in software

  • We limited the MVP to transfers between single plates to limit the variables we were testing in the first release.

  • We saw promising results for task time decrease in our benchmarking

Screenshot of the MVP

Screenshot of benchmarking results from the MVP

We finished phase 2 and 3 and successfully expanded the capabilities of the MVP

  • Post MVP, I worked as the product designer and manager of this project and worked directly with engineers as the Product Manager and Product Designer

  • Read about that initiative cycle in this case study!

  • We saw further task time improvement (49-71%!) and an 87% reduction in task failure in a side by side quant study

A video of the new liquid transfer tool after the completion of phase 2 and 3. There are also improvements from the quality of life phase as well

Users really appreciate the improvements

  • “It was better, like 100% way better”

  • “I really like the UI for the rest of it. I think it’s like way more intuitive than the old”

  • “This is the real game changer that can save you a lot of time”

Not only do users like it better, it affects the company’s bottom line

  • On average, Ginkgo users run 1000 liquid transfers per day. On the lean side, this saves users 1 minutes per transfer. On the complex side, this saves users over 10 minutes per transfer.

  • Thats a time savings of 17 to 167 hours A DAY

Additionally, this sets precedent for other products to be revisited and redesigned

  • Just because a scientist can do something, doesn’t mean that we can’t do better

  • There are major possible efficiency gains through good design

  • We can unlock a lot of potential and user trust by continuing to improve products. This presentation has led to software and automation leadership considering redesign of older software as well as green-lighting continued support for products post-MVP stage