Designing with science in mind: How Benchling product design leader Rebecca Conway uses design to solve challenges for scientists

Kyrstin Lou Ward

Rebecca's interest in visual arts combined with her love of solving logical puzzles led her to the field of product design, where she's been working for nearly a decade. Her experience designing for complex enterprise SaaS products lent itself well to Benchling and the intricate tools scientists need to be productive. As a leader on the product design team, along with her colleagues, Rebecca works closely with customers to understand their challenges and craft intuitive user experiences that help scientists solve the world's most pressing challenges.

Can you tell me a little bit about yourself and about your role here at Benchling?

Rebecca Conway: I'm on the Product Design team at Benchling. Product designers at Benchling are generalists, so we do all aspects of the design process from research, to creating flows and wireframes, all the way down to working on visual design and design systems.

Often when people think of what we do, they’ll think of the craft aspect of design, putting pixels on the screen. That’s definitely part of it, but there’s more to the process. We partner closely with product managers to do customer research, define the problem we want to tackle, and then explore multiple solutions. We often put together clickable prototypes, so we can explore multiple design concepts, how they will work, and how the user will interact with them. Once we’ve narrowed in on an approach and validated it with users, engineers will start building the solution. Designers work closely with engineers as they are going through implementation. There's a lot of back and forth and communication that happens during that stage.

I really value having a lot of variety in my work and getting to work on many different things. I would never want a job where I do the same thing over and over again.

What do your interactions with customers look like?

RC: We're constantly talking to customers. We frequently have calls ranging from initial discovery before kicking off a project—defining the problem we want to tackle, figuring out what the customer's pain points, are and what their workflows look like—all the way down to validating a proposed solution.

Our work is very customer-centric. We're always going back to the user, getting feedback on concepts, or soliciting ideas from them. I really like that aspect of the design process because by communicating with our users directly, we’re able to get quick feedback and make sure we’re on the right track.

It sounds like your role is highly dynamic, highly collaborative, and very user-centric. With that in mind, what would you say are the guiding principles for your work?

RC: I would say the first guiding principle is just focusing on the customer and what they need. We are extremely customer obsessed here at Benchling. In other design disciplines, there's often less of a focus on the end user. In school I studied graphic design, which sounds like it might be similar. They're both digital, visual art, but they’re almost like night and day in the way you approach the projects you're working on. Graphic design is much more creative, and there are many more avenues you can take in your approach. Product design is based more in principles and patterns, in data and research. It's meant to solve a very specific problem and to help people get their jobs done faster and easier, in the case of enterprise software.

So I think, number one, make sure you are actually solving people's problems. Don't just create something that you think makes sense without validating it, or simply create something that just looks good. There's really no point in doing that.

We are making a tool to improve the work that scientists and researchers are doing. So everything we do needs to be in service of that. The work we’re doing has to solve real problems. That is probably the biggest guiding principle. I think that’s the golden rule.

“We are making a tool to improve the work that scientists and researchers are doing. So everything we do needs to be in service of that. The work we’re doing has to solve real problems. That is probably the biggest guiding principle. I think that’s the golden rule.”

—Rebecca Conway, Product Designer @ Benchling

What would you say distinguishes Benchling's users, the scientists, from other users you've designed for in your career?

RC: Previously I worked for Mode, and before that I worked for Sumo Logic. The user bases for those products include analysts and developers that spend all day at their computers, and that’s where their work happens.

Designing for the Benchling user is very different because we have to be aware of what they're doing in the physical world. That has a huge effect on how they interact with our technology. A lot of times, being on the computer is just one small part of the scientists’ day. They're actually out there doing science, and we are really just there to aid them. With Benchling users, the work happens elsewhere, and we're a helping hand for them to make that work faster and more streamlined.

What’s an example of something in the user environment that affects the design process?

RC: There's a Benchling application called Inventory, and that's really about keeping your stock of materials up to date in Benchling, so you know where everything is located and how much of it there is.

And so in the lab when scientists go to move some inventory around or get a sample from a freezer, they might be wearing huge gloves and they can't keep the door of the freezer open for very long because the temperature's going to change and there are all of these aspects of their environment to be aware of. And then they have to go back to their computer, remember everything they just did, and update their inventory within Benchling. Of course it’s also really important that the inventory was correct in the first place, so they knew exactly where to locate the item they were looking for in the freezer.

So in this case, things like making data entry much easier, much more seamless for them, is really important when there are all these physical factors going on in their real world. There are a lot more considerations about the user’s environment and their workflow when designing for Benchling.

It sounds like when designing for Benchling, the considerations are quite different from those at your previous companies. With that in mind, why did Benchling stand out to you? What brought you to Benchling?

RC: I was definitely looking for something different. I felt like I had been designing for a similar type of user for many years, being in the data realm for a while, and it was hard to personally connect to that. It also seemed like I was designing for products that were just out there to make companies more money. And so it was really hard to feel behind that mission.

