Benchling creates software for life science teams, ranging from academic labs to some of the largest pharmaceutical companies in the world. What started as a simple set of tools had evolved into a full platform, with over 200K scientists and 1,300 companies relying on it.
In 2025, we launched Benchling Bioanalytical, a product to help large enterprise customers test samples during drug development.
Role
Design lead. Co-led discovery with a senior PM, then coordinated design work across 4 designers and 5 engineering teams.
Timeline
2024-2025
Outcome
Launched with Merck, our charter customer, onboarding 400+ users and reducing throughput time by 90%.
Skills
Research · Product Strategy · Information Architecture · Interaction Design
During drug development, companies run analytical tests to ensure the quality and efficacy of their drug product and manufacturing process. Developing those tests is itself a massive investment, they have to be designed and experimentally validated, just like the drug. Novel biological drugs make this even harder, since scientists are working with living materials that are sensitive and easily contaminated.
For companies like Merck, this process can be excruciating. They'd lost a major vaccine deal because their business processes and IT infrastructure couldn't keep pace with the speed of science, a bottleneck in connecting physical lab work to the data it produced.
Scientists can define protocols flexibly and iterate on them until they're ready to publish.
Scientists can flexibly design plates which are used by instruments to automate lab work.
Scientists can execute work by hand or through lab automation, analyzing large volumes of data seamlessly.
Lab managers intake materials and make sure they're safely stored in the right place, with full traceability when they're used in experiments.
Lead scientists and quality teams can review work, trace back results, and manage project progress.

Modern science is a team sport, with a lot riding on the hand-offs. Behind any drug candidate sits a giant repository of past knowledge and a web of systems and teams that all have to work in sync.
Like many industries, software had evolved to serve the specific needs of each user, creating complex hand-offs and data siloes. But the stakes are exceptionally high, as incomplete data or poorly-documented work can lead to regulators pausing a drug development campaign worth billions.


Early stage R&D is ambiguous and exploratory, but as teams move into drug development, they're more like chefs trying to perfect a recipe.
They iterate through many versions, varying a ton of experimental parameters, until they have everything dialed in. There's still innovation and creativity, but efficiency and reliability are the ultimate goal.
We decided to spend significant time on-site with Merck, doing lab tours, stakeholder interviews, and whiteboarding sessions.
The picture rarely came together cleanly. Each conversation surfaced a different system with a different interface. Each scientist was only familiar with their specific team's workflows and what happened beyond was an organizational black box. We read through hundreds of pages of protocols, raw data, and reports ourselves to piece it all together.
A major challenge was helping our teams back home understand and buy into what we learned. My PM counterpart and I hosted a series of onsite user workshops where we broke down each user journey, pulling in experts from each side to walk us through everything.

Different tools capture and document data, but they don't talk to each other. Scientists end up manually chasing down samples, checking expiration dates, and recording work they'd done hours earlier. On average, a scientist needed to work across nine systems to access the information they need.
Different materials and instruments live in different systems, each with their own data structure. No one could agree on what a "sample ID" was, so they existed in four different formats, relying on know-how and Python scripts to get everything consistent. Multiply this across different systems and it led to a lot of frustration and confusion.
Robotics made execution faster, but also more data than teams could handle. Given all the manual steps in handling and processing data, the tedious work rapidly piled up. Lead scientists talked about manually reviewing reports, even on nights and weekends.
Teams didn't have visibility into each other's work, which led to confusion around timelines and requests. Every team wished the other teams understood their work better. When are my samples arriving? Where did the test results go?

