Strateos users spend a lot of time reviewing the datasets generated from experiments they run on our platform. The data viewing and interpretation tools available to life scientists today are surprisingly limited, and a powerful feature of Strateos is the ability to immediately explore and understand data right in the Strateos Console.

At the start of this project, the dataset experience had suffered neglect and needed UX and engineering improvements.

In this post, I'll describe the efforts of our growing Strateos Design Team to build a better dataset experience for our users.

Problem Definition

Strateos offers full transparency into the data captured during an experiment. When our platform executes a user's experiment, the system presents the data collected as soon as it's available in a visually rich format. This immediacy and ability to visually review is a huge value-add for our users.

However, before this project, the UI architecture for viewing and analyzing datasets in the Strateos Console was aging. Our users love having specific data visualizations for different types of experiments, but maintaining these many views was time-consuming and prone to bugs. Dataset views often broke, and adding new views required extensive custom coding.

The as-is experience for viewing datasets prior to this project was prone to bugs and visually messy.

Furthermore, our approach to generating datasets had challenges. When a user requested to download a dataset, it was generated on the fly using the current state of the system. This caused inconsistencies between downloads and prevented proper auditing – which can be problematic for scientists.

Finally, the existing interface lacked clean aesthetics and made it difficult for users to quickly interpret their results.

Stakeholders

Working from the initial framing of this project, we identified the following stakeholder groups for which the team's solution would need to work:

Scientist Users

The external users of Strateos hold many different titles, from Lab Managers to Accountants to Scientists. However, Scientists are typically the only members of a team that analyze datasets, so their needs will be the focus of this project.


Internal Scientists

A good portion of Strateos's daily users are Strateos employees, responsible for customer success, scientific development, or simple lab maintenance. These individuals are frequent consumers of datasets.


Software Engineers

As Strateos adds new scientific capabilities, our engineering team is responsible for building out the accompanying dataset visualizations. Our proposals need to reduce the engineering team's burden and likelihood of introducing visual bugs.

Job To Be Done

The Design Team and Strateos's Head of Product developed a single Job To Be Done to guide this project. A solution that addresses this Job To Be Done will address the individual needs of each stakeholder group.

As a biologist using Strateos, I want to view and access the data generated in an experiment in a single location, so that I can quickly understand if an experiment was successful, and know how I should proceed with my work.

Research and Exploration

User Research

Synthesis artifacts following user research.

With our job-to-be-done in place, we began a round of extensive 1:1 interviews with members of each stakeholder group. From these conversations we identified the following pain points:

  1. Scientists struggle to quickly understand the basic outcome of their experiments, due to a cluttered interface, the need to download data files before viewing them, and changes in display between datasets from different experiments.
  2. Scientists have no way to understand the state of the world when their data was generated, such as how much liquid was in a container when it was measured. This makes it extremely difficult to understand why an experiment might have failed.
  3. When Scientists need to compare values from multiple datasets, their workflow is slow due to a poor navigation experience.
  4. Scientists struggle to access the specific data they need from an experiment, and often end up downloading far more data than necessary.
  5. Internal Scientists struggle to release new features to customers in a timely manner due to the long time required for software engineering to implement new dataset views.
  6. Software Engineers must spend many hours duplicating and modifying UI code from other dataset views in order to implement new ones.

User Needs

From these pain points, we narrowed the scope of the project down to four core user needs:

Determine Success

Biologists need to understand if an experiment was even modestly successful so that they can determine if a dataset is worth analyzing further.

Explore Data

Biologists need to be able to sort, search and filter their data on the fly so that they can compare datasets and gain a deeper understanding of the results.

Specific Views

Biologists need to view datasets in layouts and visualizations specific to the type of experiment that was run.

Quick Implementation

Software Engineers need to quickly create new Dataset views without duplicating existing code, or introducing visual regressions.

Goals

Our task was to provide a re-designed user experience for navigating and accessing datasets. The core requirements were:

  1. Extensible: The proposed solution must work in a variety of contexts, and be easily adaptable to future needs as new dataset types are added.
  2. Audit-able: It should be clear when a dataset was generated and apparent that the data contained within a dataset is static and represents a past state of the system.
  3. Compose-able: Datasets are made up of Data Objects, and this solution should visually mirror that architecture.
  4. Useable: Biologists have well defined approaches to data. Our solution should not dictate a preferred approach but instead meet Biologists where they stand.

Our initial sketches focused on the core components needed to appropriately display data objects, with some basic attention paid to layout. These sketches were foundational to the final architecture proposed.

Architecture Brainstorming

Our sketches produced the beginnings of a visual system, which we decided to develop into a full framework from which a multitude of layouts could be composed.

To develop this framework, we detailed all of the data types Strateos supported. Then, we audited the Strateos database to find the following most commonly executed experiments:

  • AutoPick
  • Plate Reader
  • Flow Cytometry
  • qPCR
  • Aliquot Measurement
Original brainstorming sketches for development of dataset visual system.

In the interest of solving for the third user need, we drew on our learnings from our scientist users and developed layouts optimized specifically for these common experiment types.

Final Proposal