I also wanted to challenge myself a little bit, learn a new domain, learn about a different industry. And I had never considered biotech at all.

When a recruiter reached out to me about Benchling, at first I thought, “I don't know if I can do this.” I didn't know if this was right for me, but I gave it a shot. I loved the people I talked to during the interview process and I was sold on the company and mission. It has just been so refreshing learning about something totally different, that I haven’t really thought about since high school, and getting to step into someone else's shoes when considering the scientists who use our product.

When you stepped into your role at Benchling, what surprised you most?

RC: I know I just talked about how I was looking for a change, looking for something different to challenge myself. But I would say the biggest surprise is just how much easier it was to design for a totally different domain than I thought it was going to be, because a lot of the patterns are just very similar across enterprise or B2B products. There are definitely certain aspects of Benchling that are very specific to science, but I could generally borrow patterns from products that I had worked on previously. And I think a lot of that goes back to the fact that, when you're doing product design, you don't want to reinvent the wheel. You want to design and build something that users are going to be able to pick up quickly.

You also mentioned that there are specific aspects of your work that are relevant to the science domain. Could you share an example of what that looks like?

RC: We have a molecular biology tool that we call molbio for short, and that is very much specific to the science domain. It’s used to visualize and manipulate DNA sequences. That is one that I could not have applied previous knowledge to. It is very particular and special to what it's meant to do.

I see all the different areas of the product on a spectrum, from very scientifically specific to more general. On the general side of things would be something like our admin settings and permissions, which are features that any enterprise tool will have. On the other end of the spectrum is our molecular biology tool. And then somewhere in the middle would be things like data entry or data modeling.

There is some scientific context you need to have when you're designing for our product, just to know about what objects our customers need to model and track within Benchling. But then there's a lot of general database patterns that you'd want to apply there, too. So it really does depend on the area of the product.

So with that, how has your role evolved over time? And over that time, how has Benchling supported your growth as a designer?

RC: As I have gotten to know Benchling better, to know our customers and their workflows better, I've gotten to work across more areas of the product. I think that's really valuable for designers because if you're just working in your one little corner of the world, you're missing out on understanding the user's end to end journey. But when you get to work across many different product areas, you can start to see better ways to connect the dots, better ways to make users’ workflows more seamless. You can spot redundancies, too.

As I've become more familiar with all areas of the product, I’ve also become more opinionated about larger scale changes that we should make within the product or areas where we should consolidate functionality or big gaps we have in the user experience.

Benchling has definitely enabled my growth, and it’s also helped me become more strategic. I feel like people at Benchling respect my opinion, and are looking for it. They’re not just thinking of me as someone who pushes pixels around, which can be a bad trap at a lot of companies.

“Benchling has definitely enabled my growth, and it’s also helped me become more strategic. I feel like people at Benchling respect my opinion, and are looking for it."

—Rebecca Conway, Product Designer @ Benchling

It sounds like your team, and Benchling overall, have supported your growth as a designer in several ways. With that in mind, how would you describe the culture on the design team?

RC: The biggest thing is everyone is just so willing to help each other. It's very important to be able to work with other designers who can help me to make decisions, who can provide feedback, who can be a sounding board. We are constantly asking each other for design advice.

We have a weekly critique where designers will bring their work to the table to get feedback. And it’s really important that we’re constantly in sync, too, for the user’s experience because it shouldn't feel like we are shipping eight different discrete products. It should feel like a cohesive user experience. So the more that designers can collaborate and provide feedback, the more the product is going to feel consistent and predictable to the user.

I feel that willingness to give time is definitely a big part of the design team. The team is also very low-ego. We are all very much focused on our goal, which is shipping a great product that solves problems. Even if it means you end up giving your project to another designer or it gets deprioritized in favor of something else. We don't care. We're just trying to get to that north star and do a really good job. And we recognize that we're all on the same team at the end of the day.

That leads in well to my last question: Which of the Benchling leadership principles resonates with you the most?

RC: So the one that comes to mind is something we’ve already talked about which is Obsess Over Customers. That's our north star—our guiding principle—that we solve problems for the people who are using our product. And so we do that by collaborating as designers, by talking to customers, using data to drive our decisions, validating our work, and not being too attached to one idea. And just always coming back to the person who will ultimately use it.

We try to understand who they are, understand their pain points, what their goals are, what they're looking for from Benchling, and we try to make their lives easier, try to make the work that they're doing more efficient and reliable, and whenever possible, try to delight them with our product. So I just think it definitely comes back to that, at the end of every day, we're doing this for our users, for those scientists and researchers out there who are doing really important work.

If you’re interested in product design at Benchling, check out our open positions.

Sign up for the Benchling newsletter

Get our latest insights and announcements every month.

Powering breakthroughs for over 1,200 biotechnology companies, from startups to Fortune 500s

Helix Image