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)

Research coordinators (rotating)

Coordinators (rotating)

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

Increased usable data

Increased usable data

1

1

Paper in Nature Medicine

Paper in Nature Medicine

10,000

+

App users

App users

30

Paying research teams

Paying research teams

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

8+

8+

hrs / day

Coordinator time on email

Coordinator time on email

58

%

Sync and survey tickets

Sync and survey tickets

POST-DOC RESEARCH SCIENTIST

POST-DOC RESEARCH SCIENTIST

“Participants rarely use the app, even if they are pinged… When we analyzed data, we found many participants had no data.”

How a confusing app held everyone back
A vicious cycleEvery stop makes the next one worse, all the way back to the participants.
ParticipantsA confusing app, so they stop syncing.
DataWhere it breaksUnder 1% of it is usable.
ScientistsCan’t prove the algorithm works, so they can’t publish.
FundingNo paper means a weaker case for the next grant.
CoordinatorsStretched across more projects, buried in support email.
SupportReplies come slowly, and participants lose trust.
Before I joined
Old survey screen
The old survey screen
Nothing says what a “complete” day is
When to take each survey is left to guesswork
Old health dashboard
The old health dashboard
No sign of whether the watch is connected or synced
Glucose, genome, microbiome: data the watch never sends

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.

Where participants got stuckShare of support emails by step in the app, before the redesign
01Log in37%
02Connect a watch5%
03Sync data35%Fixed in 04
04Fill out surveys23%Fixed in 05

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.

RESEARCH PARTICIPANT

RESEARCH PARTICIPANT

“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.”

What changed on the sync screen
After: the redesigned screen
  1. 01Status, said plainlyConnected or disconnected, never implied.
  2. 02Last syncedToday’s data or last week’s, at a glance.
  3. 03The watch, by nameOnly the data types that watch provides.
  4. 04How to syncPull down to sync, said on the screen itself.
  5. 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.

RESEARCH PARTICIPANT

RESEARCH PARTICIPANT

“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.”

What I found, and what the calendar shows because of it
Data lens: sync dots
  1. 01Support tickets“I synced but there is no result.”The algorithm needs 12 hours of data to run a day. No one had told participants.A filled dot means the day synced. An empty dot means under 12 hours.
  2. 02ScientistsA deviation needs that day’s survey.Without it, a red alert can’t be explained, so the data can’t be used.Red days ask for a survey, and the tasks sit on the same page.
  3. 03CoordinatorsNo feedback, no participation.In earlier studies, people disengaged when the algorithm told them nothing.Every day shows the result, green or red, in neutral words. It never diagnoses.

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.

6research staff surveyedAll running Stanford studies on MyPHD. I then reviewed the designs with the study’s stakeholders.
  1. Saved views, and an import that fills in contactsEach participant was being looked up by hand.
  2. Last sync on every row, worst firstChecking meant decoding 30–40 files.
  3. A seven-day overview of who needs a nudgeWeekly checks kept slipping.
  4. 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

Weeks to set up a new paying team, down from 4

Weeks to set up a new paying team, down from 4 weeks

1

Coordinator on support, down from 3

OutlookAn email when I left the labClinical Research CoordinatorTo: Kexin

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.

Warm regards,Clinical Research CoordinatorDepartment of Genetics

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.

Next case study

Next case study

Stanford Data Ocean — Teaching data science to 5,000+ beginners

Read the case study →