The Problem

Benchling is the leading cloud platform for biotech R&D. Scientists use it to plan experiments, collaborate with teammates, and record structured data from their work. But there was a critical gap in the workflow.

After running experiments, scientists need to clean up, process and analyze raw data from instruments (for example, by reshaping data, doing linear regressions and curve fitting) in order to produce meaningful answers to experimental questions that guide the next round of experiments.

We offered an existing analytics tool, Insights Dashboards, but it required users to write SQL queries to extract data from Benchling. Most lab scientists don't know how to write SQL, so this tool was inaccessible to our core user base. Instead, they had to rely on other software (Excel, JMP, Prism) or cumbersome workarounds just to create simple charts. This meant:

• Fragmented workflows and lost time on data wrangling

• Multiple sources of truth (and version control headaches)

• Breaking Benchling's core promise as a unified platform

The opportunity: What if scientists could go from raw experimental data to meaningful insights, all in one place?

In 2024, we launched Insights Analysis, enabling lab scientists to transform raw data from scientific instruments into meaningful results with just a few clicks. ✨ 

Kickoff sprint

When we kicked off this project, “analysis” at Benchling meant many things (and thus touched many teams): dashboards, reports, SQL queries, integrations. To align stakeholders and carve our a clear product direction, I led a week-long design sprint with teammates from product, design, engineering, strategy, and field.

We synthesized past research, audited existing tools, and mapped out the landscape of analytics needs across Benchling. Most importantly, we defined where our product would play.

Defining the opportunity

What emerged from the sprint was clear: the biggest unmet need was for research scientists who interpret experimental data but lack technical backgrounds in data science or SQL.

While our existing tools served data-savvy users and operational reporting needs, there was a whole segment of lab scientists who just wanted to answer questions like "What were the results of my assay?" without writing code.

The challenge became: How can we help research scientists transform raw experimental data and visualize trends in common scientific experiments - without requiring SQL or coding skills?

Research

To design something scientists would actually use, I talked to customers and internal subject matter experts and dove into details of common lab assays to understand how scientists take raw data from instruments and translate them into meaningful insights.

What we learned:

• Analysis leads to reporting. Scientists analyze data to draw conclusions and share progress.

• Not everyone’s data-savvy. Lab scientists know analysis software, but struggle to write queries, joins, or combine data from multiple sources. They want point-and-click, not code.

• Exploration over automation. For science teams in early research, analysis is messy, iterative, and open-ended. (This differs from teams in development and manufacturing, where assays and analyses are standardized.)

• Analysis is branching. Scientists often need to view the same data at different levels. For example:

  • Heat map of plate results

  • Table of results by standards

  • Table of average results per sample

  • Table of a plate’s summary statistics

Early Concepts

Based on these research insights, our engineering team chose to model analyses as a Directed Acyclic Graph (DAG), where the nodes are datasets and the arrows are “analysis steps”, a data transformation that takes dataset(s) as input and outputs other datasets or charts.

With this understanding, my early concepts were UI frameworks for showing relationships between data inputs and outputs.

Using principles to guide decision-making

We had several promising concepts, but without definitive feedback from users or the team, we were stuck without a clear direction.

So, I went back to our research findings. Working with my PM, we aligned on a set of product principles based on research that we then used to evaluate design concepts:

• Analysis leads to reporting → Outputs should be organized.

• Scientists aren’t always data-savvy → Follow conventional data analysis UX.

• Exploratory over repeatable → Support iterative, exploratory experiences

• Analysis is branching → Parent/child relationships should be obvious

These principles became our North Star, and we used them to turn subjective opinions into objective decisions.

Design x Product x Engineering collaboration

As we moved into detailed design, I realized that showing mockups wasn't enough to communicate the behavior we needed. What happens when a scientist masks a data point in one chart? How does that affect downstream visualizations?

To bridge the gap, I created visual diagrams that explained data transformations and their ripple effects through the analysis. These diagrams became a shared language for the entire team, aligning mental models across functions.

Elevating design craft and delight through details

When I started this project, I thought data analysis was something scientists just had to get through… a means to an end.

But during research, I discovered something unexpected: seeing results come in after days of experiments is the most exciting part of their job. (I didn’t realize data analysis could be… joyful! ✨)

That insight changed how I approached the design. If this was a meaningful, even emotional moment, the tool should feel that way too. I introduced small moments of delight - custom chart icons, thoughtful use of color, and smooth transitions - subtle cues to make the product feel approachable and even delightful.

The solution

From raw data to insights, all in one place

With the launch of this new analysis tool, scientists can now:

• 💖 Combine, filter, and visualize datasets within Benchling

• 💖 Build and iterate on analyses without writing code

• 💖 Maintain full traceability across experiments

Impact

The tool has become a key selling point in enterprise deals, including with a major pharmaceutical company. It’s a win for both sides:

• Scientists ❤️ the intuitive experience and sense of ownership over their data.

• IT and business stakeholders ❤️ the traceability and platform consolidation.

What I learned

Clarity is a superpower
By using diagrams, flowcharts, and storyboards to communicate complex technical concepts, I influenced product strategy and unblocked engineers - often more effectively than showing UI mockups.

Keep humans at the center
Rather than simply translating backend decisions to the frontend, I advocated for user-friendly concepts and terminologies that resonate with scientists who don’t typically have a data science background.

Principles turn ambiguity into progress
Defining and aligning around shared principles turned ambiguity into progress. If I could do this project again, I would have done this even sooner to drive decisions faster.

Focus on leverage, not coverage
I learned to prioritize the high-impact decisions that clarify direction or unblock teams, rather than trying to solve every edge case upfront.