How the work moved
-
Research
AI deep research
-
Synthesis
Patterns and risks
-
Hypotheses
Bets worth testing
-
Concept
A companion, not an app
-
Design
Voice, rules, safety
-
Prototype
A working service
-
Iterate
Refine what breaks
Designing with AI as a research partner
The space is wide: the condition, the families, the clinics, and the apps that already exist. I explored it with AI deep research, which produced structured reports with sources.
- 1 · Market opportunity
- Trends, unmet needs, five opportunity areas, strategic implications and risks.
- 2 · Competitive benchmarking
- Family-focused apps, all-ages trackers, device ecosystems and coaching platforms, compared side by side.
- 3 · Condensed brief
- A one-page benchmark for the concept itself: differentiation and recommendations.
What AI did
- Scanned trends, competitors and studies across a wide space
- Structured competitors into comparable categories
- Drafted a first synthesis to argue with
What stayed with me
- Which patterns mattered for design
- Which opportunity to pursue, and which to leave
- What the product should sound like, and never say
- What data it should keep
The patterns I took forward
Most of the reports were market detail. Five patterns were design problems.
-
Tracking becomes a chore
Teens disengage from generic tools; what feels new quickly becomes “boring”.
-
Independence vs. peace of mind
Teens want to manage on their own terms; parents need to know they’re safe.
-
Personality is the product
The AI-assistant opportunity depended on a voice and tips made for teenagers, not adults.
-
A clear medical boundary
Staying away from dosing advice keeps a product in low-risk wellness territory.
-
Minors’ data is the most sensitive thing it could hold
Privacy and trust had to be designed in from the start.
Of the five opportunity areas the research named, Dia explores one: an AI-powered personal assistant.
Hypotheses
The prototype is built around three bets:
-
Conversation instead of forms
If logging feels like texting a friend, a teenager is more likely to keep doing it.
-
A voice that never lectures
Focusing on the person rather than the number keeps the relationship going.
-
Calm safety builds trust
Clear thresholds and a hard line on medical advice let teens and parents rely on it.
From pattern to design decision
Decision 1
A persona, not a form
Dia is “a cool older sister who happens to know a lot about diabetes”: warm, a little funny, never clinical. It remembers what you said and brings it up naturally.
Why Answers tracking becomes a chore and personality is the product.
Decision 2
Rules that protect the relationship
Two or three sentences, like a real text. At most one follow-up question. Never “you should” or “you must”. A bad reading gets “how are you feeling?”, not a lecture.
Why Answers independence vs. peace of mind: support without supervision.
Decision 3
The conversation is the log
Every reply also returns structured data — glucose, unit, meal, insulin, mood, activity — so a casual message becomes a record without a single form field.
Why Logging without the chore.
Decision 4
Safety that stays calm, and a hard boundary
Below 70 mg/dL (3.9 mmol/L): something sugary, and tell someone nearby. Above 350 mg/dL (19 mmol/L): how do you feel, and tell an adult or caregiver. Never the word “emergency”; never medical advice beyond talking to a doctor or caregiver.
Why Answers a clear medical boundary, and keeps parents in the loop when it matters.
Decision 5
Keep as little as possible
Onboarding asks for a name and a glucose unit once, and infers the unit from the number if it isn’t given. The profile holds only those two things.
Why Answers minors’ data is sensitive.
From Dia’s conversation spec
Teen: just checked, 142
Dia: not bad at all 💪 was that before or after you ate?
Teen: ugh 280 again
Dia: oof, that’s frustrating. how are you feeling rn? did anything different happen today?
Prototypes
The prototype is a working service rather than a clickable mock: the experience is the conversation, so it needs a real model behind it.
-
WhatsApp
The teen texts Dia
-
Twilio
Passes the message on
-
Web service
Python, on Railway
-
Claude
Replies and extracts data
-
Supabase
Log and profile
Alongside the conversation, a companion app prototype shows what the log adds up to, and who else can see it.
Companion app prototype, shown with test data.
Iteration
- Research narrowed in three passes: a broad market analysis, then competitive benchmarking, then a one-page brief for the concept itself. The concept, called SafeZone in the research, became Dia.
- Memory was added after the first version: a small profile table, so Dia stops asking for your name and unit once it knows them.
- Failure has a voice too: if the model call fails, Dia answers “ugh sorry, i glitched for a sec 😅 try again?” instead of an error.
The sharing screen is a first pass at the role of parents and doctors. Before a real teenager uses Dia, consent, and what gets stored and for how long, need a design of their own.
What I learned
AI shaped the exploration; it didn’t make the product decisions. Which pattern to act on, what Dia sounds like, where its safety lines sit and what it must never say were design work.