How might we make chemotherapy less risky for cancer patients?

Chemotherapy is a risky treatment. In an ideal world, patients should stay in the hospital for 7-10 days after their therapy, just so they can get timely treatment in case of an emergency. However, today in the United States, most patients are discharged from hospital shortly after their treatment. For some patients, this period could be as short as 3 days. How can we make post-treatment time safer for cancer patients?

Gaido, a remote patient monitoring system

To solve that problem, we built Gaido — a remote monitoring system that tracks patients’ vital signs when they return home. There are three components:

• Patient end: a mobile app + wearable device that tracks the patient’s five vital signs
• Nurse end: a dashboard that lets nurses track their patient's vitals and receive alerts
• A Machine Learning (ML) algorithm that detects potential risks and looks for optimal intervention points

During my time at BCG, I designed the patient-end mobile app. My responsibilities spanned across scenario construction, wireframing, prototyping, and UI design.

Let me first walk you through my final design :)

User scenario

Derek, 58, just finished his second chemotherapy. Derek's health condition stabilized two days after the treatment, and his doctor decided to discharge him in 48 hours. Since Derek has signed up for Gaido prior to the threpy, Gaido's support staff comes over to help him onboard the system.

⚠️ Disclaimer: I created all the screens below based on my work at BCG. Other designers continued to work on the project after I left the team, so the actual UIs may look different.

Onboard the system

With the help from the support person, Derek downloads the Gaido app from his phone, creates a profile, and puts on the wearable devices that track his vitals.

Track the vital signs

Two days later, Derek returns home. He can easily check his vitals at any time through the Gaido app.

Take a Patient-Reported Outcome (PRO) survey

One day, Derek’s core temperature rises to 102.5 F. He receives a prompt from Gaido to fill out a wellness update survey. He answers a few questions about his symptoms, recent activities, and moods, and learns that the record will be shared with his doctors. Gaido also encourages Derek to call his hospital if the symptoms don’t go away.

Manage data and consent

Because Gaido collects health data (which is sensitive personal information), we need to follow the highest privacy standards and give Derek the options to download/delete data, revoke consent, as well as control how his data can be used at a granular level.

Game plan

Vital signs are useless?

After the initial concept testing, we ran into an unexpected issue: testing participants (doctors and triage nurses) told us that vital signs are actually much less useful than what we had assumed:

1. False alerts are inevitable and hard to detect. For cancer patients, the boundary between normal and abnormal vital signs can be extremly fuzzy. Patients are likely to have pre-existing conditions that would make their vitals look abnormal, even when they're doing well.
2. Quantitive data alone doesn't tell much about what has happened. Although doctors and nurses found it valueable to see trend over time, they were not sure about how to interpret the data and how to give medical advices. Further clinical contexts such as patient-report symptoms are crutial for people to make sense of the vital signs.

Based on the feedback, we realized two missing pieces in the initial proposal:
1. Expectation calibration.
We need to manage user’s expectations for the accuracy of the system. To address this, we decided to send alerts only when Gaido detects an absolute emergency (eg. when the patient’s blood oxygen level drops dramatically).

2. Context information that augments the quantitive data.
Based on suggestions from SMEs, we decided to send Patient-Reported Outcome (PRO) surveys to users through the mobile app. PRO is a widely used tool for nurses to understand a patient's condition, such as symptoms, recent activities, and moods.

Setting design goals: Balance user needs with data needs

As we shifted our focus from alert to collection of PRO collection, the tension between patient needs and data needs became much more prominent. How might we avoid treating early adopters as mere "data providers"? How might we provide more immediate value for them? To address that, I added user values as a top design goal, and applied several strategies.

Strategy 1: Focus on high-value data points to avoid nonpurposive data collection

As our ML engineers became interested in including Patient Reported Outcome(PRO) in their model, they wanted us to “collect as much PRO as possible”. The original plan was to prompt users every two hours and make them fill out 10 surveys everyday via the mobile app. The problem is, that plan not only will affect the user experience, but also won’t get us high-quality data--if users aren't really engaged, there will always be workarounds to fool the system, which will result in low-quality data points.

The only way to get good data is to engage our users -- to help them understand why the data is needed and how data recording would benefit them. To do that, we had to ask ourselves first: What type of PRO data do we need?

I was able to identify high-value data points with that info, and map out the alert user flow to help the team to build a data collection plan that's more targeted and less annoying for patients:

Strategy 2: Make raw data more useful when the ML model isn't mature enough to provide insights

To balance user needs and data needs, another opportunity I looked into was to make the display of vital signs more accessible to patients. We did five user tests to learn how patients perceive their vital signs, and improved the design accordingly.

Strategy 3: Help users calibrate their trust level in the system via visual design

The tension between user needs and data needs continued in the visual design stage. To begin with, we as a team picked three promising directions from a set of classic brand personas. Then I was then asked to explore the visual concepts for the three selected directions: ”companion”, “translator”, and “caregiver”.

After looking at the three mock-ups, I realized that while “companion” and “caregiver” feel more warm and human, they can also make the system look more trustworthy than it really is, and thus introduce blind trust. Therefore, I decided to go with the "translator" style (which is more neutral and straightforward).

Product results: Challenges turning into selling points

Gaido (alpha version) was successfully released in the iOS app store shortly after I left the team. The product has been through iterations since then and was acquired by a health tech company early this year.

What I found most interesting is that the inclusion of patient-reported outcome has been a major selling point for Gaido. That wouldn’t come into play without the human-centered design approach and close collaboration between design and ML engineering.

Designing early stage ML-powered systems

The tension between user needs and data needs is not unique to Gaido. If you’re also designing early stage ML-powered systems and have similar challenges, here's what you might want to consider:

• Be mindful of the type and amount of work your system may introduce to users
• Optimize your data collection strategy to minimize user tasks
• Help users to understand how much they should trust the system. Aovid language or design patterns that might introduce blind trust.
• If your ML model is not matured enough to produce reliable outcomes, look for alternative ways to bring value to early adopters.

If you’re interested in UX of AI and want to chat with me, don’t hesitate to shoot an email :)