Endothelial Cell Data Visualization Dashboard

Duration: 10 weeks; June 2023 - August 2023

Organization: Allen Institute for Cell Science, Seattle, WA - Internship

Role: UX Design Intern

Team: 6 members

Tools: Figma, Miro

Project Type: Desktop Prototype

Overview

The Allen Institute for Cell Science’s Animated Cell UX team researches and designs internal cell visualization tools to ensure they are user-friendly and long-lasting. Internal endothelial cell scientists needed a tool to visualize public single-cell RNA sequencing (scRNA-seq) data from endothelial cells. 

As a UX Designer, I was tasked to:

  • Identify main user problems and needs through stakeholder analysis and interviews.

  • Synthesize research findings into functional requirements for the development team to quickly follow.

  • Prototype concepts and iterate based on feedback from the UX team and usability testing.

  • Provide design recommendations for a dashboard made using Shiny, a program that develops web apps

UX Double Diamond

Fig. 1: To ensure the dashboard would fulfill scientists’ needs, I adhered to the UX Double Diamond design process to guide my ten weeks of the internship.

Discover

I came into this project with little background knowledge of endothelial cells. The endothelial team, a group of scientists researching this cell type, often use visualizations to understand genes and their features.

I scheduled discovery interviews with potential key internal users of the dashboard to get a better understanding of this space:

User Interviews

I aimed to figure out the problems users experienced in previous tools:

  • I made an interview protocol and talked to 6 internal scientists and research associates connected to the endothelial team and their work.

  • I also crafted a quick page mockup to see how interviewees would react to its layout (see Figure 2).

  • Most importantly, I discovered key problems they ran into using previous tools and features they would like to use to optimize their research.

Fig. 2: An example dashboard page I prepared to facilitate conversation and thinking with interviewees; created to give interviewees context into what the dashboard could look like + gain an initial understanding of what they would like to see.

Comparative Analysis

First, I explored other internal tools published by the Allen Institute to see how they were laid out and the type of information included. This:

  • Informed the questions I asked interviewees

  • Gave a better idea of the tools interviewees used in the past and what they might be comfortable with

  • Uncovered patterns across internal visualization tools (visual layout, ability to export plots)

  • Highlighted features to potentially include (ex: onboarding process for new users, clearer written content)

User Flows

I created user flows (see Figure 3) for the main user interactions to understand common scenarios and identify gaps in research.

This method ensured mockups efficiently captured the tasks scientists needed to complete.

Define

After gathering a mess of information and findings, it was time to organize everything into focused points.

Fig. 3: Flow for a user interacting with the Gene Expression (GE) tab. Shows worst-case scenarios (ex: errors) to consider.

Finally, I took the information from interviews, responses to the low-fidelity mockup, and the comparative analysis to create a list of functional requirements to present at my weekly project meeting.

Functional Requirements:

  • Ability to download/export plots

  • Ability to create a new plot (with default selections)

  • Guide to explain plot differences (could be in an “Information” section). Ex: how to use the plot and definitions, etc.

  • Error handling (ex: if no data is available, if dashboard doesn’t load, if plot cannot render after x amount of time)

Nice to haves (for future versions of the dashboard):

  • Ability to save a plot view so that when a user exits the tab, they don’t have to redo creating the plot

  • Ability for users to set their default view

User Personas and Problem Statements

Through interviews, it was apparent that there were three main personas who would be using the first version of this Shiny dashboard. With each came a different problem statement curated to highlight their goals and frustrations:

  1. Scientist with high background knowledge of data

    • “I have a wide breadth of knowledge on this subject matter, but do not interact with the data directly. I need a method to see a more approachable view of the data through visualizations. The Shiny apps I have used in the past were also hard to use and confusing, making it harder for me to complete my work.”

  2. Research associate who indirectly works with the data

    • “I have never used Shiny applications in the past, but since I learn best through visuals, I would like to try out new methods to better inform my experiments. I also want to share polished visuals to better communicate my findings with my team.”

  3. Scientific manager

    • “"I need a quick method to validate my findings against the scRNA-seq dataset. I need a simple-to-use and customizable tool that will allow me to quickly view data visualizations.”

Develop

I created 6 low-fidelity mockups. Keep in mind: these mockups would change as project goals became clearer; for example, halfway through the project, the development team realized another page for a new type of plot needed to be added:

