The outcome:
Measuring completion rate and time recovered post-launch.
The problem:
Patients answered risk assessments cold, in the room, making consultations longer and the answers less reliable.
Timeline and team size.
2 months, team of 5 (Product Designer (myself), CEO, CTO, Marketing and Medical). My responsibility was designing the flow, testing it with users. I shared the initial phase with
The company.
Nuumad is a digital consultation platform for pharmacists.
01 CONTEXT
Nuumad: online consultation platform for healthcare professionals (HCP).
Nuumad helps pharmacists run consultations with digital PGDs. The USP and pain points were already validated, and the business goal was retention and acquisition, so the work was about deepening an existing product, not proving a new one.
02 PROBLEM DISCOVERY
Where the time was going
Our users spent longer on the risk-assessment page than any other, and check-in calls kept surfacing the same friction. The only way to access and run the RA was during the consultation. To understand the impact, we ran 14 structured interviews with both HCPs and patients.
Here's the HCP's view of risk assessment
03 INSIGHTS
Same room, same moment, four different reasons
Five findings stood out across the interviews. Read together, they weren't five separate complaints, they pointed at one shared moment where the current flow breaks down.
I (HCP) have to record the patient's answers to the risk assessment at the beginning of the appointment.
I (patient) can't think in peace about the answers or look into my medical history because I feel rushed to answer.
Sometimes I'm not exactly sure about the answers, because it's not something I answer every day.
Some of the questions are quite intimate and I don't feel comfortable answering them in the office.
A family member is more knowledgable abut my medical history, but they aren't with me at the appointment.
04 SYNTHESIS
4 symptoms - not 4 problems
Time pressure, recall, and privacy looked like distinct issues, but they shared one root: patients answer at the worst possible moment. Naming that root (the when and where of answering) is what let me define the problem instead of chasing three causes at once.
Time pressure
Recall
Privacy
the when and where of answering
Lengthy and possibly inaccurate consultations
05 PROBLEM DEFINITION & HYPOTHESIS
Hypothesis
The shift was moving from the HCP's point of view to the patient's. I framed the problem, wrote a falsifiable hypothesis, and defined upfront what would prove me wrong at the problem level (not just what would prove a design wrong) alongside the signals that would tell me it worked.
Usually, before forming a hypothesis, I'd run a prioritisation session to understand which problem should be a priority. In this case, the interviews showed a clear pattern and I was able to move straight to problem definition. The criteria for prioritisation are: frequency & reach, severity, strategic fit, evidence strength, tractability.
THE PROBLEM
A patient is trying to give accurate risk-assessment answers, but they're answering cold in the appointment — no time to think, no access to their records, no privacy — which makes the consultation longer and their answers less confident and reliable.
THE HYPOTHESIS
If we let patients answer before and outside the appointment, they'll answer more confidently and accurately and the consultation will shorten, because the blocker is the moment, not the questions.
Patients are either unsure about their medical history or intimidated about the intimate questions, which makes the consultation uncomfortable and lengthy, and patients feel less confident in the information they provide.
WE'D KNOW WE WERE WRONG IF
01 The questions patients stumble on are the same ones they can't answer anywhere — the intimate or genuinely-don't-know ones.
02 Patients report they'd be equally unsure answering at home as in the office.
03 Patients given time + records + privacy who still answer hesitantly
SUCCESS LOOKS LIKE
The outcome: patients arrive having answered the RA accurately and confidently, and the RA no longer eats consultation time.
Leading signals test day to day): share of patients who complete the RA before the appointment, how long it takes them, their self-reported confidence at the point of answering, and how many questions they leave flagged as "not sure."
Lagging signals (prove it worked): time the HCP spends on the RA portion, and how often the HCP has to correct or overturn what the patient entered.
THE CONSTRAINTS
The HCP must still edit or comment on patient's answers
Limited resource (1 engineer and 1 designer)
06 DIVERGENCE
3 comparable options
Every approach could have its riskiest assumption tested by hand, before any build — a desk audit, a Wizard-of-Oz send, a human walkthrough. I sequenced by what each test would teach for the least cost, killed the heaviest option in an afternoon, and let the evidence point to the answer.
Option A: Pre-fill & verify
Riskiest assumption
The info the RA needs actually lives in a record you can pull
Bets the cause is:
Missing information: patients can't recall what isn't in front of them
Patient experiences:
Form pre-filled from their record; they confirm, correct, or flag
Rests on:
Most RA answers already exist in records; verifying beats recalling
Cheapest test:
Desk audit: what % of RA questions are answerable from records? No build.
Build: heaviest
Option B: Private async form
Riskiest assumption
Patients actually complete it ahead of the appointment
Bets the cause is:
Pressure and setting: rushed, watched, in the room
Patient experiences:
Blank form on their own device, at home, untimed, private
Rests on:
Patients have the answers; only time and privacy are missing
Cheapest test:
Wizard-of-Oz: send RA to a few patients ahead via existing channel; watch completion + quality
Build: lightest
Option C: Guided prep
Riskiest assumption
Comprehension is the bottleneck: and a guide can explain safely
Bets the cause is:
Comprehension and confidence: unclear what's asked or what's "right"
Patient experiences:
Guided flow explains each question; "not sure" is a valid answer
Rests on:
Questions are opaque or intimidating, not unknown or rushed
Cheapest test:
Human walks a few patients through verbally; does confidence jump?
Build: heaviest
My thinking & decision:
Every one of the three approaches can have its riskiest assumption validated manually, before any build. No engineering effort is committed to learn whether a bet is even alive.
That reframes prioritisation entirely. I'm sequencing by what each test teaches for the least cost. Approach A is the clearest example: it's the most expensive thing to build (it needs records integration), but its make-or-break assumption - that the RA's answers actually live in a record I can pull from - is answerable in an afternoon with nothing but the question list in front of me. So it goes first.
If the records don't hold the answers, I've killed the heaviest option before lunch; if they do, I've cleared the runway to build it with confidence. Either way I've spent an afternoon, not a sprint.
07 MANUAL TESTS
Deciding what to build
Every approach could have its riskiest assumption tested by hand, before any build: a desk audit, a Wizard-of-Oz send, a human walkthrough. I sequenced by what each test would teach for the least cost, killed the heaviest option in an afternoon, and let the evidence point to the answer.
Option A: Pre-fill & verify
Assumption
The info the RA needs actually lives in a record you can pull
Test outcome
Desk audit of the questionnaire:
only a minority of items were answerable from existing records; most are current-state or lifestyle.
most of the pharmacy's records live offline - on paper
Killed - one afternoon
Option B: Private async form
Assumption
Patients actually complete it ahead of the appointment
Test outcome
Wizard-of-Oz sent to some patients:
most completed before arriving,
answers came back fuller and more confident
even if some weren't filled, users had a basic information
Validated and selected
Option C: guided prep
Assumption
Comprehension is the bottleneck: and a guide can explain safely
Test outcome
Human walkthrough:
helped a little, but confidence rose mainly from time, not explanation, so cause was secondary
used the 'Not sure' learning and merged it with Option B
Parked
My thinking & decision:
The blocker was the moment of answering, not missing data or unclear questions. Move the RA before the appointment, patient-led and private, with the HCP reviewing, carrying a little of C's "not sure" handling into B.
08 SERVICE BLUEPRINT
Current and proposed service pathways
Mapping both states across every lane showed exactly what changes — and what doesn't. The patient's answering moment moves before the appointment, the HCP shifts from data entry to review, and the clinician stays the authority over the record throughout.
Today — risk assessment answered live, in the room
| Lane | Before | During appointment | After |
|---|---|---|---|
| Patient | Books visit, no prep | Answers cold, on the spot — rushed, unsure, exposed on intimate items | Leaves; some answers were guesses |
| Frontstage HCP | — | Reads questions aloud, types answers, waits while patient thinks | Proceeds on possibly shaky data |
| Backstage | Visit scheduled | RA module open in EHR, clinician-entered | RA stored in record |
| Systems | Scheduling | EHR RA form; clock running in-room | Record updated |
Proposed — patient-led, private, clinician-reviewed
Shaded cells mark what changed from today.
| Lane | Before | During appointment | After |
|---|---|---|---|
| Patient | Gets a private link, fills RA at home, untimed — can check records, flag "not sure" | Reviews with HCP; time spent only on flagged or sensitive items | — |
| Frontstage HCP | System sends invite + reminder | Sees pre-filled answers; edits, comments, confirms — stays the authority | Finalises record |
| Backstage | RA generated + sent; responses held as draft | Draft surfaced in EHR for review, not re-entry | Confirmed RA committed, edit trail kept |
| Systems | Secure patient form + draft storage | EHR shows patient draft with edit/comment | Audit trail of clinician edits |
Shaded = changed from current state
My thinking & decision:
Now I know what needs changing in the service blueprint. This means I can move to start writing requirements
09 REQUIREMENTS
Definition of good
Before designing screens, I set goals, non-goals, and requirements, split into what makes the flow work (v1) and what makes it better (v2). The non-goals trace straight back to the approaches the tests ruled out, so scope was decided by evidence, not preference.
GOALS
Business
Recover in-appointment time by moving the RA out of the room
Enable more consultations per day
User
Answer confidently about their medical history
Feel supported when they don't know an answer
NON-GOALS
Replacing the in-appointment form: the HCP keeps authority over the record
Auto-populating answers from records
Building HCP-side analytics or reporting
Changing the RA questions
A comprehension guide
REQUIREMENTS
V1
Patients can answer without setting up an account
State persists: patients return to where they left off
HCP can comment on answers (not edit) keeping patient voice and clinician note distinct
Patients can submit with items flagged "not sure"; the HCP sees the flags
If not submitted before the appointment, the RA reverts to in-appointment with no loss
Form locks once the consultation takes place
HCP sees the form only once the patient has submitted it
Responses handled securely — visible only to the assigned HCP after submission
V2
Patients are sent reminders to complete ahead (form works without it; manual nudge covers day one)
Lock-time updates automatically when an appointment is rescheduled (handle manually at first)
10 UX FLOW
The flow, end to end
Every v1 requirement shows up here as a branch or a state — the not-completed fallback, the per-question "not sure" flag, the two locks. Two actors, one handoff at submission, both paths converging at the consultation.
11 UX & UI DECISIONS
From flow to interface
Where the logical states become real screens: the patient's private entry, the "not sure" option on each question, and the ability to add more comments. Below you can find the annotated screens with decisions behind them. Click the right arrow to view more screens.
12 UNHAPPY PATHS
Edge cases I designed for
A flow is only as good as its unhappy paths. Each one here traces back to an insight from research or a requirement I set before designing.
The patient doesn't know the answer
The situation
Interviews were clear that patients often can't answer confidently ("it's not something I answer every day."). A binary yes/no forces a guess, and a guess is worse than an admission, because the HCP can't tell the difference.
What I did
Gave uncertainty a home at three levels of granularity, rather than one catch-all.
Unsure whether you had it: "Unsure?" on every row, carried consistently across steps
Unsure which vaccine it was: "Unknown" as a first-class option in the dropdown
Unsure about the details: guidance stating an approximate date is acceptable
Why it matters
This is error prevention at the source (Nielsen #5) rather than validation after the fact. It also protects the signal: the HCP sees where the patient was uncertain instead of receiving a confident-looking answer that isn't.
The patient submits, then remembers something
The situation
Answers are locked to the patient at submission, so the HCP reviews a stable set. But people remember things afterwards. That's the nature of recall.
What I did
Chose the one-way gate deliberately and told the patient before they commit, rather than letting them discover it. Anything remembered afterwards is raised in the consultation, where the HCP can comment on the record.
Why it matters
Post-submission editing would help the patient but undermine the clinician's confidence that what they reviewed is what they'll discuss. In v1 I chose reviewer trust; revisiting this is a v2 question.
Edge case branches
The situation
Not every edge case is a screen. Most are branches. These are resolved in the flow logic rather than a bespoke interface.
What I did
User never opens the form → reverts to in-appointment RA, with no loss
Starts but doesn't finish → state persists; returns where they left off
Appointment rescheduled → lock time follows the consultation, not the original date
Why it matters
This is error prevention at the source (Nielsen #5) rather than validation after the fact. It also protects the signal: the HCP sees where the patient was uncertain instead of receiving a confident-looking answer that isn't.
13 FINAL FLOW
The flow from the patient's point of view
The end result, seen the way a patient meets it: an email before the appointment inviting them to complete the risk assessment privately, in their own time: the whole redesign, reduced to one calm moment before they arrive.