My Personal Health Dashboard
by Stanford University
Turning a struggling study app into a product Stanford labs paid for
My Role
UX/UI (sole designer)
Year
2020–2023
Team
Engineers (2)
Stakeholders (3)
Scientists (rotating)
Industries
B2B Healthcare
Precision Medicine
AI
01 — Overview
4× more usable data, and an app other labs paid to use.
MyPHD is an app that collects smartwatch and survey data for Stanford health studies. When I joined, engineers had built it without a designer, and almost none of the data it collected could be used.
As the only designer, I redesigned how people connect their watch, sync it, and answer surveys. Usable data went up 4×, and other labs started paying to run their studies on the app.
4
x
10,000
+
30
02 — Problem
Bad data stalled the science, and everyone around it.
Out of more than 5,000 people in the study, only 32 produced wearable data the scientists could use. Without it, they couldn’t prove the algorithm worked. And the problem fed itself, as the loop below shows.
Painpoints
0.61
%
Usable data
hrs / day
58
%
“Participants rarely use the app, even if they are pinged… When we analyzed data, we found many participants had no data.”
03 — Diagnose first
Find where people got stuck before redesigning anything.
An engineering lead wanted to start fixing screens right away. I pushed to find out what was actually broken first. Instead of asking for research time, I used what we already had: every support email, sorted by the step in the app where the person got stuck. Then I fit in short talks with 3 scientists and 14 participants.
Two steps caused more than half the emails, syncing the watch and filling out surveys. I handed the spreadsheet to the coordinators so they could keep tracking it.
Syncing and surveys caused 58% of support emails, so that’s where I started.
04 — Clear data sync
Show whether the watch is connected, and when it last synced.
Syncing caused 35% of support emails. People compared our app with their watch’s own app, saw different numbers, and assumed the sync had failed.
“On the Dashboard, there’s a bunch of other data that I don’t know how to input. For instance, it has White Blood Cell as an option. I’d love to input all of that into this study but I don’t know how.”
- 01Status, said plainlyConnected or disconnected, never implied.
- 02Last syncedToday’s data or last week’s, at a glance.
- 03The watch, by nameOnly the data types that watch provides.
- 04How to syncPull down to sync, said on the screen itself.
- 05RemovedGlucose, genome, microbiome and an aggregate card. None came from the watch.
The shipped sync flow.
05 — The calendar
Explain every day on the calendar, so a blank day isn’t a mystery.
Surveys caused another 23%. Three things I learned shaped what the calendar shows each day.
The calendar was the riskiest piece to build on a one-week timeline. I kept it in by agreeing it would only use neutral words and never suggest that someone might be sick.
“The app never seems to update… This morning I updated on WiFi, but only May 7th actually populated an algorithm alert, the 3rd and 4th are blank. I tried exiting and running the app again but still blank.”
- 01Support tickets“I synced but there is no result.”
- 02ScientistsA deviation needs that day’s survey.
- 03CoordinatorsNo feedback, no participation.
The shipped calendar.
06 — Researcher dashboard
Design a dashboard for the coordinators. It was never built.
Once other labs paid to use MyPHD, the coordinators running their studies became our users too. Checking on participants took them hours of manual work, so I designed a dashboard to do it at a glance.
It was never built. Our only engineer was busy with other projects, and a bug in the live app could have affected every study at once.
- Saved views, and an import that fills in contactsEach participant was being looked up by hand.
- Last sync on every row, worst firstChecking meant decoding 30–40 files.
- A seven-day overview of who needs a nudgeWeekly checks kept slipping.
- Email alerts for red alerts and key survey answersSurvey answers went unseen.
A prototype of my 2022–2023 design. Never shipped, and the data is made up.
07 — Results
From a cost to a product labs paid for.
The redesign paid off in three ways. The lab got 4× more usable data, and the study’s algorithm was published in Nature Medicine. It caught 80% of infected participants a median of three days before their symptoms started.
Support got cheaper. Emails about syncing and surveys fell 20%, and one coordinator could handle the inbox instead of three.
And the app started earning money. Other Stanford labs paid a fee per team to use it, and a design system I built cut each new team’s setup from four weeks to two.
4
×
More usable data
20
%
Fewer sync and survey emails
2
1
Coordinator on support, down from 3
Hi Kexin!
Bittersweet to hear that you’ll be leaving the lab. Thank you so much for your support these past few years! Especially during 2020-2023 for your immense support on improving the MyPHD experience for participants and research teams.
An email a clinical research coordinator sent me when I left the lab. Name hidden for privacy.
Behind the work
What didn’t ship
A researcher dashboard that never got built.
The coordinators’ dashboard never shipped. Our only engineer was stretched across other projects, and a bug in the live app could have affected every study running on it.
So I wrote up the research and the designs, including the order the team wanted things in, alerts first, so someone could pick it up later. It taught me to push forward what I can, and leave a clear record of what I can’t.
How I worked
Disagreeing with an engineering lead, with evidence.
The biggest disagreement came at the start. An engineering lead wanted UI fixes right away, and I wanted to understand the problem first. Waiting had a real cost, because the study was live and every broken week meant more data nobody could use.
So I didn’t ask for research time. I used the support emails we already had, which showed that more than half the problems came from two steps. We agreed to fix those two first instead of polishing every screen.
What I’d do differently
Co-design with engineering from day one.
If I did it again, I’d bring engineers in earlier. The calendar shipped, but only after a late debate about scope. Showing them the coordinators’ evidence sooner would have shortened it.
I’d also ship the dashboard in smaller pieces. With one engineer, waiting for the whole thing meant shipping none of it. The research team had already told me what mattered most: alerts, and knowing that participants were syncing consistently, especially new ones. People who keep up with a study early on are more likely to keep up the whole way through, so spotting a new participant who’s falling behind lets the team nudge them, or find out why and help, before the habit slips.
Stanford Data Ocean — Teaching data science to 5,000+ beginners
Read the case study →




