SAS GUI Redesign
Background
Lodestone is a startup that is developing a groundbreaking nanoparticle technology to improve monitoring of immunotherapy treatments and accelerate drug discovery. They developed a readout system to detect and quantify a pathogenic protein with minimal invasiveness. They are now looking to redesign their UI to better support immunology researchers throughout the process.
Overview
My role
UI/UX Designer in a team of 1 designer and 1 developer
Overview
Objective
Redesign Lodestone’s user interface to be an intuitive and functional GUI that guides the user through the necessary steps of the process without error; Restructure UI information and content.
Scope
January - June 2023
Internship and design project for Masters of Engineering
Outcome
A 65% increase in user’s satisfaction with our newly implemented system
A 45% decrease in user support requests
The identification of 6 new features
A 50% decrease in development time and an increase in market competitiveness
Our Contributors
As part of our course, Cook Engineering Design Center (CEDC) connects students with industry partners to solve real-world problems. Our sponsor, Lodestone Biomedical, is a biotechnology company whose mission is to enable immediate detection of treatment response in support of precision medicine across cancer therapies and emerging immunotherapies. The company’s technology provides non-invasive, longitudinal, real-time monitoring in the tumor microenvironment, which will accelerate clinical trials and enable true precision medicine as the new standard of care. The technology is used in the Gaur Lab at Dartmouth Hitchcock Medical Center by students of Geisel School of Medicine.
Before
After
To see how we got there, keep reading!
Process
Researching the Problem & the User > Creating Flowcharts > Sketching > Wireframing (Grayscales) > Low-fidelity Prototyping > High-fidelity Prototyping > Usability Testing > Final Version
Research
User Interviews
To better learn about my user demographics for whom I am designing, I conducted interviews with the current users of the interface to better understand the shortcomings of the current design and to identify their needs and wants. I also developed an empathy map which helped me identify what our users are struggling with and where in the process this is occurring.
After conducting the interviews using the current design of the interface, several pain points became evident:
1. Inaccessibility to non-expert users
The process of data collection using the SAS technology is very complicated and intricate. There’s a lot to learn about the system and the learning curve is steep.
2. Tool guidance
Because there are so many steps to working the SAS and navigating the interface, tool guidance through the entire process is very critical.
3. Streamlining the process
The current design requires that users interact with both Reaper and the SAS interface. Removing the need for users to use a second software is critical for simplifying the workflow.
User Persona
I combined my user research with data on existing biomedical technologies in order to create a persona representative of the target market.
After identifying our user persona and conducting user interviews, the need for some features became evident:
Multiple Interfaces: the old GUI required the user to interact with Reaper, a digital audio workstation software that was used to calibrate the SAS before taking measurements of a sample. The user would first launch Reaper and then manually calibrate the SAS. This entailed editing complex settings that a non-expert user would be incapable of navigating. Eliminating the need for additional interfaces was a priority for the design of the new GUI.
The new interface would automatically turn the field on after calibrating the SAS and then also automatically turn it off upon completing data collection.
It would also allow for easy calibration to streamline the process, save time, and eliminate unnecessary complexities.
Need for interface guidance: due to the complex and intricate nature of the process from start to end, as illustrated by the current workflow that entails so many steps and interdependencies, the new GUI needs to walk the user through the process as smoothly as possible. The previous GUI was made up of one page that contained several buttons, with no guidance on what to press and when.
The new GUI needs to guide the user through the necessary steps, and prompt them to do sanity checks often to ensure proper operation of the machine and quality assurance of the measurements made.
Need for interface confirmation: the previous GUI asked for user’s confirmation when prompted to carry out actions that affect the acquired data, such as aborting data collection and clearing the measurements made.
The new interface maintains this added layer of protection, as data acquired is very valuable to the user and continues to be our priority.
Login Page: the previous GUI had no Login Page, which could potentially create issues when files would get accidently deleted or edited. Since we knew that the SAS would be used by multiple users/labs within the facility, it was determined that accounts would be necessary.
Structure of Hierarchy: the previous GUI showed no hierarchy whatsoever; it had a flat structure. The user would input the data for a single experiment before proceeding to take measurement of the sample. After talking to users, it became evident that a hierarchy is necessary to streamline and speed up the process. The finalized structure is:
Information Architecture
To better understand the workflow of the current system and interface, I created a flowchart of the entire process as well as one of the current UI. This helped me identify steps that I can combine or get rid of and ways to create the ideal user path.
Wireframes
Wireframe Sketches
I came up with a few early sketches for the interface in order to determine which components worked best together.
Responsive Wireframes
I then adapted elements from my earlier sketches to create wireframes for key pages on desktop.
Low-fidelity Prototypes:
Following our industry and user research, flow sketches and grayscale wireframes, we developed low-fidelity prototypes to explore different layouts for the pages. In the iterations we explored:
Different page layouts to uncover alternative ways of providing tool guidance through the various steps. These included presenting the different steps as pop-ups, tabs (horizontal or vertical), or a combination of both. These iterations were crucial in deciding the right balance between user navigation (manual) and interface prompted navigation (automatic).
It was decided to settle on a combination of horizontal and vertical tabs, with the horizontal tabs representing the general high-level steps and the vertical tabs including the substeps (lower level). Based on user feedback, tabs feel more familiar as a way to multi-step processes.
Steps as pop-ups
Steps as vertical tabs
Steps as horizontal tabs
Steps as combination of horizontal and vertical tabs
Final version
Different ways of inputting data for each run/scan. We first started by dedicating different pages for each substep.
After speaking to users, it was evident that we were losing users the more clicks they had to make.
We ultimately decided on condensing all substeps in one page. This allowed an easier way for users to input data, as well as provide a visual record of each run. The condensed version also allowed users to quickly transition between, add, and remove characteristics and parameters. This layout provided users as much flexibility as possible in the data inputting stage.
Before: users had to click on tabs to navigate through the substeps
After: users can just scroll-down (all sub-steps are in one page)
Internal and external flows to discover the best methods of integrating the longitudinal measurements and their visualization into the plotting tab.
The previous interface showed only one type of graph, as it only allowed running individual scans.
After speaking to users, we were urged to consider adding a button to toggle to switch between different graphs. This feature would eliminate the need for users to export data and plot graphs on their own.
Various visualizations for the live plots.
After discussing with users, it became apparent that displaying the values of the x and y-axis numbers in a table was completely redundant and provided no additional insights than the ones shown visually in the graph. We thus decided to get rid of the table and instead make the graphs more interactive, showing values on hover.
Before: only one graph with table on the side
After: multiple interactive graphs
Different ways to edit previous experiments, studies, and runs.
Studies can easily be edited and changed since info needed to define a study does not affect the data previously acquired. Experiments, on the other hand, can only be modified partially. A user can change biosensor and subject data, but not scan parameters. Changing scan parameters without rerunning scans simply renders previously acquired data and plots invalid. Similarly, a user cannot edit runs, but can create copies/clones that they can modify. This ensures quality assurance of data acquired throughout the process.
Previous studies can be edited
Previous experiments can be partially edited
Only clones of previous runs/scans can be edited
Finding the balance between accommodating non-expert and expert users.
After talking to users, we discovered that some reminders that are very helpful for non-expert users may become tedious and bothersome. Having a pop-up that asks the users to check the temperature on the machine is critical for novice users who have not used the machine for long, but will probably be an unnecessary feature for expert users who have gone through the process countless times.
After talking to users of similar medical interfaces, it was established that it is standard to have reminders and sanity checks for all users. This ensures that the data acquired is valid and correct, which is very important when conducting experiments that would cost a lot of time and money. It minimizes the chance of error and is a great measure to ensure accountability.
Key pages from the low-fidelity prototype:
Log-in page
Creating/editing studies
Creating/editing experiments
Experiment set-up page
Creating/editing subjects
Calibration page (within each run/scan)
Scan description page
Plots page
High-fidelity Prototypes:
Colors
After analyzing and prioritizing user feedback, I started brainstorming appropriate color palettes for the interface. I created different color iterations and ultimately ended up choosing the last version. I chose blue and orange as my primary and secondary colors respectively, as blue provides a “clean and calm” interface – exactly what is needed while navigating through Lodestone’s medical interface. Orange, on the other hand, brings attention to key features and is a nod to the company’s name which means mineral magnetite.
Iterations:
Final version
After exploring different styles, I created a few provisional UI components in accordance with atomic design principles.
After deciding on the colors of the interface, I created the high-fidelity prototype and tested it with our users, to get their insights on the final version of the GUI.
Usability Testing
To evaluate the efficacy of the interface, I conducted usability tests on 5 users. The main areas for improvement were:
1. Default values
Most non-expert users would not know which values to use for calibration, if not specified by their PI. Having the option of using default values reduces the chance of error and ensures quality assurance.
2. Quick scans
Although having a structured hierarchy when conducting studies is very helpful to keep the users organized, it is a very long process if the user is interested in running a quick scan.
3. Order of steps
Users need to fill out the scan description page before proceeding to calibration, since some of the values inputted in the description page are needed for calibration
Final Version
After analyzing and prioritizing the user feedback, I iterated over the design and updated the prototype. A handoff document that explains the new features and details the reasons behind them is attached here.
This is a video of the final version. Feel free to look at the Figma Pages and play with the prototype!
Next Steps
Developing the Design
Lodestone is employing the services of Ryan, who was consulted throughout the two terms, to develop the GUI using PySide6 UI framework.
Parameter Sets Feature
Allowing parameter sets to be saved and uploaded to reduce the number of times users input the same data would be a great feature to have.