Case study 02 · seed 1157360529
Figma prototype · 2024 · Role — Product designerFigma · HCI · Data flows
Units — mmol/L

The mascot and the XP —
on top of clinical accessibility,
never instead of it.

The mascot and the XP —
on top of clinical accessibility,
never instead of it.

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.

Legible from arm’s length · at night ·
on the twelfth check of the day

Three passes, in order

01
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.

02
Core journeys

Log a reading, review a trend, keep up with medication and meals. Each journey got flowcharted, prototyped, and walked end to end.

03
The reading itself

Colour is never the only signal. Every glucose state pairs colour with position, text, and shape, so the interface survives colour-vision deficiency and 2 a.m. screen dimness.

The trend arrow is never colour-only

colour + position + text + shape

People who use these apps described reacting to the number but deciding based on direction, so direction got equal visual weight with the reading itself. The same synthetic component, shown under four conditions it was designed to survive.

TREND
↓FALLING
4.8 MMOL/L
01 — AS DESIGNED
TREND
↓FALLING
4.8 MMOL/L
02 — COLOUR REMOVED
TREND
↓FALLING
4.8 MMOL/L
03 — SCREEN DIMMED, 2AM
TREND
↓FALLING
4.8 MMOL/L
04 — AT ARM’S LENGTH
4.8 mmol/L is a synthetic reading — no real patient data was available for this project.
Fig. 1 — the decision, schematically
HIGH · 10.0 MMOL/LLOW · 4.0 MMOL/L4.8 ↓ FALLING

That single decision, giving direction equal visual weight with the reading itself, reorganized the whole home screen around the only question that matters: what should I do in the next twenty minutes?

Thirteen real screens, framed not re-drawn

Every screen below is the actual Figma prototype, not a re-drawn mockup of it.

GluCare splash screen with a warm bear mascot and Sign In / Create Account buttons on a cream and sage background
Splash: consumer warmth before a single clinical detail
GluCare log in screen with empty email and password fields and inline helper text
Log in, empty state with inline validation copy
GluCare log in screen with the email and password fields filled in
Log in, filled state
GluCare home dashboard showing a daily glucose trend chart with a shaded in-range band and a daily tip card
Home dashboard, the daily trend read at a glance
GluCare add-a-sensor screen with a device illustration inside a circular target and a plus button to pair
Pairing a new sensor
GluCare scan complete screen showing a 102 mg/dL result with trend, time scanned, XP earned, and streak
A single reading, with trend and context, not just a number
GluCare medication screen with a weekly day picker and morning and evening medication checklists
Medication tracking, built for the same daily habit loop
GluCare nutrition screen with calorie, carb, protein, and fat rings and an empty meal log
Nutrition summary before anything is logged
GluCare breakfast food search screen with an All / My Meals / My Recipes filter and a history list
Searching and logging a meal from history
GluCare nutrition screen with the calorie rings filled in and photographed breakfast, lunch, dinner, and snack entries
Nutrition summary once the day is logged
GluCare My Recipes empty state with a bear mascot holding an apple and a green Create a Recipe button
My Recipes, empty state
GluCare My Recipes empty state with the Create a Recipe button in its pressed state
My Recipes, button press state
GluCare settings screen listing Account, Privacy and Security, Data and Information, Display and Appearance, and Log Out
Settings: account, privacy, and data controls
SYNTHETIC DATA ONLY — NO REAL PATIENT DATA AVAILABLEmmol/L (CANADIAN CONVENTION)SOLO DESIGNER · NO ENGINEERING PARTNERPROTOTYPE — NOT YET USABILITY-TESTED

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’s actually validated so far

Core flow completion — qualitative. Confirmed through design walkthroughs of the authentication and logging journeys. Formal usability testing is the planned next phase, not something that’s happened yet.

GluCare — Glucose Monitoring PrototypeProduct design — case study
Search & jumpesc