Web App
•
Product Design
•
UX Research
•
Product Strategy
Company
Date
Hats Worn
Impact
Overview
The Zio monitor is a recording device prescribed to patients experiencing heart issues. The journey can be summarized into 3 high-level phases:
Patients wears Zio monitor on their chest for prescribed length of time, then ships it back to iRhythm
Internal techs use a QA tool to review and edit the data recorded by the device
PDF report is created and shared with the physician
This project was to design a new, cutting-edge version of the QA tool to replace the dilapidated, decade-old one technicians have been using.
Users
For the purposes of this project, we’ll focus on one particular group of users: scan technicians. These techs use the QA tool to open records containing ECG data from patients, review/correct the data, and generate the final report PDF.
My Role
I was the lead, end-to-end product designer, while also taking on additional responsibilities at different points due to the team’s small size:
UX Research: Partnered with a UX researcher on stakeholder interviews, user observations, and usability testing
Product Management: Led timeline creation and feature prioritization during the first two years, when no product manager was assigned.
Outcome
The initial version of the new QA tool, Zio QA 1.0, is feature complete and in the validation phase. It is scheduled to fully launch in mid-2025.
Usability testing of the new Zio QA has shown positive results, with an overall increase in usability, satisfaction, and efficiency. Projections based on testing indicate a 2 - 4 minute time reduction per record, saving $24M+ for each minute over 10 years.
Challenge
Business Goals
A variety of factors drove iRhythm leadership to green light the design and development of a replacement QA tool:
Old tool was built on an obsolete tech stack
An ongoing effort to expand into new international markets
A desire to reduce the amount of time it takes to review a record, which affects the company’s bottom line
Business Stakeholder
“This tool has served us really well over the past 10 years. It has all the basic functionality we need, but comes with many issues. As we grow and scale as a company, it will not be enough anymore.”
User Needs
There were only a few actual user pain points that were communicated anecdotally at the start of the project:
The workflow is open-ended, which is inefficient and invites a lot of unnecessary work
The QA tool was only one tool of many that are required to complete a scan
As it was designed, two monitors are necessary to correctly use the tool
A two monitor setup was required
More specific insights into the experience of using the tool was lacking. Therefore, kicking off the project with a coordinated research effort was a priority.
Research
With minimal domain knowledge, designing a new tool would be nigh impossible without a comprehensive research period to understand the experience of using the current tool and the vision for the replacement tool.
A screenshot from the old QA tool. My lack of background knowledge was an initial challenge.
User Research
As a part of the research phase, I partnered with a UX researcher to conduct the following:
Training sessions - I sat in on new hire training sessions for the QA tool. I had access to the tool and was able to follow along and play with the different functions.
Contextual inquiry - I observed (remotely due to COVID) technicians as they shared their screens and scanned different records.
User interviews - I conducted interviews with technicians as a follow-up to observing them use the tool.
Stakeholder Conversations
I led meetings with clinical leaders, many of whom were former users of the QA tool who now managed and coached less experiences technicians. The goals of these conversations were two-fold:
Understand their perspective of the current tool workflow
Differentiate between the short and long-term visions of the tool
The tool is extremely complex and contains layers upon layers of functionality, so it was important to identify and prioritize what features should come first.
I used this image on a few occasions to illustrate the iterative approach in our short vs long-term vision discussions.
Approach
Identify the Optimal Level of Guidance
The first big challenge of the design phase was finding the right balance between letting users freely navigate and perform actions, versus guiding them through a more strictly defined workflow. I thought through various potential options and led meetings with cross-functional partners to review the potential of each. Ultimately, we chose to go with a more guided approach.
Three different workflow skeletons, from constrained to flexible
Iterate Modularly
Now the vision for the new tool was one guided workflow composed of multiple steps, many of which required specific suites of functionality. Designing for each of these steps was like a small design project in itself, with it’s own self-contained phase of concepts, prototypes, and full-fledged user testing.
Evolution of the Rhythms step
Build a Design System
Once we reached the high-fidelity design stage, I built a design system for the new tool in Figma in order to:
Ensure the designs were consistent across the app
Facilitate quick ramp up of other designers assisting
Have a foundation with which to create new designs
Allow developers to reference a design “source of truth”
A snippet of the Zio QA design system
Create Documentation
Due to the complex nature of the new tool, there were many intended behaviors and use cases that weren’t communicable via static mockups. In additional to finaI mockups, I wrote detailed annotations describing the intended functionality and recorded video demos for the especially complex cases.
Designing
Below, I share a selection of designs highlighting some of the impactful decisions I made over the course of this project.
Editing Functionality
• Challenge •
How should we allow users to edit and modify the ECG data? What type of controls should they be? How should they be accessed?
• Action •
I explored three different concepts. The engineering built them out into prototypes that we tested with users.
Option 1: The right-click dropdown menu
Option 2: “Jaws” menu that expands and collapses based on context
Option 3: Sidebar menu that is toggle-able with the navigation
• Result •
Based on user feedback, we decided to move forward with the sidebar option.
ECG Scrolling Behavior
• Challenge •
How should users be able to navigate and scroll through an strip of ECG?
• Action •
I experimented with various combinations of potential interactions (dragging, single/double clicking, scrolling, etc.) and created quick interactable prototypes in Figma to share with the development team. The dev team then built prototypes that we tested with users
These designs are a bit challenging to share through static images, so below are some video clips illustrating the different options I designed.
• Result •
We learned that neither of the options were perfect, and the final design incorporated the aspects that users preferred.
Event Data Visualization
• Challenge •
How can we provide a high-level episode summary of a given rhythm type based on the episode duration and heart rate?
• Action •
I explored various ways of visually representing the information, and had to think through various states that could result from user interaction.
• Result •
We landed on a heat map visual, a way for users to get a high-level view of the occurrences and quality of different rhythm episodes that a patient experienced. But finalizing this visual was only the start, as I would move on to defining the heat map behavior and axes rules.
The heat map is located in the upper left of the Rhythms view
Final Mockups
Below are screenshots showing the final design for each major step in the workflow.
Takeaways
Complexity dulls the instincts – The more complex/foreign a project is, the less I can rely on my past experience and design instincts to make snap decisions. Building relationships and communication with experts becomes extra important
Get creative with communication – Constant communication with the team was critical. I experimented with various communication methods to get decisions made as quickly as possible.
Keep the big picture in mind – Both from a strategy (short-term vs long-term) and from a design consistency perspective, decisions can’t be made without considering how it affects the whole.