Benchling Bioanalytical Backup

Breaking the bottleneck

Going from weeks to days for test results

During drug development, companies have to run hundreds of analytical tests across countless samples to ensure the quality and efficacy of their drug product and manufacturing processes.

Developing these analytical tests is an enormous investment of time and resources because, like the drug product itself, they must be designed and experimentally validated. Novel biological drugs makes this even harder, as scientists are working with living materials which are themselves complex and sensitive.

For a company like Merck, the development process had become excruciating, as they'd recently lost a major opportunity to develop a vaccine. Their legacy software couldn't keep up with the evolution of the science. They needed a solution that could be easily configured and used by scientists, without requiring developers at every step.

The thing that was taking the longest wasn't doing the experiments in lab — it was getting data from all the systems collected and analyzed.

– Roy Helmy, Associate VP, Merck

Moving beyond early-stage R&D into drug development

Historically, Benchling had been a flexible lab notebook for recording anything — think "Notion for life science."

However, these scientists were more like chefs trying to develop recipes. They're trying to create a step-by-step process, through tinkering and iteration, until it's been perfected.

This means lots of experimental parameters, repeated over and over, at high speed and volume. It's much more of an optimization and operational efficiency game than pure R&D.

Building two products on a single foundation

Bioprocess vs. Bioanalytical

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.

It was a strong hunch, but until Merck, we hadn't had a customer to really prove it out.

Discovery

Getting out of Zoom meetings and into the lab

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 workshops where we broke down each user journey, pulling in video recordings and screenshots of their software, as well as reps from the field teams to help distill everything.

Research turned up dozens of smaller findings. These the following two mattered most because they cut across the entire project and directly set up the explorations ahead.

‍

Unstructured lab records made it impossible to streamline downstream processes

Scientists optimize speed and actual lab work, not software configuration, but this creates massive issues downstream. When final results get published, it's hard to track down where they came from. When a finding gets audited, teams need to open up documents and dig through audits.

This meant tons of manual review, painful audits and, occasionally, re-doing weeks of experimental work.

How could we help scientists captured structured data without slowing down their work?

Bottlenecks in the automated testing workflows

Once analytical tests are finalized, they need to be executed at scale. This entails complex hand-offs between teams. Lab managers intake samples in one system, scientists find samples in another system, record their work in another, and final results get published with little visibility back into the upstream work.

While each system was purpose-built for a particular user with a specific job, the connective tissue between often slowed things down and required tapping scarce IT resources.

How could we streamline these hand-offs while making each touchpoint still feel purpose-built for each user?

Exploring design directions

What would it take to actually support Bioanalytical?

We already had a data architecture and UI taking shape for bioprocess. Before committing to a direction, we wanted a clear-eyed gap analysis: how far could our existing foundation stretch to cover bioanalytical's needs and where would it fall short?

We explored this along a spectrum, from a baseline that leaned entirely on what we already had, to purpose-built explorations targeting bioanalytical's sharpest pain points.

‍

Baseline: What were we missing?

This included both capabilities that were in-flight but potentially had gaps, as well as net new capabilities which had been newly uncovered. We pulled teams in to help stress-test our understanding and make sure we had the latest plans from their side.

Exploration 1: Faster, lighter configuration

Scientists default to unstructured text when it's too hard to structure everything, so we explored ideas around making the configuration workflow easier for them. I drew inspiration from past customer feedback, low-code/no-code apps, and emerging ideas around LLMs.

Although we knew that many of these wouldn't make the cut, it helped resurface a broader set of issues that our notebook and table UIs suffered from and reinforced the importance of tackling these longer-term.

Exploration 2: Plate-based experiment planning

Plate design was an example where we had some initial designs, but which hadn't factored in the complexity of bioanalytical. This was true across many of our capabilities.

I viewed my role as helping the plates team deeply understand the use cases and material / data flow that needed to be supported, facilitating design explorations and providing feedback to the two designers who worked on it. In particular, I pushed us to explore how plate design could be better integrated within the experiment planning UI itself, as well as how to represent dense layers of parameter metadata (e.g. temperature, pH, etc).

Exploration 3: High-volume, automated test ordering

Once a test was finalized, it needed to run near-flawlessly across thousands of clinical samples.

But Benchling had no real concept of a "test order." In the real-world, a single sample can have many tests assigned, with complex logic on how it should be handled, tested and analyzed. And, if the results don't look right, they must be re-tested under different conditions.

The strategic tension underneath all three

Every one of these explorations pointed toward real, unmet need. But building all of it carried serious risk.