Mockup - Version 1

First mockup of the main three data plot tabs.

Mockup - Version 2

At this point I was trying to pin down the most important user interactions. I highlighted and circled main interactions to present to the development team for confirmation and edits. This mockup also showcases bigger plot sizes and different dropdown filters based on interview feedback.

Mockup - Version 3

A few interviewees mentioned wanting the capability to add a new chart to an existing page. I met with my mentor to ideate layouts for this potential feature and present it to the development team.

We proposed quick buttons below the main plots where a user can click on common plot types to generate; or, they can create their own from a blank chart option:

This feature was unable to be implemented due to project time constraints.

Mockup - Version 4

Final mockup before moving onto high-fidelity prototype in Figma. Represents all needed pages and the features feasible to implement for this version. This mockup includes an added tab (“Box Plots”), which the development team wanted to add so users could explore the dataset even further.

Deliver

I conducted usability tests with the development team’s working dashboard in order to validate the designs and find any obstacles to solve before official publishing. I used feedback from these interviewees to guide my high-fidelity prototype made using Figma.

Usability Tests

I conducted 5 usability tests with the same interviewees (one of the original interviewees had schedule constraints and could not attend this second round). Their insights informed the tasks I needed to complete for delivery by the end of the summer:

  • 50% of interviewees manually scrolled the dropdown of 4,000 genes before being prompted by the interviewer (me) that they could manually type the name in.

    • Proposed solution: Rewrite dropdown text to let users know that they can manually type a gene.

  • The ability to download plots is important to all users for presenting research and making comparisons.

  • 100% of interviewees wished to have descriptions on each tab describing what the plots are showing.

    • Proposed solution: Prioritize the “Help” button on each tab. When clicked, a modal appears with insight into the plot and how/why to use it.

  • 100% of participants had issues with size of plots. They would prefer the full plot scaled.

    • Proposed solution: Plots should be scaled so that they are fully on the page and that a user does not have to scroll down to see the full image.

  • General polishing of color and font size for readability.

Final Deliverable & Takeaways

After 10 weeks of work, I was able to present a final design recommendation to the development team. I went through another 8 different versions of the high-fidelity prototype after helpful design reviews with the UX team.

Instead of having >10 plots displayed on a singular page like past internal tools, I was able to respond to user concerns by recommending a cleared, more direct design aimed to improve scientists’ experience visualizing the endothelial dataset.

Impact

My final tool template was implemented for use by 8+ end-users and is now published internally as a template for subsequent Institute products:

Image of final prototype

The Allen Institute emphasizes on open science, and as part of this goal, has all interns present their projects to the building. I created a poster documenting the design process, presenting this project to over 500 employees:

Previous tool’s layout - disorganized and hard to understand as a new user

Takeaways

  • The process of creating useful tools requires research and iteration: continuous feedback from main users and UX professionals.

  • Design is not just problem-solving, but problem-finding: understand user perspectives and focus on core obstacles.

  • Working alongside a development team means keeping in mind feasibility when making recommendations.

  • UX can be applied to every field. Scientists and researchers use tools that may not have been made with their needs in mind due to time and budget constraints. The Allen Institute is fortunate to have resources available where a UX team can come into a project and research how to optimize these tools.

  • Enhancing the user experience of scientific tools has a direct impact on the world and biology; while we may be designing for a smaller internal team, the work they are able to complete with a more intuitive dashboard will further discoveries in the field.

Work for future iterations

  • I could not track certain metrics since this project started from scratch. In the future, I would want to interview users 6 months after the app is internally published to see if the app streamlined users’ work or reduced their steps to visualize this data.

  • Add hover descriptions to table columns.

  • Dynamic scaling across the application for accessibility on mobile and tablet versions.

What would I have done differently?

  • Set clearer deadlines

    • This was the first time the development team had worked with UX, so it was a learning curve for both specialties. If I could go back, I would be more intentional about explaining the reasoning why we needed to implement a feature based on user needs, along with the importance of conducting thorough research before proposing designs.

  • Interview more users who had never used a Shiny application before

    • All the users interviewed work at the Allen Institute, meaning they have varying levels of understanding of the visualization tools teams used. It would have been helpful to interview users who have never used these tools before for true testing.

New tool’s design recommendation based on scientists’ needs. Click on the laptop to view all pages!