Case study 01 · seed 1157360529

Glucose Monitoring Prototype

RoleProduct designer WhereIndependent, health informatics When2024-01 → 2024-04 ToolsFigma, HCI, Data flows githubopen ↗

A glucose monitoring app prototype designed to clinical accessibility standards. Auth flows, core journeys, and a reading screen built for someone who checks it twelve times a day and deserves better than a dashboard.

The problem

A person managing diabetes checks their glucose more often than they check the weather. That reading is not a dashboard problem, it’s a companionship problem.

Note 1My design bar for this project: a reading should be legible from arm’s length, at night, by someone who has already done this twelve times today.

Most consumer glucose apps borrow their visual language from fitness trackers: celebratory, gamified, loud. Clinical tools swing the other way, dense and cold and built for the clinician instead of the patient. I wanted to find out what lives in between, a design with consumer-grade warmth that takes clinical accessibility standards completely seriously.

The constraints

Working without real data turned out to be a gift. It forced me to design for every state honestly instead of cherry-picking happy paths. Hypoglycemic readings, sensor gaps, and stale data all got first-class visual treatment, because in real life those are the moments that matter most.

How I worked

The project moved through three passes:

  1. Authentication and onboarding. Health data is regulated data. I mapped the sign-in flow around token-based authentication patterns and explicit consent screens before touching any visual design.
  2. Core journeys. Log a reading, review a trend, share with a clinician. Each journey got flowcharted, prototyped, and walked end to end.
  3. The reading itself. Color is never the only signal. Every glucose state pairs color with position, text, and shape, so the interface survives color-vision deficiency and 2 a.m. screen dimness.
HIGH · 10.0 MMOL/LLOW · 4.0 MMOL/L4.8 ↓ FALLING
Fig. 1.1 · Every reading pairs color with a second channel, so no state depends on color alone

What I learned

The most consequential decision was the smallest one: the trend arrow. People who use these apps describe reacting to numbers but deciding based on direction. So I gave direction equal visual weight with the reading itself, arrow, verb, and color moving as one unit. That single change reorganized the whole home screen around the only question that matters: what should I do in the next twenty minutes?

Where it goes next

This is a prototype and it says so plainly. The honest next step is moderated usability testing with people who actually manage diabetes. Everything above is a hypothesis with good reasoning behind it, not a validated result. Knowing the difference between the two is the discipline I care most about.

What actually happened

Qualitative
Core flow completion
Design walkthroughs of the authentication and logging journeys. Formal usability testing is the planned next phase.
Search & jumpesc