On the product side, we only had one bioanalytical customer at this stage, which meant a real risk of over-building for Merck's specific workflows rather than the market's actual needs. It had taken months to get a deep understanding of Merck and we'd need more time and people to do broader, more rigorous discovery.

On the execution side, engineers were already split across two major workstreams, on top of core product work and keeping the lights on, so landing all three wasn't guaranteed. Leaning on existing components wherever possible bought us time to keep learning before committing to bigger, harder-to-reverse investments.

Throughout this project, we had to troubleshoot tension between teams, as Bioanalytical tapped people who were normally organized by app pillars and feature areas. It meant lots of context-sharing and alignment meetings, eventually turning into recurring product leadership meetings, to make shared prioritization decisions.

I viewed my role as an advocate for scientists, as well as translator of ideas, since it was often hard to really know what decision we were making and what the impact would be without seeing it in some tangible form.

Designing for the art and science of plate layout

I want to dive deeper into plate-based experiment planning because it's a key area where Bioprocess and Bioanalytical diverged and illustrates my approach to solving complex trade-offs and team dynamics.

A plate is a grid with wells arranged in rows and columns, which robotic instruments can transfer fluids in and out. You can thousands of individual chemical reactions in a single plate, so they're the industry standard for all bioanalytical work. Our task was to figure out how plate design could be easy to use yet robust enough to handle real scientific work.

Defining and varying experimental parameters

Earlier plate design explorations had assumed one common parameter would vary across a plate: dilution. That assumption made sense for the use cases those explorations were built around, but it didn't hold for bioanalytical. Here, scientists needed to define and vary essentially any parameter that made physical sense for their experiment, not just dilution. That meant the underlying interaction model couldn't be built around one hardcoded variable. It had to support an open-ended set of parameters, defined by the scientist, without becoming so abstract that the interface lost any sense of structure or guidance.

Getting materials and data to actually flow through the design

The earlier explorations had also assumed plate design would live inside a flexible notebook, not a structured, step-by-step process. That assumption broke down too. If a scientist had already defined materials and parameters, like temperature, earlier in their workflow, could those be pulled directly into the plate design? Should some even be enforced as required? And once a plate was designed, how did that structure flow downstream into analysis, so the data collected actually connected back to what was defined upstream? For simple plates this was manageable. For complex ones, with dense layers of materials, parameters, and data all needing to be represented at once, we had to figure out how the interface could scale without collapsing into visual noise.

Keeping plate design out of experiment planning, for now

The cleanest solution to the parameter and data-flow problems would have embedded plate design directly into the experiment planning step. Once we understood that wasn't feasible within our timeline, the workaround was to have users fill out the experiment planning table as before, then design their plates separately, inside the experiment's worksheets.

I pushed back on this hard. Splitting plate design out of the main flow meant asking users to hold context across two separate places, which raised real concerns about navigation confusion and added interaction cost. We brought in an architect to make sure we'd actually exhausted the technical options, and pushed for a broader product leadership review so the trade-off was understood by everyone, including the customer-facing teams.

What surprised me was that the bioanalytical scientists we shopped the idea with were fine with it. My honest read, as a designer, was that this was easier to accept in the abstract, before anyone had a live product they were using every day to compare it against. Their reaction didn't fully resolve my concern, but it did confirm the workaround wasn't a dealbreaker, which mattered given the timeline we were working against.

We also knew this wasn't an irreversible decision. It was a resourcing and sequencing one in service of hitting a v1 deadline, not a permanent architectural constraint. Still, it was one of several calls where we knowingly chose something that wasn't the ideal experience, because the alternative meant pulling investment away from other work that mattered more at the time. Not every trade-off in this project was one I fully agreed with, but they were made deliberately with a clear enough understanding that we could revisit them later.

‍

Outcomes

Shipped, validated, and expanded

Everything from this work shipped and went through rigorous user acceptance testing on Merck's side before going live. Merck leadership was pleased enough with the result to do a public launch, estimating that their teams could now collect and analyze data roughly ten times faster than before.

Usage climbed steadily after launch, based on our internal dashboards, though I'll be honest that we didn't have the time to properly baseline it or dig into the numbers qualitatively. Much of our UI also wasn't instrumented much beyond high-level usage metrics at that point. For sentiment, we leaned heavily on our customer field teams and direct conversations with scientific stakeholders, and what came back was consistently positive.

The engagement also expanded well beyond its original scope. It opened the door to a deal with non-analytical teams at Merck, who were drawn to our core offerings specifically because of how well they now integrated into the broader workflow and improved handoffs between teams. It also helped open conversations with two customers outside Merck, one of which had signed by the time I left Benchling.

Jia Liu