Within the past year or so, we'd been developing a product called Benchling Bioprocess, which helps scientists design the manufacturing process for producing the drug.
Our bet for Bioanalytical was that it could be built on the same technical foundation as Bioprocess.
Historically, bioprocess and bioanalytical software had evolved separately, but this led to tool sprawl and data silos. This jacked up operational costs and made it hard to extract learnings from all their data.
However, we observed that both team are developing step-by-step procedures through systematic experimentation. Both needed their procedures to be eventually locked down and executed repeatedly.
As we spent time with their team, we felt more confident that it could work.
Data needs to move seamlessly from one step to the next, without breaking, without manual re-entry, without anyone having to double-check it survived the hand-off. We prioritized getting this right, fast and reliably, before spending time on anything else. A beautiful screen doesn't matter if the data behind it doesn't get exported correctly ten steps later.
Scientists were already navigating too many systems where the same thing looked and worked differently depending on where you encountered it. They needed X to mean X everywhere, consistently, including in how it showed up in their data. Consistency builds trust in our system faster than a beautiful color palette.
During early development, scientists need to be able to do whatever they want, quickly. Even though we want to simplify workflows, there's irreducible complexity to what they're trying to do. However, once a test is finalized, we must ensure everything's locked down correctly with no gaps.
Before building something new, we asked whether we could extend what already existed, only considering something net-new when that genuinely wasn't enough. As designers, we were especially responsible for this, as we often spanned multiple teams and could see the UI patterns in a way that engineers focused on their specific app area wouldn't.
I led a design kickoff, walking through our insights and conceptual flows, while everyone basically picked apart the brief. I wanted to empower everyone to own their work, but balance that with executing quickly.
For example, one designer wanted to go wide in exploring solutions. I heard them out, exploring ideas together, but made it clear we'd need to backlog some until after launch to help our team focus.
I also helped junior designers troubleshoot a never-ending list of org issues. The big one was that the lead designer for bioprocess had left and a junior designer had stepped to fill in, assuming that a lot of the core work had been done.
Perhaps unsurprisingly, there were many unresolved UX questions to work through and she was having a hard time working with her PM. I lent a sympathetic ear, but focused on helping her address the issues head-on with her PM. While they didn't end up being best friends, she started being added to the right meetings and gained recognition as an indispensable part of the team.

I want to focus on plate designs to highlight the questions around information architecture, navigation, and interaction design that I worked on with our team.
I'd originally explored a few concepts with plate design as an additional step in experiment planning. I wanted to show we could re-use existing or planned components to easily design plates, including via templates, and assign them runs (i.e. the documents where scientists would execute the work).
It turned out this wouldn't work.
Plate design was being built into our existing notebook document system. It's where our current scientists work and it hooks into other systems for registering entities, keeping audit logs and so on. Fundamentally, our experiment planning flow had grown far beyond its original intended scope and it was too late to rework those assumptions before launch.

To my surprise, Merck's scientists were okay with it.
It wasn't the ideal experience, but they were already being forced to plan experiments, design plates and execute work in different contexts, so having a single clean data flow already felt like a large improvement. It still bugged me, but I could live with the trade-off.
The silver lining was that we were able to ship improvements to how plates were visualized across our platform, including for our core R&D users. It was a great example of building with leverage and included improvements to how plate visualizations and liquid transfers.
And, even though my role was mostly to whiteboard and bounce ideas, it was nice to do some hands-on exploration and see it help all our users out.
After months of work and weeks of rigorous user acceptance testing, we saw Merck go live with a public announcement and 400 users onboarded.
Usage steadily climbed after launch based on our internal dashboards, though we didn't have time or internal staffing to dive deep into the metrics or build out better instrumentation.
One major positive signal was this led to several other teams planning to adopt Benchling, potentially expanding to thousands more users over the coming years.
Also, despite shifting focus back to bioprocessing, we landed two more prospects without any salespeople dedicated to bioanalytical. And one deal had gotten far enough where we'd basically validated our solution and were planning to close it within the next few months.

Around this same time, generative AI adoption was picking up across the org, but we made a deliberate call not to try bolting anything onto this project mid-stream.
Instead, Benchling spun up a small, dedicated AI team, with one of our founders, a group of engineers, and another designer, and I contributed use cases and feedback on emerging design patterns from the sidelines.
I was personally very interested in data entry, since scientists spend an enormous amount of time on it, including in experiment planning. What if they could just describe what they wanted, or upload a spreadsheet or screenshot that didn't match our table formats at all, and let the LLM interpret it? The hard part was balancing accuracy against token efficiency. We landed on a multi-model consensus approach for a while, which worked but was expensive to run at scale.
I ended up working on an enabling piece of that puzzle: integrating with external ontologies, so the LLM could reference a standard set of definitions and values per customer, making it more accurate without needing as many models running in consensus.
By the time I left, Benchling was gearing up to launch Benchling AI, layering generative AI across the platform to help scientists with everyday work.