Based on this exploration, we proposed a four level hierarchy:

Primitives > Layouts > Templates > Summaries

Primitives

Primitives are the basic visualizations we support. They are the atomic units from which all dataset views can be created. I designed and coded five of them, along with a set of Data Visualizations.

Image

Images of containers allow scientists to understand the physical state of their container.

Image Data

Code Block

JSON snippets can be displayed in a formatted view when no superior visualization is available.

code-block-primitive-1

CSV

CSV Data Objects can be displayed along with searching and sorting capabilities.

csv-primitive-1

Plate Map

Data Objects that represent single values for wells in a plate can be visualized as a plate map.

plate-map-primitive-2

Table

Structured data not stored as a CSV is rendered in a table layout.

table-primitive-1

Data Visualization

Often, basic plots and graphs help scientists digest an experiment's results. This set of data visualization primitives addresses the vast majority of our user's needs.

Layouts

Primitives > Layouts > Templates > Summaries

The next level of the hierarchy is Layouts. While a large number of possible arrangements exist within our 12 column grid, we selected a small subset for use in datasets. This allows us to write template components and reduce the engineering overhead of implementing new dataset views.

12 Column Layout

Visualizations that use only a single primitive make use of a basic, full width layout.

9:3 Column Layout

Smaller graphics with more substantial supplemental data leverage a 9:3 layout.

10:2 Column Layout

Graphics that benefit from larger scale can display a small amount of supplemental data alongside in a 10:2 layout.

Templates

Primitives > Layouts > Templates > Summaries

Layouts are used by Templates for clean, consistent content display. We defined four types of templates, each of which leverages one of the predefined layouts shown above. Every Template presents structured data, often previewed with a graphic such as a Plate Map or Data Visualization.

Drawing on our initial visual exploration, we mocked out high-fidelity examples of each template type.

Single Data Object

Used when no graphic representation of the data object is readily available. This Template is intended to be used sparingly, as the user needs are best addressed with visual representations of data.

single-graphic-template-1


Main Graphic with Supporting Data

Used when the primary user need is to see visual patterns in the data. The supporting data helps provide context for the visualization, helping to solve for the second user need.

single-graphic-supporting-data-template-1


Structured Data with Supporting Graphic

Used when the primary user need is to see and explore structured data. The user is looking not for a visual pattern, but rather to scan a set of structured data.

structured-data-supporting-graphic-template


Main Graphic with Supporting Graphic and Data

Used when the primary user need is to see visualized data for recognizing patterns. The supporting graphic and data provide more structured views of the same data.

main-graphic-supporting-graphic-structured-data-template

Summaries

Primitives > Layouts > Templates > Summaries

Finally, datasets of specific types are represented as a Summary View that leverages one or more of the Templates. A Summary View brings the entire framework together and presents specific layouts for different experiment types, answering for the third user need. The key features of a Summary View are:

  • Understand the type of instruction the dataset was created from, along with the time it was created, and the robotic infrastructure on which it was created, offering invaluable context to the user.
  • Quickly download either all of the raw data for a dataset, or single data objects, for use in other analysis tools.
  • See the details for the physical container from which data was collected. This is critical information that helps scientists contextualize the results.
AutoPick, Plate Reader and Flow Cytometry

These are some of the most common experiment types Strateos users run. All three can be represented using a Graphic with Supporting Data template. The data from these experiments are best represented with visual primitives such as a Plate Map or Image, and then supported with data points from which those primitives are rendered.

plate-reader-summary

qPCR

The qPCR dataset is a workhorse of the Strateos platform and users need to explore this data in a multitude of ways. A Graphic with Supporting Graphic and Data template allows the display of time series data, as well as specific data from each time series. A Line Chart is used as the base of the qPCR plot, and is the main graphic for quickly visualizing and understanding the success of the experiment. A Plate Map and its associated data is used alongside the line plot to provide additional context.

qpcr-summary

Multiple Aliquot Measurements

The Data Object details are rendered in the header. A CSV of the measured data, and a bar chart of the data are passed to the Aliquot Data with Supporting Graphic template.

multi-aliquot-measurements-summary

Fallback Summary

It is possible for a Dataset to be created that does not have a valid type. In this case, a simple list of Data Objects is displayed. For files such as JSON/CSV, a preview is shown.

file-summary

Results

The nature of this proposal allowed for a healthy development process. While fellow engineers focused on backend modifications, we tackled the implementation of the Primitives and Layout components. This allowed our team to work independently and quickly at first. Then, with the various components in place, we collaborated to tie all the pieces together.

Screenshot of a user's qPCR dataset taken from the Strateos Console.

Overall, the project was incredibly well received by internal and external users. We heard from our own employees and our users that they found their datasets far more approachable, and that they were able to evaluate the outcome of an experiment at a glance – success!


If UX and design for science interests you, we would love to hear from you on twitter and we're always looking for great people to join our mission at Strateos.

Careers at Strateos | Strateos
At Strateos, individuals are empowered to think creatively to solve problems and answer hard questions with well researched data. We work in an collaborative environment where everyone is encouraged to do their best work supported by a team of peers.