PLACEHOLDER · DROP IMAGE HERE
Klaro hero · 3 phone screens (CHK-01 · CHK-05 · RES-01A)
Klaro - Symptom triage for the German DiGA track
A self-initiated concept app for symptom intake, calibrated escalation, and a doctor-ready SBAR handoff. (German DiGA / MDR Class IIa used as a design constraint.)
Timeline
2026
Solo · evenings & weekends
Role
Concept · Research
IA · UI · Design System
Constraint
DiGA / MDR Class IIa
used as design constraint
Problem
Symptom-checker apps in the German market either over-reassure users (sending real emergencies home with a "stay calm" screen) or hedge so hard that everyone gets pushed to the ER. Neither pattern serves patients or the system. There is no shared design language for calibrated medical confidence, and nothing that hands a doctor a clean structured summary at the end of the flow.
{This mattered to me because mis-calibrated triage is a real safety issue in DACH primary care - false reassurance kills, false alarm clogs ERs. The design constraint had to do real medical work.}
Outcome
A Transparent Triage Engine: every result shows its confidence band, calibrated escalation (Low / Moderate / Emergency) drives the CTA, and the session ends with an SBAR / SHBE summary the patient can hand to a doctor or call into 112. Self and Proxy modes, re-check loop, and a component library shaped by DiGA accessibility constraints round out the system.
THE PROBLEM
Four problem dimensions, four design responses.
Two are psychological and technical barriers unique to AI products. Two are clinical failure modes specific to symptom-checker apps. Each problem requires a different design move.
THE DESIGN QUESTION
How do you make an AI health assistant that feels calm and simple to use, still takes the clinical and regulatory rules seriously, and never uses slick design to cover up how unsure the model really is?
What I kept coming back to: be honest about what the model doesn't know.
AI · Psychological
The Black Box Trust Barrier
Users are naturally highly skeptical of medical diagnoses generated by algorithms. Raw machine-learning outputs without context cause anxiety and rejection.
DESIGN FOCUS
Explainable AI (XAI) · Progressive disclosure patterns that show the why behind every conclusion
AI · Technical
High-Input Friction vs. Model Accuracy
Accurate medical assessments require precise, highly granular user inputs. But long diagnostic intake forms spike user drop-off rates and feed the model worse data.
DESIGN FOCUS
Smart Contextual Conversational Intake · Breaking complex medical taxonomies into dynamic, one-question-per-screen UI steps
Clinical · Failure mode
False reassurance
A system that downplays a 0.5%-probability emergency. "Don't worry, it's probably tension" at 3 a.m. for a thunderclap headache is not a UX bug, it is patient harm.
DESIGN FOCUS
Calibrated escalation · Severity-override rules · MDR Class IIa auditable dismissals
Clinical · Failure mode
Over-escalation
A system that escalates every input to "see a doctor" to stay safe. Users abandon. The German healthcare system over-loads at exactly the moment it is already operating at capacity.
DESIGN FOCUS
Calibrated routing · Never "GP just in case" · Confidence Gap Warning over false top-3 lists
Regulatory constraints
Five constraints shaped the design: the IEC 62366-1 usability process, post-market surveillance with long-term retention of anonymous events, on-device data by default under GDPR, the DiGA Freischaltcode through statutory insurers, and emergency dismissals that record the user's deliberate choice.
My Research Approach
I couldn't recruit a clinical user panel for a solo concept project, so I designed the research around what I could honestly access. Desk research on the DiGA / BfArM fast-track requirements, a structured audit of seven existing symptom-checker apps (Ada, Symptomate, NHS 111 online, K Health, Babylon, MD live, Doc.com), and ~12 informal conversations with friends and family members who had recently used such tools or called the 116117 non-emergency line. This shaped the assumptions; I'm transparent in the case study about what's verified vs. what's a designed hypothesis.
User Research and Key Findings
Synthesised pain points across the audit and the informal interviews. Six themes kept reappearing - each became a design constraint for the Transparent Triage Engine.
1. Symptom intake felt like a quiz, not a conversation.
Existing apps used long, branching multiple-choice trees that broke flow and made people give up halfway. Users described it as "filling out a tax form while sick."
2. Results were either too scary or too soft.
Either every cough led to "see a doctor today" or a clear emergency got a "monitor at home." There was no calibrated middle, and no honest "we are X% sure" signal.
3. No one trusted a result they couldn't explain.
Participants said they would believe the app more if it showed *why* it landed on a diagnosis - which symptoms mattered, which it weighed less. Pure black-box scoring kept them on Google.
4. Caring for someone else broke the flow entirely.
Three of twelve interviewees were proxy users - checking on a parent, child, or partner. No app handled this cleanly; pronouns broke, history mixed, sex/age assumptions failed.
5. The doctor handoff was always manual and lossy.
After triage, users either screenshotted the result or re-typed everything into Doctolib. Nothing produced a structured summary a clinician could parse in under 30 seconds.
6. Re-checking later was punishing.
Symptoms evolve. Every app made you redo the entire intake - no delta questions, no awareness that you had triaged the same complaint two days ago.
What this changed in my approach
I stopped designing a “smarter symptom checker” and started designing a Transparent Triage Engine. The product is no longer the diagnosis - the product is the calibrated escalation, the explainability, and the handoff. Every screen had to earn the user’s trust by showing how confident it actually was, and every dead-end (proxy, re-check, emergency override) became a first-class flow instead of an afterthought.
RESEARCH & PERSONAS
Three personas.
Personas aren’t decorative on this product. Each one identifies a specific failure mode the design has to engineer against - a separate guardrail in the system.
N
Nadia, 34
Health-anxious researcher
ABOUT
34 y · Female · Berlin · Self-check
TOP RISK PRIORITY
Panic abandonment
“I’ll be up googling ‘thunderclap headache’ until 4 a.m. - Klaro has to tell me if this is the real thing or not.”
FAILURE MODE
Panic-driven abandonment. If the interface produces anxiety on top of an already-anxious user, the session ends and the next time she just goes to A&E.
DESIGN RESPONSE
Dark mode auto-activates via prefers-color-scheme. Cap at 3 conditions. Calibrated escalation - never “GP just in case”.
M
Marcus, 52
Pragmatic decider
ABOUT
52 y · Male · Hamburg · Self-check
TOP RISK PRIORITY
Missed emergency
"I trust apps that don't cry wolf. If you tell me to call 112, I expect you to mean it."
FAILURE MODE
Over-reliance. The cried-wolf effect - if Marcus has been escalated needlessly twice, he’ll ignore EMG-01 the third time, which may be the one that matters.
DESIGN RESPONSE
Two-step emergency dismiss writes acknowledgement to audit log. Severity colour mapping is rigid. Disclaimers only where they add information.
P
Priya, 28
Junior nurse · proxy mode
ABOUT
28 y · Female · Munich · Proxy-check
TOP RISK PRIORITY
Wrong clinical detail
"If I show this to her doctor and one detail is wrong, we'll lose hours. I need the export to be clinically correct, not friendly."
FAILURE MODE
Trust destruction if clinical logic is wrong. Priya is the smartest user; her mistake-tolerance is the lowest.
DESIGN RESPONSE
Proxy mode treated as a real use case, not bolted on. The SHBE export follows German anamnesis order. Events are logged so there's an auditable trail.
Quotes are illustrative - written to capture each persona’s situation, not transcribed from real interviews.
INFORMATION ARCHITECTURE
The full user flow.
Onboarding → Symptom Check → AI Engine → Results → one of four legitimate exits. Branch lines are coloured by clinical severity. The red dashed shortcut bypasses the engine entirely - client-side red-flag detection with zero network dependency.
01
The 2-hour Active Episode Gate
When a user attempts a fresh check within 2 hours of completing one, the app intercepts with time-since-last-check, previous result, and a direct link to 116 117. The user can still proceed, but the muted ghost-link styling tells them the system thinks they shouldn't.
02
The two-step emergency dismiss
Dismissing the EMG-01 warning requires both an acknowledgement checkbox and a separate tap on a now-muted CTA. The checkbox writes a structured event to the audit log. The user is free to disagree with the engine. The system is not free to forget that disagreement.
03
The probability cap at three conditions
Showing 8 to 10 possible diagnoses, common in earlier products, optimises for completeness and tends to raise anxiety. Klaro caps at three, always probability-ranked, never alphabetised. Anything below the threshold rolls up into a Confidence Gap Warning, which routes to 116 117 instead of listing more maybes.
Structural pivots
v1 used segmented progress dots, they broke when the engine added follow-up questions. Replaced with phase-based labels. v2 attempted pure conversational UI, users lost context, couldn't edit. Replaced with hybrid modular: one question per screen plus a Review screen with discoverable per-row edit. v3 introduced no-ghost-drafts: half-collected symptom data is worse than no data.
Ideation and
Conceptual Design
I sketched the entire flow on paper first - every screen, every escalation branch, every dead-end. Two complete attempts went in the bin before the calibrated-confidence model emerged. Below: the working pages where the Transparent Triage Engine got found. Focused on making sure the model could actually carry the result without lying.
Sarah, 34 · Female
Understanding your symptoms
How long have you had
this headache?
This helps us understand if it's a new or ongoing symptom.
Just started
Within the last hour
A few hours
Started today, a few hours ago
1–2 days
Started yesterday or the day before
✓
3–7 days
Lasted most of this week
More than a week
Ongoing for over a week
Next
Skip this question
9:41
9:41
ANALYSING YOUR SYMPTOMS
✓
Symptoms
AI Engine
Results
Comparing with clinical data...
Matching your symptoms against verified medical patterns
Analysing...
65%
✓ Symptoms logged and verified
→ Comparing with clinical data...
Preparing personalised results
Cancel check
9:41
Sarah, 34 · Female
Your Assessment
Based on: mild headache, slight fatigue
Low - Monitor at home, no immediate care needed
Most likely
58%
Tension Headache
(Spannungskopfschmerz)
A dull, aching head pain with a sensation of tightness. Common in people with stress or poor posture. Usually not serious.
Why this condition? →
Second possibility
Mild Dehydration
27%
Third possibility
Mild Viral Illness
9%
What you can do at home
💧
Stay hydrated
Aim for 2L of water today. Avoid caffeine.
🌡
Track your temperature
Check every 4 hours. Seek care if above 39°C.
😴
Rest in a quiet room
Dim lights, minimal screen time for 30 min.
Find open pharmacy near you
Enter PLZ
Location off - enter postal code
We'll check in with you in 24 hours
Continue monitoring at home
9:41
Class IIa SaMD · BfArM DiGA
Klaro
Understand your symptoms.
Know your next step.
Klaro analyses your symptoms, shows you the most likely causes with honest confidence scores, and guides you to the right level of care.
This is not a diagnosis. It is a decision support tool.
Get started
No account required. No login. No email.
9:41
<
Nadia, 34 · F
What's bothering you?
Describe your main symptom in your own words
headache
Headache
General head pain - tension, pressure or throbbing
+
Headache with nausea
Pain combined with feeling sick
+
Headache with visual changes
Pain with blurred vision or spots
+
Headache
×
Safety monitor active
Common symptoms
Headache
Stomach pain
Fever
Back pain
Sore throat
Cough
Continue
9:41
×
Doctor Conversation Guide
DE
EN
SHBE Format · Deutsch
S
Situation
Ich habe meine Symptome mit Klaro Triage geprueft. Die Einschaetzung ergab Migraene als wahrscheinlichste Ursache (72% Konfidenz).
H
Hintergrund
34 Jahre, weiblich. Symptome seit 3 Tagen. Kopfschmerzen linksseitig, Uebelkeit, Lichtempfindlichkeit. Schmerzstaerke 6/10.
B
Bewertung
Die Gesamtkonfidenz lag bei 72% (mittel). Weitere Moeglichkeiten: Kopfschmerzen vom Spannungstyp (18%) und Clusterkopfschmerz (10%).
E
Empfehlung
Ich bitte um Ihre Einschaetzung, ob Migraene zutrifft und ob weitere Untersuchungen notwendig sind.
Assessment used for this guide
Migraine (72%) · Tension Headache (18%) · Cluster (10%)
>
Severity: Moderate · Confidence: 72%
Share as text
Print (A4)
Copy to clipboard
Generated from Klaro Triage assessment. This is not a diagnosis.
This guide helps structure your conversation with a doctor. It does not replace professional medical judgment.
9:41
<
Re-check
Klaro checked in · Tap to update your status
Last check
Migraine (Most likely)
24 hours ago
Moderate
How are you feeling?
Since your last check 24 hours ago
Better or resolved
Symptoms have improved or gone away
>
About the same
No significant change
>
Worse
Symptoms have gotten worse
>
New symptoms
I have new or different symptoms
>
Remind me later (+4h)
This re-check expires in 48 hours. After that it will be archived.
Explored multiple approaches:
Three architectures got serious paper time. (a) Pure conversational chat - felt warm but lost the structured trail clinicians need. (b) Form-first quiz with scoring at the end - clinical-looking but cold and slow. (c) Hybrid intake → Comparing screen → calibrated result with explainability bars. The hybrid kept the structure auditable while letting the user see the model think.
Decision Taken:
Went with the hybrid: free-text symptom capture, structured follow-ups only when they change the answer, then a Result screen that always shows the confidence band, the top three matches, and a labeled escalation tier (Low / Moderate / Emergency) tied directly to the CTA. The model never collapses uncertainty into a single number.
Trade-off:
The hybrid is slower than a pure quiz and noisier than pure chat. Two extra screens in the average session. Acceptable cost - the calibrated result is the whole product, and skipping the explainability layer would have rebuilt exactly the problem I set out to fix.
PROCESS · WIREFRAME EVOLUTION
v1, v2, v3. What broke and what survived.
The clarifying-question screen (CHK-03) shifted twice on structural grounds, not aesthetic ones. Each pivot was triggered by a specific usability failure.
v1
Rejected
v1 screen mock
Segmented progress dots
Progress bar stalled when the engine added follow-up questions. Users interpreted it as a bug, then as confused AI, then as a reason to abandon.
v2
Rejected
v2 screen mock
Pure conversational chat
It looked clean on its own but fell apart once I thought through real use. Users lost context, couldn't edit, read AI questions as opinions. Produced no scannable record for the doctor at the end.
v3
Final
v3 screen mock (CHK-03-A)
Hybrid modular · phase labels
One question per screen. Phase eyebrow communicates progress honestly without committing to a step count. Review screen with per-row pencil-edit.
HIGHLIGHTS OF THE DESIGN
Transparent Triage Engine
RES-01A · Low
EMG-01 · Emergency
RES-01D · Confidence Gap
RES-01A · Moderate Result (hero)
PLACEHOLDER · drop hero Triage Result screenshot. Confidence band, top-3 differential, calibrated CTA.
Why I made this call
The single most important screen in the product. Every other DiGA-grade triage app I audited hides the model’s uncertainty behind a single label (“see a doctor” / “monitor at home”). That hides exactly the information the user needs to decide. The Triage Engine surfaces three things on one screen - the confidence band (Low / Moderate / Emergency), the top three differential matches with weighted probability, and a labeled escalation tier that drives the CTA directly. If confidence is low or matches are within a 10-point gap, the system shows a warning instead of pretending it knows. The CTA is never “Continue” - it’s always the exact action: “Continue monitoring at home,” “Book appointment via Doctolib,” “Call 112 now.”
KEY FLOWS, ANNOTATED
Calibrated escalation, end to end.
Five screens carry the model. Each one is doing a specific job the audited apps got wrong. Notes call out the moments where the design earns its keep.
CHK-01
Symptom Entry
Free-text first; structured follow-ups only when they change the answer.
CHK-01 screen
← Free text first - never a quiz. Plain language captures hedge words the model needs.
← Auto-suggestion chips appear under input - not above. They’re a safety net, not the path.
← Safety monitor pulse runs the whole session. Red-flag terms trigger emergency intercept before submit.
CHK-05
AI Processing
Show the model thinking. Never a spinner with no story.
CHK-05 screen
← Three labeled steps: Symptoms logged → Comparing with clinical data → Personalised result. The user sees the work.
← Progress bar maps to actual model state - not a fake timer. If matching takes longer, the bar slows honestly.
← Cancel-check escape route at the bottom. The model is never a hostage situation.
EMG-01
Emergency Override
Surfaces at the first red-flag term. Independent of triage tier.
EMG-01 screen
← Full-bleed red, single page - interrupts any flow the moment a red-flag term appears.
← Call 112 button never moves. Same position on every emergency state across the app.
← Two-step dismiss (checkbox + confirm) - accidental dismissal is the worst failure mode here.
SBR-01
SBAR / SHBE Doctor Guide
Structured handoff a clinician reads in 30 seconds.
SBR-01 screen
← Fixed SBAR sections: Situation / Background / Assessment / Recommendation. German clinical convention.
← One-tap share to Doctolib, email, or print - handoff is rarely a single channel.
← Confidence band re-appears here. The doctor sees exactly what certainty the app claimed.
RCK-03
Re-check, Delta Questions
Symptoms evolve. The app should not.
RCK-03 screen
← Only asks what changed. “Same headache, still 4/10? Any new symptoms?” - not the full intake again.
← Episode-aware: connects back to the original assessment so the doctor handoff shows a trajectory.
← If the re-check pushes confidence up a tier, the user sees the upgrade explicitly. No silent re-rating.
LOCALIZED FOR GERMANY
Designing for German infrastructure
This is where the German specifics mattered most: connectivity, local services, and the rules.
Low-connectivity scenarios
2 a.m. migraine, Berlin Altbau basement
Mobile signal one bar. User types "starker Kopfschmerz". The client-side red-flag scanner runs before any API call. If matched, EMG-01 launches with zero network dependency. If not, processing shows a clear network state with a 30s timeout fallback to ERR-02.
Rural Brandenburg, reading prior result
Past episodes stored locally with full results, severity chips, original SHBE export. Re-read and re-share without re-querying the engine. The Re-check loop stores incremental deltas locally - reporting changes after 24h is not starting from zero.
EMG-02 · Offline Emergency Survival View
When two 112 attempts fail in a row, the app shows a static, cached first-aid panel with numbered steps. If this shipped, that content would need clinical sign-off and versioned retention per MDR Article 10.
Localized ecosystem integration
Doctolib
RES-01A's "Arzttermin buchen" deep-links into Doctolib with symptom context pre-populated. On return, PES-02 adjusts re-check timing based on whether the appointment was booked, declined, or deferred.
116 117
After-hours hotline. CTA triggers tel: link with confirmation overlay. PES-01 asks the single question “Hast du mit der Bereitschaft gesprochen?” and routes accordingly - retry, passive tracking, or EMG-01 escalation.
DiGA Freischaltcode
16-digit prescription code at ONB-01B. Supports TK, AOK, Barmer, DAK, IKK at launch. No-code path leads to a free-tier demo without AI analysis - preserves educational value, gates the regulated medical-device functionality.
Apotheken-Notdienst
Pharmacy locator from the self-monitor path. GPS-aware with PLZ/city-input fallback. No degraded experience for privacy-conscious users; same pharmacies surface either way.
DESIGN SYSTEM & ACCESSIBILITY
Gambetta + General Sans. Severity as semantic colour.
Gambetta (display serif, ≥22px) paired with General Sans (everything else). Two-family pairing carries semantic weight - display serif marks a question or moment of clinical authority; sans serif carries body, UI labels, data.
Severity colour mapping - three differentiators, always
Every severity has colour, text label, and shape per WCAG 1.4.1. Colour never carries clinical meaning alone.
Low
Self-monitor
Moderate
GP appointment
High
116 117
Emergency
112 (full screen)
COLOUR TOKENS · LIGHT + DARK MODE PARITY
background
Page background
surface
Cards, sheets
primary
CTAs, confidence
link
Teal · text links
Banned phrases live in the system as enforceable specs
✗ Exclamation marks in clinical contexts
✗ “May possibly” / “könnte möglicherweise” - double hedge
✗ "Please note that…" / "Bitte beachte, dass…"
✗ Emojis on RES, EMG, CHK, SBR flows
✗ Duration shorthand: “4h” - use “4 Stunden”
✗ “This is not medical advice” alone - legally insufficient
PLACEHOLDER · COMPONENT LIBRARY
8 patterns + 2 interactive · Profile Pill · Severity Badge · Confidence Chip · Phase Eyebrow · Option Row · Continue CTA · Wrap Chip · Segmented Toggle
IMPACT
Clinical & Business Impact
This is a self-initiated concept - no live deployment, no validated KPIs. The impact below is the system’s design intent measured against the DiGA / MDR Class IIa fast-track criteria and the audited competitor baseline. Honest framing.
• Calibrated escalation:
Three explicit tiers (Low / Moderate / Emergency) tied directly to the CTA. Every audited competitor collapsed risk into a single label. The Triage Engine treats the calibration as the primary design surface.
• Explainability built in, not bolted on:
Confidence band, top-3 differential, and contribution weighting visible on every result. Designed to satisfy the BfArM transparency expectation without a separate "about this assessment" detour.
• Structured clinical handoff:
SBAR / SHBE output is part of the flow, not a feature. Estimated 30-second physician parse time vs. the ~3-minute screenshot-and-retype baseline observed in the user interviews.
• Episode continuity:
Re-check loop reuses the original episode state. Trajectory data goes to the doctor instead of disconnected snapshots - addresses the single biggest gap in the audited apps.
• Proxy as a first-class flow:
Caregiver mode (parent / partner / child) doesn't break pronouns, age inference, or history. Three of twelve interviewees couldn't use existing tools for the person they were actually checking on.
• DiGA-aligned by design:
Component library, copy, and data-handling patterns shaped against MDR Class IIa expectations from the first wireframe - not retrofitted at the compliance review stage.
TARGET KPIs · SUCCESS FRAMEWORK
What I'd put on the dashboard.
Since this didn't launch, none of these have data. They're the dashboard I'd want from day one. The numbers are targets, not results.
NORTH-STAR METRIC
Correctly-routed triage sessions per active user, per month.
It would optimise against both failure modes at once. "Correctly routed" means SHBE export reaching a physician plus a short post-session check on whether the user acted on the recommendation.
AI INPUT QUALITY
> 85%
Intake Completion
Minimizing cognitive fatigue during the dense symptom-gathering stage required to feed the AI model precise data.
AI TRANSPARENCY
< 15s
Time-to-Understanding
Ensuring the interface visualizes the AI's diagnostic reasoning quickly and transparently without overwhelming the user.
AI GUARDRAILS
100%
Deterministic Safety Routing
Instantly triaging high-risk language or symptoms directly to emergency physical care paths when AI confidence parameters are low.
ALSO WORTH WATCHING
< 12%
Drop-off per intake step
If people bail mid-intake, the model never gets enough to work with. The number I'd watch most closely early on.
≥ 40%
Re-check return rate
Of people with a non-emergency result, how many come back within 72h to update their status. A rough read on whether they trust it.
100%
Consent on file
Every active user with a stored, timestamped consent record. Not optional under GDPR, and a hard gate for any DiGA path.
Structured output following German clinical convention. One-tap share to Doctolib, email, or print. Confidence band re-appears so the clinician sees the exact certainty the app claimed.
4. Episode-aware Re-check Loop.
Re-check asks only delta questions, links back to the original episode, and surfaces tier upgrades explicitly. The doctor sees a trajectory, not isolated snapshots.
PLACEHOLDER · FULL SITEMAP
Drop the Klaro sitemap export from Figma node 387:2004
What I'd do Differently
→ Run a real moderated study, even small.
Twelve informal conversations is not a clinical user panel. The next version needs n=20+ DACH patients across both self and proxy modes, with the calibrated escalation tested against actual physician second-opinion.
→ Validate the calibration with a clinician.
The Low / Moderate / Emergency tiers are designed against the literature and German triage convention, but the actual thresholds need a GP or emergency physician in the loop.
→ Build the SBAR handoff against real Doctolib data.
The doctor-facing summary is designed against the SBAR / SHBE spec, but I haven't put it in front of a German GP to time the actual parse.
→ The trade-off I made:
Shipping the calibrated-confidence pattern means two extra screens on average vs. a pure quiz flow. I'd want to instrument session-time post-launch and confirm the slowdown doesn't push abandonment up.
THAT'S IT
Klaro · A self-initiated concept · 2026 · Solo, evenings & weekends · DiGA / MDR Class IIa used as a design constraint