A live glucose dashboard read by three people who couldn’t be more
different: someone who just wants to know they’re okay today, someone
tracking progress with a coach, and someone who reads the clinical data
natively. One product, three levels of medical literacy.
GoodFlip CGM dashboard. Sole designer, research to shipped UI.
77.6%
finished setup
78%
were still using it at day 14
Role
Sole Product Designer, research to shipped UI
Product
GoodFlip CGM dashboard (TatvaCare)
Scope
Research, IA, interaction, visual design, shipped
Timeline
[ fill: duration ]
Tools
Figma [ fill: remaining tools ]
Why CGM
CGM was a product call. My job was to design against it, which meant
understanding why it was the right one.
CGM
Business
A standalone SKU in a growing market (BeatO, Ultrahuman, SugarFit), with a natural 15-day repurchase cycle.
Product / ecosystem
Filled the gap between six-month lab tests. Slotted in alongside BCA and coaching.
User
See your own glucose patterns, catch spikes early, watch progress without waiting six months.
Clinical / coaching
Continuous data a coach could act on, versus twice-a-year snapshots.
Four different reasons to say yes. The design had to hold up to all of them.
The bet
One product, three readers
GoodFlip is built to be science-forward, so hiding the clinical data was
never the option. The full picture had to be in the product.
But a CGM produces around fifteen metrics, and the people reading them
aren’t the same person.
The Seeker
doesn’t have diabetes. She’s doing intermittent fasting and wants to know one thing: did I stay in range today? CV% and GMI mean nothing to her.
The Changer
is working with a coach to reverse insulin resistance. He tracks week over week, and needs something clean enough to share.
The Diagnosed Diabetic
has used CGM for years. She reads AGP and standard deviation natively, and compares today against last Tuesday.
So I stopped designing one screen and split the dashboard into three
views, by how deep a reader wanted to go.
Daily
the glanceable home. Current glucose, daily average, time in range.
Cumulative
progress across fifteen days, for the person tracking change.
Advanced
the clinical layer, and the view a user shares with their doctor or coach.
The final IA: three views, split by how deep a reader wants to go.
Inside each view I made one more call, metric by metric. Show it, simplify
it, or hold it back.
The per-metric call
Metric
Call
Why
Time in range
Show
Upfront, never buried. The one number that answers am I okay.
GMI
Simplify
Renamed “Glucose Estimate” with a tooltip. The acronym means nothing to most people.
Max fluctuation
Withhold
Held back from the everyday user. A lone alarming spike doesn’t inform them, it frightens them. It lives in the advanced view, where a coach reads it in context.
The question was never how much to show. It was what each person could act
on, and what would only scare them.
Living with the device
I wore it for fifteen days
Understand the medical concepts
Sit with the medical team on how they read the data
Wear the CGM for 15 days
Write user stories and scenarios
Wireframe
Before I designed a screen, I put a sensor on my own arm and lived with it
for the full fifteen-day cycle.
Three things surfaced that no amount of research would have.
The install was harder than the manual admits. Two-part
device, and even having studied it, I fumbled the first attempt. If I
struggled, the 60-year-old installing their first one didn’t stand a chance.
The errors weren’t edge cases. Data dropped out. Moisture
got in. A reading vanished and I couldn’t tell whether it was me, the
sensor, or the app.
The nudges were the one thing that genuinely helped. I
expected notification noise. Instead, the right prompt at the right moment
made the data feel alive instead of buried.
I ended the fifteen days with a list of everything that can go wrong with
this device. That list became the brief for what I designed next.
AssetReal photo from the 15 days: sensor on arm / app showing live data (real photo strongly preferred over mock)4/3
What I built in response
Legible data, trustworthy device
That list of everything that can go wrong became the brief. I built
against it in two directions: making the data legible, and making the
device trustworthy.
Onboarding journey
Main landing page
Making the data legible
Daily and Cumulative, one tap
The archetype work couldn’t stay on paper. One switch at the top of the
dashboard lets the Seeker land on today’s single answer and the Diabetic
drop into fifteen-day trends, without either wading through the other’s
screen. The three-view split, made into one tap.
Advanced Metrics, walled off
A clearly separated section, so the everyday user knows where the
clinical depth begins and where they can stop looking.
Plain-language cards
Every metric card ends on a human verdict, not just a number. 18% above
range reads as “room to improve.”
Education pages
For every metric a user might not understand, a page that explains what
it means and how to read it, in plain language before clinical terms.
This is the decision I can prove worked, see the numbers below. People
didn’t tolerate the education. They sought it out.
The nudge system
The thing that helped me most during my fifteen days, designed as a
system rather than a stream of alerts. Seven triggers, each tuned to what
the moment can bear: a low-glucose dip is cautious and actionable, a
night spike is quietly informative, the end of a spiky day is reflective,
not alarming. Same duty of care as the dashboard itself, applied to what
we say and when.
In-context error states
When syncing dropped, the screen said what to check and why, in place,
rather than leaving the user staring at missing data.
Live CGM replica
Marketing wanted to launch this as India’s first Bluetooth CGM. I turned
that ask into a live on-screen replica of the device showing the current
reading, so the data felt alive rather than buried in a table.
Connection support
Help, demos, and a way to reach support built into the connection journey
itself, where the install actually got hard.
Most of this held. The onboarding didn’t, and the complaints told me
exactly where.
The reckoning
Then I looked at what happened
Six weeks after launch, the February 2026 data was in. I only claim what
it can hold, so here’s what held.
77.6%
of people who started setup finished it
218 of 281, through a ten-step, two-part hardware pairing flow. Device
onboarding usually bleeds users at every step. This one mostly didn’t.
And I know exactly where the other 22% fell: transmitter detection, the
one real cliff in the funnel (93% to 83%). That specificity matters,
because it’s the same two-part device that came back to bite us after
launch.
78%
were still using it at day 14
The full sensor cycle (Day 0: 93%, Day 7: 81%, Day 14: 78%). People
didn’t set it up and drift. They came back to read their data every day.
One honest limit: I hold this at day 14 and no further. Beyond that the
cohorts thin out and the number stops being trustworthy. So this is the
ceiling I’ll claim.
42%
opened the day-glucose explainer, the most-opened content on the dashboard
In the last section I claimed people sought out the education rather than
tolerating it. Here’s the proof: the day-glucose explainer was the single
most-opened piece of content on the dashboard (42%), with the
time-in-range explainer next (24%). People didn’t just glance at their
numbers. They stopped to learn what the numbers meant. The one decision I
most wanted to be right about, was.
Retention across the sensor cycle
93%Day 081%Day 778%Day 14
Held to day 14. Beyond that the cohorts thin out, so this is the ceiling claimed.
The dashboard held. The onboarding was where reality pushed back.
Where reality pushed back
The device didn’t behave
Setup completion said 77.6%. What it didn’t say: some of those completed
setups started coming back as replacement requests. The data looked clean.
The device, in people’s hands, wasn’t behaving.
The complaints traced to one thing. It’s a two-component device (sensor and
transmitter, assembled by the user), and despite clear instructions, people
couldn’t tell when it was seated correctly. Data wouldn’t show, or they’d
installed it slightly wrong, or it wasn’t attached properly.
The root cause wasn’t the instructions. It was the mental model. Our
audience was used to a single-piece, stick-it-on-and-forget device. A
two-part assembly was a category they’d never met, and no amount of
on-screen copy fixed a hardware expectation. (The funnel had already
whispered this: transmitter detection was the one cliff in setup.)
Two responses, each matched to a specific failure
The QR scan kept failing
On the sensor mapping step, so I added manual code entry as a fallback.
BeforeAfter
Older users were arriving in numbers we hadn’t designed for
So I translated the whole flow to Hindi with a language toggle.
BeforeAfter
Killed idea
I also pitched the more ambitious fix: use the phone camera as a live
install assistant, guiding the user through seating the device in real
time. I built a working demo. We killed it: dev bandwidth was thin, and
more seriously, nobody could answer what happens if the assistant tells
someone it’s seated correctly when it isn’t. On a medical device, a
confident wrong answer is worse than no answer. So it stayed a prototype.
The fixes handled what broke. The next move wasn’t a fix. The dashboard
could tell you your glucose spiked at 3pm. It couldn’t tell you why. The
why was almost always food.
So we brought Kaira, our food-logging AI, onto the CGM graph itself, with
two aims: help users see the pattern between what they ate and how their
glucose moved, and get them logging more in the first place.
Kaira on the CGM graph: food marked on the curve, and the plain-language
insights users open.
Food, placed on the curve
Users could mark meals directly onto their glucose graph and tap any one
to see how it moved their sugar. A spike stopped being a number to worry
about and became a meal you could point to.
A clear entry point for AI insights
One obvious place to go from “here’s my data” to “tell me what it means,”
so the AI layer was something users chose to open, not something that got
in their way.
The insight itself was a design surface, not just the container
I owned what the AI actually said, the logic behind which insight surfaces
when, and the language it used to say it. In a product like this, the
model’s response is the interface, so I treated its words the way I’d
treat any other UX copy, held to the same care: useful, plain, and never
alarming to someone looking at their own health data.
AI only when the user asks for it
The one-liner above the graph looks AI-generated, but it’s rule-based by
design. Real AI runs only on genuine user intent, when someone actually
asks for an insight. Same result on screen, a fraction of the token cost
at scale.
It worked as an entry point. The CGM screen became the second-largest
food-logging doorway in the entire app, driving 26% of all logging starts,
behind only the nutrition screen built specifically for it. A glucose
dashboard turned into one of the product’s primary places to log a meal.
My part was the integration: how Kaira surfaced on the CGM screen, how
meals mapped onto the graph, the tap-to-detail interaction, the entry point
into insights, and the logic and language of the insights themselves. I
designed it and handed the logic to the developers.
What worked, I can point to. The education pages, the bet I most wanted to
be right about, are among the most-opened content on the dashboard. The
dashboard itself has drawn few real complaints and some genuine user
appreciation, which for a screen this dense is the outcome I’d have taken at
the start.
The clearest proof it held: the same dashboard now runs on MedEcho, the
doctor-facing version, where clinicians read their patients’ data through
it. A screen built to be legible for three kinds of reader turned out
legible enough to become the clinical one.
It isn’t finished. We watch the user reviews as they come, and I worked
with a colleague to resolve the most common friction through a proper FAQ
layer. And the thing we ruled out at launch, real two-way interaction with
Kaira, is now being built directly into the CGM. The ambition that dev
bandwidth killed on day one is the direction the product is taking now.
None of this was about a dashboard. It was about deciding what each person
could handle, showing the data honestly, and fixing what I got wrong when
the device proved me wrong. That’s the work I’d do again.
