Accelerating R&D workflows for biotech companies
OVERVIEW
Scientists in pharma and biotech use Benchling to design DNA sequences, track samples, record their work, and analyze data. Benchling’s Workflows product helps teams connect these activities, making hand-offs and collaboration smoother.
For example, a scientist running an experiment might need certain samples analyzed by another team. Once the analysis is done, the results go back to the scientist, who can then continue their work. Workflows in Benchling help manage these activities by organizing tasks, assigning them to the right people, and keeping everything on track.
When I joined the Workflows product team in 2022, they had just launched branching workflows—a big step up from linear workflows. But there was a catch: our customers couldn’t set rules to automatically decide which path a workflow should take. This led to frustrating workarounds, slowing them down instead of speeding them up.
To fix this, I led the team through workshops, design iterations, and user research to develop Routers, a feature that lets scientists create custom logic within their workflows—so they can focus on discoveries, not workarounds.
Role
Product Design Lead @ Benchling
Team
Product Manager
Engineering Leader
Software Engineer x4
Duration
6 months (10/2022 - 04/2023)
PROBLEM
Customers can't accurately model R&D workflows in Benchling
Our customers had no way to automate decision points in their workflows. Without this, they couldn’t accurately model their R&D processes, which made the Workflows product harder to adopt and forced scientists to rely on frustrating workarounds.
Take an assay panel, where different tests (assays) are run on samples. Scientists need to route samples based on criteria—like sending blood samples to one test and tissue samples to another. Without conditional logic, Benchling’s workflow would send all samples to every assay, even when certain tests weren’t needed.
Scientists had no easy way to fix this, making automation—and their work—more complicated than it should be.
Frustrating workarounds
Without this conditional logic baked into workflows, scientists have to deal with 2 workarounds to doing their job:
1 —
Canceling tasks
Scientists can manually cancel unwanted assays. This is time-consuming and leads to messy data since assays are canceled due to the product’s limitations, not for scientific reasons.
2 —
Editing the workflow
Scientists can manually delete the unwanted assays from the workflow. This is tedious and can lead to errors since scientists aren’t familiar with the workflow editing tool.
CONCEPTS & PRINCIPLES
Exploring solutions with the team
I led a design thinking workshop with the team to get everyone aligned on the problem, map out ideal user flows, and brainstorm solutions. The problem space was pretty broad, and the ideas we generated reflected that—it was clear we needed to narrow our focus.
I don't think the workshop was 100% successful. We had great discussions and generated solid ideas, but we couldn't align on a direction. To help guide decisions and future conversations with the team, I created a set of design principles:
PRINCIPLE #1
Empower administrators
Don't put the burden on scientists. Benchling should accelerate their work, not slow them down by asking them to configure workflows. Administrators know the business logic needed for their workflows—empower them to do this work.
PRINCIPLE #2
Re-use existing patterns
We have a strong foundation in our workflow editing tool. Let's continue to build on that, rather than introduce new paradigms that are costly to build & require users to learn from scratch.
PRINCIPLE #3
Solve for the majority use cases first
Most customers are using our tool to model sample management & testing/screening workflows. Focusing on those key use cases will help us deliver value faster.
Making some early bets
These principles helped us decide on two key aspects of functionality as I was iterating on wireframes.
1 —
Drag-and-drop to add decision points
We decided to introduce a new type of "node" called a Router, which users could drag into a workflow to add decision points. By building on the existing workflow builder’s design and functionality, we hypothesized this would make the feature easier to adopt.
2 —
Build logic by filling out a form
We also decided to add a new UI for configuring Routers, allowing users to set up conditional logic by filling out a form. While coding would offer more flexibility, it wouldn’t be accessible to administrators who in most cases don't know how to write code.
USER RESEARCH
Getting our MVP in front of users
As we finalized the scope for our first release, I kept iterating on the designs. Since we were introducing new capabilities and a new configuration UI, I wanted to test them with real users. I teamed up with our Product Manager and Customer Success team to recruit 10 administrator users to participate in usability tests & share their feedback.
We didn’t find any major usability issues, but we did get a clearer picture of what customers needed to fully adopt routing in their workflows. For example, our initial release only supported routing based on strings, but we quickly learned we’d need to handle numbers, booleans, and Benchling-specific data types like entity schemas.
I shared these insights in a research report, which helped shape our roadmap and prioritize fast-follow releases.
OUTCOME
Promising results
We launched Routers in April 2023 with a set of capabilities that covered many use cases, but we weren’t sure how quickly customers would adopt it. Three months later, nearly 30% of our customers had already set up a Router—faster than we’d anticipated, since features like this usually take longer to roll out and implement in Benchling.
30% adoption
in 3 months
v1 — April 2023
We launched the first version of Routers in April 2023, giving customers a way to add decision points to their workflows and set simple rules to decide which path to follow. To start, it only supported routing based on string values.
Adding Routers to a workflow
Getting started is easy—just drag a Router into the workflow and connect it to other steps. Hovering over it reveals an option to edit the Router's rules.
Selecting a variable
Selecting a destination
Once you’ve picked a variable and set a condition (e.g. “If the Assay is qPCR”), the final step is choosing where the workflow should go next when the condition is met.
Editing labels
A small but impactful feature I advocated for was allowing users to edit labels for each route and the Router itself, making workflows easier to read at a glance.
v2 — October 2023
By October 2023, we expanded Routers to support numbers, booleans, and Benchling entities, along with new options to automatically stop a workflow or repeat a step. We focused on these improvements based on what we heard from customers and the research I had run earlier in the year.
"Looping" a workflow
If a condition is met, the workflow can loop back to an earlier step—a must-have for Quality Control workflows, where samples need to be reprocessed until they meet a certain standard.
Stopping a workflow
A workflow can also automatically stop when a condition is met, if continuing the process doesn’t make sense anymore.
v3 — October 2024
In fall 2024, we took it a step further by adding support for multiple conditions, allowing customers to set up more complex logic. Adoption has slowed down a bit, but nearly 55% of our customers are now using Routers.
Adding multiple conditions
New affordances let users add multiple conditions and choose whether all—or any of them—need to be true for the route to be triggered.
Adding condition groups
Users can also group conditions, to build more complex, nested logic.
RETRO
If I could turn back time…
No project is perfect. If I could do two things differently, I'd push for a more focused MVP earlier in the process, and define clearer success metrics upfront.
Speeding up our scoping & iteration
As soon as the project kicked off, it felt like we were trying to boil the ocean. This slowed us down a bit, since my initial explorations were trying to solve for every use case under the sun. While there's merit to understanding the full picture of the problem and having a vision for what we want our long-term solution to be, we could have narrowed in on a set of requirements for a v1 earlier in the process.
Defining success metrics
Having success metrics—at least discussed—early on in the project could have helped focus my designs, and our scoping of the feature. We were mainly guided by closing product gaps, which was valuable, but understanding what behaviors we wanted to impact could have allowed us to move faster and make quicker decisions.
For example, some things we could have tracked and quantified:
Time on task
thanks to automated decision points in workflows
Cancelled tasks
because we eliminated a manual workaround
Workflows edited
because decisions are now encoded in workflows
Workflow templates
since workflows can now be more easily combined
Despite these shortcomings, I'm proud of what we achieved as a team. Routers is a complex feature that ties into many parts of Benchling—not just Workflows—and is helping scientists discover & develop medicines faster.
Want to read more?
Here's another case study if you have a few more minutes to spare:
