Designing robot instructional software for complex setups
Case Study: Expand on a previous design to allow users to create relationships between multiple containers based on common laboratory patterns
Skills: Discovery Interviews, User Flow Mapping, Lowfi -> Hifi Wireframing and Prototyping, Prototype Testing, Information Architecture, Interaction Design, SQL, Quantitative Testing
Summary
Background
Scientists need to mix various liquids together to create reactions and run experiments. They are often doing this with the aid of laboratory automation and need to setup their liquid transfers using software.
Ginkgo scientists perform over 1000 liquid transfers every day. Shaving minutes off of each transfer yields hours of time saved across the company every day.
Saving even 3 minutes per transfer is 50 hours a day saved
Challenge
Understand how and why scientists are moving liquids between multiple containers at a time. Create a design that takes advantage of the common patterns and allows scientists to swiftly setup otherwise complex transfers. Improve upon the old UI by allowing flexibility and controlled variations within those common patterns.
Solution
I designed a UI that took advantage of the sentence structure that users used to describe their transfer setups to me and described setup in terms that were familiar to users
A screen recording of me making 4 copies of a source container and moving samples from 4 96 well containers to 2 384 well containers (because I wanted to skip quadrant 4 to leave room for experimental controls) using the new UI
Show me the numbers!
We ran a quantitative study post-release that asked users to complete 3 tasks using both the New UI and the Old UI. The graphs are at the end of this case study
Every single participant thought using New UI to complete the tasks was easier than using the Old UI through SEQ scores
There was an 87% reduction on task failure using the new UI
Looking at only those who completed the tasks, there is a 48%-71% average time decrease for completing the 3 tasks between the old and new ways
Lastly, of those that succeeded a task using both methods, every instance of a task took about equal to or less time to complete using the new UI
“I’ve had a lot of folks from the lab side bring up how much they are liking the improvements to the liquid transfer interface. The theme has been that at all the conferences/demos they attend, there are a lot of similar products to what we have internally developed, but one place we consistently shine above is our liquid transfer interface.”
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
They need software that allows them to quickly and easily record what samples they want to transfer and where
Scientists at Ginkgo use many different robots, and commercial software is specific to each brand of robot
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 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 time1000 x 3 minutes wasted = 50 hours a day!We grew out of our previous solution from 2016
Research in 2021 demonstrated pain points such as a difficult learning curve, lack of integration with automation, and a lack of flexibility for certain operations.
This led to many users not recording their samples in software and inaccurate data tracking, and more importantly, users spending a lot more time than necessary onboarding and setting up their experimental protocols.
Additionally, a large quantity of transfer types added effort on development teams to maintain.
A video of creating a simple transfer between four 96 well containers and one 384 well destination container using the old interface. Inexperienced users have difficulty knowing which Transfer Program Template to select on the first try. This design also had 1 happy path and did not provide enough flexibility for slight alterations
So we built an MVP to create transfers between 1 source container and 1 destination container.
This MVP allowed users to specify where they wanted to move their samples from 1 container to 1 container and laid the groundwork for a brand new interface that I could expand upon. Check out his work on that project here!
However, MVPs are never enough. Many of our scientists are performing liquid transfer operations between multiple containers and would not adopt the product without that support
The basics of the new design were well received.
The next phase of work aimed at creating a collection of templates that would allow users to express intent between multiple containers without needing to go into each individual container to do so.
Design Challenge
Understand how and why scientists are moving liquids between multiple containers at a time. Create a design that takes advantage of the common patterns and allows scientists to swiftly setup otherwise complex transfers. Improve upon the old UI by allowing flexibility and controlled variations within those common patterns.
Actions
Process flow
Discovery
Understand type of transfers by having users draw on paper and answer questions
Identify patterns
Compare responses across users to find themes and common transfer types
Ideate
Create low fi clickable prototypes that introduce new concepts
Test
Test prototypes with users for usability and fit
Iterate and Test
Incorporate feedback from the first round of testing to improve designs. Test again
Hand off
Meet with devs and create materials for smooth hand-off. Collaborate during the coding process
We formed a team of engineers from software and automation
We met every other week to discuss ideas throughout the development process. Since they work our software on-call, they have a lot of insight into the problems that our users are running into and needing to file tickets for
I started with more in depth research. I asked 8 users to draw and tape together paper containers to represent what transfers they were performing
I tried to include early adopters of the MVP, people who hadn’t used the new feature before (but had used the old version) and an automation engineer.
I choose to have users explain their use cases using paper because it could be completely free form.
‘Crafting time’ made the exercise more comfortable and allowed the scientists to walk me through their experimental workflows without being restricted by any limitations of software.
I also added more questions about how they mentally group containers and if they always treat a grouping of containers the same to deepen my understanding.
A photo of a participant explaining how they would setup a transfer between different containers
A photo of a simple workflow and how the samples move to different wells between different steps
A photo of a type of common transfer where users are consolidating samples from multiple containers onto one
From there, I compared across users and found common patterns in the way they were transferring
Photos of from multiple participants talking about how are make copies of their containers.
Users described many different types of transfers they were making and what the purpose of each one in the experiment. A few examples:
Users store many of their successful samples as glycerol stocks to be used later. At the start of a new experiment, a user might want to transfer a little bit of sample from each well of their storage container to experiment one while not affecting the original material.
Cells needs media to grow and multiply so that there can be enough to be tested later on. Media from one bottle or container needs to be transferred into every well of sample.
A 96 well container and a 384 well container are the same physical size, so each well of a 384 well container is about 1/4 the size of a well in a 96 well container. Cells grow better when there is more space to grow, so many people will grow their cells in 96 deep-well containers. But to save money on reagents and get more high throughput, some scientists opt for the 384 well container for testing. Common transfers involve moving between 96 well containers and 384 well containers.
Given these use cases, I used figma to low-fi prototype a new interaction
A screenshot of a single frame from my low-fi prototype
A screenshot of multiple frames with annotations from my low-fi prototype. I like to diagram out each of the interactions at this stage so that I can visually see and think through each interaction
I tested this as a figma prototype with 6 users and with senior product designers and it tested well but had added unnecessary complexity for edge cases
People liked the concept of grouping similar plates together and quickly understood the concept of a stack
People didn’t understand the difference between stacks if each plates can be individually edited
“Seems like Arbitrary grouping that the user determines – this creates a lot more UI elements on the screen and more visual things to manage, that’s where I’m pushing back on. This level of flexibility could add more complexity – it’s a tradeoff”
A screenshot from a user prototype session
I iterated, and tested out a new approach for a handful of the patterns
A major design decision was how to draw boundaries between which types of transfers would be grouped together.
When describing their transfers, users often used similar nomenclature when describing the transfer. How I want to transfer out of this source container(s) + How I want to transfer into this destination container(s) . Users are thinking about what they want to do in the form of sentences, why not create a fill in the blank with that sentence structure?
I used similarities between user descriptions and mental models, the number of containers they were transferring between, and the way wells were associated with each other to determine the boundaries.
A screenshot of the first draft of the sentence structure for going between 4 96 well container and 1 384 well container. During the interviews, many users described this interaction as a ‘Compression’
A screenshot of the first draft of the sentence structure for making copies of a single container. Many users described this interaction as a ‘Copy Layout’
A screenshot of the first draft of the menu where users would select the type of transfer they would be setting up by seeing a visual representation
This tested a lot better with 5 more users!
Overall, the sentence structure resonated with users and was quick to learn. There were some comments about how they wished it did more calculations on the number of destination containers would be needed based on their inputs
“Straightforward. Everything I clicked without thinking about it was right on the first try”
“This works really well” “This was visually exactly what I anticipated”
“Quick. It was easy to figure out”
It was tricky getting the right sentence structure for all the patterns, but it was a very fun puzzle to solve. I cleaned up the mockups and got ready for handoff
Despite having multiple transfer types, One of my top priorities was creating a sentence structure that could be reused as much as possible for all the other transfers. This would decrease the learning curve for users using multiple transfer types, and make development easier by having reusable parts
Screenshots of 3 setup frames from 3 different types of transfers. Pink and blue boxes show reused components across transfer types
During handoff, I also mapped out all of the interactions and flows for each transfer type
A screenshot of a portion of my interaction diagram for all of my transfer types
A screenshot of a slack conversation with a developer while we were functionally testing
I collaborated with the engineers as they built out the designs
The engineers shared feedback on technical feasibility and used the designs to inform their data models throughout the process
I walked the developers through my flows before development to to give an opportunity to ask any questions and to gauge feasibility of my final design
I performed all of the functional testing prior to release for each transfer type to test main and edge cases
We all worked together to solve for unexpected edge cases uncovered during coding
Each transfer type was individually developed on over time
A screenshot of one of our collaborative Figma files with the mockups
Solution
A screen recording of me making 4 copies of a source container and moving samples from 4 96 well containers to 2 384 well containers (because I wanted to skip quadrant 4 to leave room for experimental controls) using the new UI
Results
A few months after the release of some of the new transfer types, we ran a quantitative study between the original UI vs the new features
I identified 3 critical tasks to be our benchmark KPIs
Our team’s UX research specialist mentored me on how to properly run a quantitative study in a previous usability session she ran
I used SQL and our Snowflake database to identify users for testing
I ran the study with 20 participants from a variety of teams, tenures and experience with the tools.
I equally split the 20 participants into an A group and a B group. The A group would use the old way to complete the 3 tasks first and the B group would use the new UI first.
I timed the same tasks on the old UI vs the new UI
I did not offer assistance, ask questions, or encourage participants to think out loud for this style of testing
I created a template in excel to speed up and automate data analysis
Quantitative studies showed major improvement!
Every single participant thought using New UI (orange) to complete the tasks was easier than using the Old UI (blue) through SEQ scores
A graph of the SEQ scores. The average SEQ score for the old UI was 2.3 and the average for the new UI was 6.0
There was an 87% reduction on task failure using the new UI
A graph of the completion of the 3 tasks.
Looking at only those who completed the tasks, there is a 48%-71% average time decrease for completing the 3 tasks between the old (blue) and new (orange) ways
A graph of the time on task for all tasks
A graph of the time on task for task 1
A graph of the time on task for task 2
A graph of the time on task for task 3
Lastly, of those that succeeded a task using both methods, every instance of a task took about equal to or less time to complete using the new UI
A slope graph of the time on task for all tasks
A slope graph of the time on task for task 1
A slope graph of the time on task for task 2
A slope graph of the time on task for task 3