DNA Annotations Redesign

Benchling logo
Biologists annotate strings of DNA sequences to demarcate what and where different genes are involved in their experiments. Benchling provides software that allows users to digitally capture annotations, but the captured annotations were difficult to manipulate, edit, and lacked visual continuity with other parts of the product.
Redesigned full screen view allows users to view, edit, and manage their DNA sequence annotations.
UX Designer, Spring 2022
Worked directly with the project manager and engineering team to define, develop, and deliver a decision based on existing problem discovery.
A full screen gif of a user adding notes to the Notes column of the annotations view.
a nonsense string of DNA
Scientists work with strings of DNA made of up individual letters, or bases, that “spell out” the instructions telling a cell what to do. A sequence typically looks like this:
  1. Continuous visibility of system status, especially when users are in a "split screen" view
  2. Reduced reliance on recall when browsing or manipulating annotations
  3. Increased accessibility of information, especially when considering extraction of stored annotations data  
  4. Aesthetic and intuitive design using latest design system
...and it goes on for hundreds or thousands of bases. While cells can comprehend these instructions, humans need additional notes to understand which sequence sections contain information for which genes, and what each gene does. Scientists use annotations to store that information, and are constantly updating the annotations with new metadata and information they gather through experiments and literature review. It’s similar to an electrical wiring diagram for the wiring of a house. It’s difficult to walk into a house and know exactly how to install an electric cooktop, but having the diagram available gives you the knowledge you need to manipulate the system. In the same way, it’s important for scientists to be able to have annotations - their wiring diagram - accessible to plan experiments and understand unexpected outcomes.

I came onto this project after the discovery phase had already been completed. These were the following areas I focused on for this redesign.
a screenshot of the Benchling product with 3 boxes. The first box is around checkboxes, the second around the name column, the third around the notes column.
Reimagining annotations as a database
While there were several factors driving this redesign, the primary reason was that users experienced frustration when adding and extracting metadata from annotations. Scientists often used annotations with the assumption that a "standard" set of information would be available and manipulatable. The existing presentation of the "standard" information in Benchling was in an unstructured Notes field, forcing users to recall what information is available, preventing field-specific filtering, and causing exported data to be difficult to integrate with common industry platforms.
Screenshot of metadata fields on ENSMBL.Screenshot of an annotation on Benchling.

Metadata fields on ENSMBL, widely considered as the provider for a "standard" set of metadata.

A single annotation and its associated metadata on Benchling.
While there were a number of ways to tackle lossy metadata organization for annotations, reimagining the collection of annotations as a database, with customizable fields made of key-value pairs, was the method that maximized user control over input, manipulation, and extraction of metadata. Annotations-as-a-database laid the groundwork for how I thought about functionality and presentation of annotations.
Design Exploration

Enabling bulk actions

Once we decided to treat annotations as a database, I considered different ways to surface annotations and associated metadata to users. Users could already see annotations labeled directly on the DNA sequence. They had to open the expanded annotations panel to see the metadata attached to an annotation.

Screenshot of the Benchling product showing how to pair annotations in the DNA editor with annotations int he annotation viewer.

Annotation labels on DNA on the left side of the split workspace, and the expanded annotations view with Notes available on the right side of the split workspace.

Some options, such as using cards for each annotation, were initially attractive because they were more visually clean. However, based on stakeholder interviews, I discovered that the top two reasons users arrived at the annotations view was 1) to make bulk edits to several annotations at once, and 2) to compare metadata between two or more annotations. Recognizing that bulk actions were the workhorse of this view, I decided to use a toolbar as a space to for users to initiate bulk actions. This brought bulk functionality to the forefront of the view and made many hidden functions much more discoverable to users.

Screenshot location of buttons for 1) bulk filtering, 2) bulk visibility, 3) annotation creation and 4) bulk editing. They are scattered around the screen. arrow pointing left to rightScreenshot location of buttons for 1) bulk filtering, 2) bulk visibility, 3) annotation creation and 4) bulk editing. They are now aligned in a neat row

1) Bulk filtering, 2) bulk visibility, 3) annotation creation, and 4) bulk edit scattered across four different areas.

1) Bulk filtering, 2) bulk visibility, and 3) annotations creation condensed into a single area. 4) Bulk edit visually communicated with text edit highlighting.

Creating new custom fields and annotations

Creating custom fields was a new functionality that wasn't previously available for annotations. My hypothesis was that creating a flow with high familiarity would be easiest for users to discover and learn, so I considered borrowing from existing patterns of interaction seen in many other table-based softwares and using a new column that could be edited in place

A two-step flow for adding custom fields that allows users to edit in place. While a common pattern, additional research uncovered use cases that this pattern could not support. On to more iteration!

Two screens demonstrating a flow to add custom fields. The first screen has a drop down to click "Add Property to Annotations". The second screen has a new custom field generated in table and a text box to enter the custom field name.

However, there were several scenarios where a user might want to add metadata to an annotation, but not necessarily have all the information available to fill out an edit-in-place column.

Three persona quotes
"I forgot I already had a custom field capturing this type of metadata and ended up with information about this characteristic spread across two columns." 
"I work with a collaborator on this sequence so I'm not immediately aware of what custom fields have been added for this sequence."
"It's hard to horizontally scroll through all column headers in a long table."

The trade-off of data quality for ease of custom field creation was not favorable, especially when a key use of capturing this metadata is for clean data exports for downstream use in the R&D workflow. I iterated through a few other possibilities to add custom flows, and eventually landed on one with an automated search for existing columns with the same column name. This safeguarded against data quality loss and removed reliance on recall.

Three screens showing ideas for how to add columns. The first is a popup modal to add property to annotations and has a drop down to select the field. The second is also a pop up modal, but has an autofill enable search to select the field. The third is a dropdown from the bulk toolbar that has an autofill enabled search to select field or add new field.
One of the biggest challenges of this project was that it occurred on a very short timeline. This required making some trade-offs—for example, working with existing discovery material and iterating with project managers rather than customers. This project sits in the 'Define' and 'Deliver' stages of the design process. While I'm confident that the design decisions I made address the needs and constraints presented to me, I'm aware that they all come from a place that's a step abstracted from the user and require more testing to deliver on a final solution. Ultimately, I appreciate that my work is just one step in what is a much longer process.

Overall, this project gave me real insight into how easy it is for product functionality — especially older, more obscure, highly specific functionality — to easily become unsynced from product design systems. Though much of what I described above were interesting design problems to work through, some of these problems may never have arisen if the annotations function had been regularly updated as Benchling's design system and language evolved.