Funnel analysis and user research traced the drop-off to the symptom input
Healthily began in 2013 as Your.MD. By the time I joined, its AI symptom checker was a legacy system. I came in to update the outcome screen. My research showed the input needed modernising first, so that became the job.
"I couldn't find the words for what I was feeling."
The system worked as built, so I traced it end to end. Mixpanel drop-off tracking pointed to the first field. When I compared what users typed with the diagnoses they ended on, the gap opened at the input. Fifteen interviews and eight usability tests showed why.
Users could not find the right words for a symptom, and they were unsure which details mattered. They wrote long, skipped the specific part and guessed the spelling. The checker returned a list of similar symptoms rather than the one they meant.
The checker was a Class I medical device, so any change to the input flow triggered clinical re-validation. I made the call to keep the NLP and modernise around it, a direction my competitor research had pointed to.
It was a full version update, with the checker's frontend and its backend symptom ontology redesigned together. The old version relied on natural language processing alone. The new one adds a translation layer between medical terms and everyday language. Autocomplete starts after three characters, each suggestion carries its “also known as” names, and the checker shows back what it heard so users can add or remove symptoms. It asks for further detail through progressive disclosure, when the user needs it.
1 Suggestions as you type
2 What it heard, shown back
3 The consultation
4 A report at the end
I led the clinical knowledge base and symptom ontology behind the AI
Under the search box sat MediBase. I structured it and led it: every condition, its symptoms, its warning signs and the rules for what the checker could safely ask. GPs from the in-house clinical team tested and signed off every mapping before it went live. The medical decisions stayed with the clinicians. I built the system they used to make them.
I extended the symptom ontology so every everyday name links to the clinical term behind it. That link is what lets a suggestion appear after three characters. Feedback mechanisms then kept improving what the AI understood over time.
The everyday-language layer I added
However a patient types it
- Self-care at home
- Pharmacy
- See a GP
- Urgent care · 999emergency
- 1Publish + red-flag gatesNothing reaches a patient un-reviewed.
- 2Symptoms keyed to UMLS CUIs, weightedWeighted scores across coded symptoms decide the outcome.
- 3Inclusion / exclusion rule engineThe logic that decides each outcome.
An A/B prototype test put everyday names under each clinical suggestion
It was a big change to the checker, so we staged it to learn how best to roll it out. The test asked whether the “also known as” names helped users, and which presentation worked best.
Two prototypes went in front of users. A was autocomplete alone, the smaller build. B showed the everyday names under each suggestion, so users could recognise “runny nose” without knowing the medical term, plus a way out when nothing fitted.
A tested worse. Autocomplete hands you a list, but no way to check the medical term is the thing you meant. People wanted their own words back before committing.
B added a step, and completion did not fall. After launch, satisfaction rose from 62% to 67%.
I owned the checker and its design system across three products
The checker lived in three places: the consumer app, the web app and the public site, each built by a different team. As design lead I owned it across all three, working with a junior designer and a brand designer. I covered discovery, user research, prototyping, the build and what came after.
I set the design system, the interaction patterns and the wording. I aligned product, engineering, clinical, legal and commercial teams around one source of truth, so the teams agreed a change once and shipped it everywhere.
As a result, a symptom looked and read the same at every touchpoint.
The homepage, top to bottom.
The home for Dot, the symptom checker.
Dot greets you and offers a route in.
Your day and your trackers.
Accuracy rose 23% and one-star ratings halved before Class IIa certification
Symptom-description accuracy rose 23%, measured on completion outcomes. More users finished. After autocomplete launched, one-star consultation ratings halved, from 13.1% to 6.6%. One tester said: “It helps you describe symptoms more accurately.”
One-star consultation ratings
Lower is better
Satisfaction
Higher is better
Whatever a user typed now routed them to the right place: a GP, a pharmacy or self-care. Red flags were never softened. Chest tightness still ended in a call to 999.
In under a year we modernised the checker's frontend and backend. The confirmation step added time, and some users just wanted to type and go. The checker went from Class I to Class IIa under EU MDR once the improvements were in.
MediBase ended up with every condition, symptom and red flag coded to UMLS.
The fix for the last screen sat at the first step
The brief was the outcome screen, the last step of the flow, and my research traced the cause to the first, the symptom input. From there I led the qualitative and quantitative research, the build, the launch and the iterations after it. Metrics backed every decision, from the A/B test to the post-launch ratings.