Healthcare UX Design for Patients and Clinicians

Mixed-media illustration: a hand-drawn clinic signpost bristles with arrows labelled in jargon, "FU-15", "Results (pending)", "Portal inbox", "Referral mgmt" and "Letters", all traced in orange and pointing in different directions; a real steel robotic arm hanging from the top edge fixes one new lime arrow to the post reading "Your next step: book follow-up".
Noah Chen
Product & Client Success Manager, ANODA
Published
18 min read
18 sections
Industries
Topic

In short

Healthcare UX design is not consumer SaaS with a stethoscope sticker. When patients, caregivers, clinicians and front-desk staff can't tell what happens next, the bill arrives as calls, wasted slots and people who stop using the product. This guide organises the work around critical journeys, the state people arrive in, failure recovery, accessibility, privacy, AI and testing, and shows how ANODA connects the patient experience to care-team work.

In this article
  1. What healthcare UX design covers, and who it serves
  2. Why healthcare is not consumer SaaS with a stethoscope sticker
  3. Start from critical journeys, not from screens
  4. Research with patients, caregivers and clinical staff
  5. Design for the state people are actually in
  6. Make the next safe action explicit
  7. Write for comprehension, not for the chart
  8. Accessibility is part of safety
  9. Privacy, consent and role boundaries build trust
  10. Identity, onboarding and patient records
  11. The journeys that break most often
  12. Clinician workflows, EHR screens and complex data
  13. AI in healthcare products: a draft is not a diagnosis
  14. Compliance is a constraint, not a usability plan
  15. What to test before release
  16. Signals that show the experience is improving
  17. Why ANODA designs the whole care loop
  18. Where to start with healthcare UX

Healthcare UX design is the work of making care journeys understandable, usable and recoverable for everyone in them: patients, caregivers, clinicians and the operations staff who keep the place running. It is not consumer SaaS with a stethoscope sticker on the icon. When a shopping app confuses someone, they abandon a basket. When a healthcare product confuses someone, they miss a refill, skip a follow-up or ring the front desk for the fourth time this week.

In our work designing and auditing digital products, healthcare is where “we’ll fix it in the next sprint” stops being a joke. The mistakes look the same as everywhere else: a form nobody tested, a status nobody explained, an error message written by the backend. The bill is different. Every confused patient turns into a phone call, a repeat visit or a clinician answering the same portal message by hand, and every one of those minutes is paid for twice: once to build the feature, once to clean up after it.

ANODA removes the misunderstandings, dead ends and inaccessible steps between a person and the next safe action. We design the healthcare journey around what patients and staff actually need to do, with clinical owners defining medical decisions and the interface making the next step clear.

What healthcare UX design covers, and who it serves

Healthcare UX covers every digital touchpoint in a care journey: booking, identity and onboarding, consent, results, medication, messages, video visits, home readings, the clinician’s screens behind them and the handoffs between all of it. The product is rarely one app. It is a patient app, a portal, a clinic back office and an EHR, stitched together and pretending to be a single service.

The users are not one persona either. Four groups show up in almost every product we audit, and each arrives in a different condition:

  • Patients use their own phone, often while unwell, in pain, anxious or waiting for news. Some are 19 and impatient, some are 82 with a tremor and reading glasses in the other room.
  • Caregivers act for someone else: a parent booking for a child, an adult child managing a parent’s refills. Most products either ignore them or make them log in as the patient, which is a privacy problem pretending to be a shortcut.
  • Clinicians work in short, interrupted bursts on shared workstations, between patients, with a queue behind them.
  • Operations staff handle scheduling, intake, billing and the phone. They absorb every failure the product lets through.
Illustrative example: a four-column map of healthcare users for a fictional clinic, Larkfield Health, comparing patients, caregivers, clinicians and operations staff by the device they use, the condition they arrive in, what they need next and what breaks for them when the product is unclear.
Illustrative example: one service, four kinds of user, four different bad days.

Design for one group and the others pay for it. A patient flow that skips a step lands on the front desk. A clinician screen that saves a click on data entry sends a vague result to the patient. Good healthcare UX design treats the whole chain as the product, because the patient does.

Why healthcare is not consumer SaaS with a stethoscope sticker

A garden shed built to code is still not a hospital wing. Same bricks, same tools, completely different consequences when a door sticks. Consumer product habits carry the same trap into healthcare. Growth playbooks, streaks, “frictionless” onboarding and optimistic defaults were built for products where a misunderstanding costs a subscription. Here it costs a missed dose, a wasted appointment slot or a person who decides the portal is not for them and never comes back.

Illustrative example: a comparison table of consumer SaaS assumptions against healthcare product reality across six rows: who the user is, the state they arrive in, what an error costs, what “less friction” means, who the data belongs to, and what success looks like.
Illustrative example: the consumer playbook, line by line, and where it breaks in care.

Friction is the clearest example. In consumer products, friction is the enemy. In healthcare, the right friction is a safety feature: a confirmation before cancelling a specialist appointment someone waited months for, a pause before sending a message that should have been a phone call. The skill is not removing friction. It is putting it exactly where a mistake would hurt, and nowhere else.

The same goes for engagement. A healthcare product that people open every day is not automatically succeeding. Someone checking the app five times a morning for a result that isn’t there is not “engaged”. They are worried, and the product is making it worse.

Start from critical journeys, not from screens

Most healthcare redesigns start with screens: a new home page, a nicer dashboard, a friendlier colour. That is putting up new classroom posters while the roof leaks. We start with a list of the journeys that matter, who takes each one, what goes wrong and what a failure costs.

Illustrative example: a critical-journey inventory for a fictional patient app listing six journeys (read a test result, request a refill, book a first appointment, submit a home reading, join a video visit and message the care team) with who takes each one, the most common failure, what it costs and a priority of high or medium.
Illustrative example: rank journeys by what a failure costs, not by how pretty the screen could be.

Ranking by consequence changes the roadmap fast. A confusing settings page is annoying. A result screen that shows a number with no context sends people to search engines and to the phone line at 7 a.m. A refill request that disappears into silence sends people to the pharmacy counter, the clinic and eventually the emergency department. The pretty screens can wait. The journeys that fail loudly, expensively and often cannot.

For each critical journey, write down the trigger, the people involved, the states it passes through, the decisions on the way and the ways it fails. This is dull work. It is also the cheapest insurance you will ever buy, because every hole you find on paper is one you don’t find through a complaint.

A failed journey gets billed three times: once when you build it, once when staff handle the fallout by phone, and once more when the person you paid to onboard stops trusting the app and goes back to calling. That third bill never shows up on the product dashboard. It shows up in the operations budget, where nobody connects it to the design.

Research with patients, caregivers and clinical staff

A teacher who writes the final exam without ever meeting the class gets exactly the results she deserves. Healthcare teams do this constantly: product decisions made by people who have never watched a patient try to book a blood test on a bus, or a nurse chart between two call bells.

Research in healthcare needs the people who use or deliver care, not a convenient panel of office colleagues:

  • Representative patients, including older people, people with disabilities, people with low health literacy, people using the product in a second language and people on older phones. If your participants all look like your team, you have tested the product on the people least likely to struggle with it.
  • Caregivers and proxies, because they carry a large share of the admin and hit the permission walls first.
  • Clinicians and staff, observed in their real setting where you can arrange it. What people say in an interview and what they do with a queue of patients waiting are two different datasets.
  • The people who absorb failure: front desk, call centre, pharmacy liaison. Their tickets and call notes are free research, and most teams never ask for them.

Treat research sessions with the same care as the product itself: plain-language consent, the right to stop, no pressure to share medical details the study doesn’t need, and a clear record of what happens to recordings. Participants are doing you a favour, often on a bad day.

Illustrative example: a research plan matrix for a fictional clinic app mapping participant groups (patients over 70, caregivers acting for a parent, first-time app users, people reading in a second language, nurses on the message rota and front-desk staff) to the task each one attempts and the product decision the finding will inform.
Illustrative example: every participant group is tied to a task and to the decision it will change.

Research only pays if it ends in a decision. Tie each participant group to a task and each task to a product question, and the findings stop being an interesting report and start being a roadmap. If you need a hand structuring that, our UX research for patient and clinician journeys starts exactly there.

Healthcare UX research

Redesigning a care journey on assumptions?

Tell us who uses it and which task keeps failing. We’ll plan research with the patients, caregivers and staff who can actually settle the argument.

Plan the research with us

Design for the state people are actually in

Testing snow tyres in August tells you they are round. Testing a healthcare flow with a calm designer at a big monitor tells you about as much. Real users arrive tired, in pain, frightened, rushed, medicated, holding a toddler, or half an hour into a night shift. Their attention is a fraction of what it is in your usability lab, and their tolerance for ambiguity is zero.

Design choices that follow from that:

  • One decision per screen when the stakes are high. A long form with a progress bar that says “Step 1 of 9” is a small act of cruelty to someone with a migraine.
  • Save progress automatically, and say so. Interruptions are the norm, not the edge case.
  • Front-load what matters today. Before a visit, the person needs three things: when, where, and what to bring or do. Everything else can wait.
  • Say what happens next, with a person or team and a time. “We’ll be in touch” is not a status.
Before and after, illustrative example: on the left a pre-visit questionnaire for a fictional clinic showing “Step 1 of 9”, seven empty fields and “+ 5 more fields below” with no save; on the right the same preparation reduced to “Before Monday’s visit: 3 things to do” (check your medication list, arrive by 10:20, an optional symptoms note), a “Saved automatically” status and “Finish later”.
Illustrative example: the same preparation, written for someone who feels awful.

Tone matters here too. Cheerful microcopy that works in a meal-kit app (“You’re all set!”) reads as tone-deaf next to a biopsy appointment. Calm, specific and brief is the house style for healthcare UI UX design. Save the confetti for the pizza app.

Make the next safe action explicit

An oven dial with no numbers works fine until someone needs a specific temperature. Plenty of healthcare interfaces work the same way: free-text fields for things that should be chosen from a list, silent submissions, buttons that do something irreversible with no preview. They work in the demo. They fail at 11 p.m. when someone is requesting a refill for a medicine whose name they can’t spell.

The rule we apply to every high-stakes step: the interface must make the next safe action obvious, and make the unsafe one hard. In practice that means choosing from what the system already knows instead of typing it again, confirming what will happen before it happens, and showing status afterwards instead of a toast that vanishes in two seconds.

Before and after, illustrative example: on the left a refill request screen with blank free-text boxes for medicine name, dose and notes and a “Request sent” message with nothing after it; on the right a “Refill requested” screen showing the medicine chosen from the patient’s current medicines, the pharmacy on file, the care team that will review it and a status timeline: sent Tuesday 6 October, care team review by Thursday 8 October, ready to collect next.
Illustrative example: pick from what the record already knows, then show where the request is.

Error recovery is the other half. Every critical journey has predictable failures: a slot taken while the user was deciding, a pharmacy that doesn’t stock the item, an expired session, a payment problem, a record that won’t match. Each one needs its own message and its own way forward. “Something went wrong” is not a state. It is a shrug, and in healthcare the shrug turns into a phone call, a lost afternoon or a person who gives up.

Illustrative example: a failure-state map for booking and refill journeys listing five failures (slot taken, record not matched, session expired, pharmacy unavailable, request rejected by the care team) with what the user sees and the next safe action offered for each.
Illustrative example: every predictable failure gets its own message and its own way out.

Audit check

For each critical journey, trigger every predictable failure on purpose: taken slot, expired session, unmatched record, unavailable pharmacy, rejected request.

Failure evidence

One generic error for everything. Sessions that end at the error. Support tickets that start with “the app said something went wrong”.

Correction pattern

Give each failure its own plain message, keep what the person entered, and offer the next safe action, including a human route with opening hours.

Write for comprehension, not for the chart

A lab result written for the lab is a parking sign with five conditions, two arrows and an exception on Tuesdays. Everything on it is technically correct, and nobody can tell whether they are allowed to park. Results screens are the worst offenders: a value, a unit, a letter “H” or “L”, and a reference range in grey eight-point type. The clinician reads it in a second. The patient reads it forty times.

Design for comprehension without pretending to give medical advice:

  • Say who has seen it. “Not yet reviewed by your clinician” changes how a person reads a number.
  • Say what happens next and when. A named person or team, and a date.
  • Keep the lab’s own reference range, labelled as the lab’s. Don’t invent interpretations the clinical team hasn’t approved.
  • Explain terms in plain words at the moment they appear, not in a glossary three menus away.
  • Separate product guidance from medical advice. The app can explain how to book, message or read a table. It should not decide what a result means for this person.
Before and after, illustrative example: on the left a results list showing “25-OH Vit D 18 ng/mL L” and two more coded tests with a small “Ref. ranges vary” note; on the right the same result named “Vitamin D blood test” with the value against “Northside Lab range: 30–100 ng/mL”, a note “Not yet reviewed by your clinician”, “Dr. Amara Reyes will review it by Friday 9 October”, and actions to message the care team or see earlier results.
Illustrative example: the same number, plus who has seen it, what happens next and when.

Uncertainty deserves the same honesty. If a result is preliminary, say so. If the system does not know when a clinician will review it, say that too, and give a route for questions. People handle “we don’t know yet” far better than silence, which they fill with the worst possible guess.

Accessibility is part of safety

A door handle the size of a pea is still, technically, a door handle. Tiny tap targets, low-contrast text, time limits that log people out mid-form, CAPTCHAs, and sign-in that depends on remembering and retyping a code: each one is survivable on a good day. Healthcare users are rarely having one.

The baseline standard is public. WCAG 2.2, the current W3C Recommendation when we checked on 29 September 2026, added success criteria that read like a list of healthcare portal complaints: Redundant Entry, so people aren’t asked for the same information twice in one process, and Accessible Authentication, so signing in doesn’t depend on a memory or puzzle test without an alternative. Treat the standard as the floor. Passing it doesn’t mean an 82-year-old can book a follow-up alone on her phone. Testing with her does.

Mixed-media illustration: a drawn phone shows an appointment screen with a large “Cancel appointment” button and a tiny “Confirm” link squeezed beside it, both traced in orange; a real steel robotic arm clamped at the frame edge sets a large lime tile reading “Confirm” over the tiny link, sized to a fingertip.
The button that matters is the one people can actually hit, with the hand they have today.

Accessibility in healthcare also means cognitive accessibility: short sentences, one instruction at a time, consistent placement of the same action, and no reliance on colour alone for “urgent”. It means content that works with screen readers and with enlarged system text without the layout falling apart. And it means sessions that forgive: warn before a timeout, let people extend it, and never throw away what they typed.

Before and after, illustrative example: on the left a sign-in screen with a six-digit code that expires in 30 seconds, an image puzzle and a “Session expired, please start again” error; on the right sign-in with a passkey or an email link, a clear “Code valid for 10 minutes” note, a “Need more time?” option and a message that the half-filled form is saved.
Illustrative example: sign-in that doesn't test memory, speed or eyesight.

Here is the money line. Every person who can’t get through the digital route arrives on the phone line or at the front desk instead, and the clinic pays staff to do by hand what the product was bought to automate. Inaccessible design isn’t cheaper. It just sends the invoice to a different department.

Imagine a shop assistant who photocopies your passport, then asks whether that’s all right. That is how many healthcare products handle consent: a 14-page policy, one checkbox, and permissions nobody can find afterwards. It ticks the legal box. It does nothing for trust, and trust is what decides whether someone shares an honest answer on an intake form.

Privacy communication belongs at the moment of the decision, in plain words: what is shared, with whom, why, and how to change it later. Separate what is required to provide care from what is optional, and make the optional parts genuinely optional, off by default.

Before and after, illustrative example: on the left a single checkbox “I agree to the Terms of Service and Privacy Policy (14 pages)” under a block of small legal text; on the right a “Who sees your information” screen explaining that the care team at Larkfield Health needs records, results and messages to provide care, optional toggles for a research programme and SMS reminders, both off, and a note that choices can be changed in Settings.
Illustrative example: consent as a decision people can read, not a hurdle they click past.

Role boundaries matter just as much. A caregiver may need appointments and refills but not every clinical note. A parent’s access to a teenager’s record may be limited by clinic policy. A front-desk colleague needs the schedule, not the results. Design these boundaries explicitly: who can see what, who granted it, and how to revoke it. The alternative is shared passwords, which every clinic officially forbids and quietly tolerates.

Illustrative example: an access matrix for a fictional patient app showing which roles (patient, caregiver with delegated access, parent of a teenager, front-desk staff, clinician in the care team) can see appointments, results, messages, billing and clinical notes, marked Full, If granted by the patient, Clinic policy or None.
Illustrative example: access that someone decided on purpose, and someone else can see and change.

Identity, onboarding and patient records

A hotel that loses your booking because you used your middle name is annoying. A patient portal that can’t match you to your own record is a locked door with your medical history behind it. Identity checks and record matching are necessary. Dead ends aren’t.

The failure we see most often is a verification step that ends in “We could not verify your identity. Please contact support.” No reason, no alternative, no hint of what to try. The person has an appointment tomorrow and no way to fill in the forms.

Before and after, illustrative example: on the left an onboarding error “We could not verify your identity. Please contact support.” with a single Close button; on the right “We couldn’t match your record yet” with the likely reason, options to try the name on the clinic letter, verify with photo ID or call the front desk with opening hours, and a note that the appointment on Wednesday 7 October is still booked.
Illustrative example: a failed match that still leaves the person a way forward, and their appointment intact.

Onboarding should also ask for less. If the clinic already holds the address, the date of birth and the GP, confirm them instead of asking again. Every duplicate field is a chance for a typo that creates a second record, and duplicate records are a mess somebody in operations spends hours untangling.

The journeys that break most often

Some journeys come up in almost every healthcare audit. Here is what goes wrong in each and what we fix first. If most of them live in a patient app rather than a portal, the same rules apply with less screen and more interruption, which is why our mobile app design for patient and clinician apps starts from these journeys, not from a style guide.

Appointments and scheduling

A bus timetable that lists departures but not where the stop is. Booking screens love internal codes (“FU-15 GP”), slots without location or format, and no hint of preparation. The result is people turning up at the wrong site, for the wrong kind of visit, without the thing they were meant to bring, and a slot the clinic paid for goes to waste.

Before and after, illustrative example: on the left a list of appointment slots all labelled “FU-15 GP, RVS-2” with times only; on the right “Confirm your visit”: a 15-minute in-person follow-up on Monday 12 October 2026 at 10:30 at Larkfield Health Riverside with Dr. Amara Reyes, what to bring, when to arrive, free cancellation until Sunday 11 October, “Book this visit” and “Add to calendar”.
Illustrative example: a booking that tells you what, where, how long and what to bring.

Telehealth visits

A video visit is a concert where nobody did the sound check. The clinician is ready, the patient taps “Join”, and the screen says “Connecting…” forever. Camera permissions, microphone, bandwidth and a waiting room that says nothing about delays: all predictable, all testable before the call starts. Plan for the three-way call too: an interpreter, a caregiver or a second clinician joining from somewhere else. And when video fails, the visit should drop to audio or a callback, not to a cancelled slot the clinic still pays for.

Before and after, illustrative example: on the left a dark video visit screen stuck on “Connecting…” with only a Leave button; on the right a pre-call check showing camera and microphone working and a weak connection, a note that Dr. Reyes is running about 10 minutes late, and the options “Switch to audio only” and “Ask the clinic to call you”.
Illustrative example: check the equipment before the visit, and always keep a way back to the phone.

Remote monitoring

Home readings are only useful if someone sees them. Out of sight, out of mind, and a reading submitted into silence teaches people to stop submitting. Remote monitoring needs a visible loop: the patient knows the reading arrived, knows the range their care team set, and knows who will look at an out-of-range value and by when. The thresholds are clinical decisions. Showing them clearly is a design decision.

Illustrative example: a remote-monitoring loop for a fictional home blood-pressure programme: the patient submits a reading, the app confirms it arrived and compares it with the range set by the care team, and the nurse on duty reviews out-of-range readings the same working day; below, the message the patient sees, including what to do if they feel unwell.
Illustrative example: a reading is only useful if the patient can see who will look at it, and when.

Messages and handoffs

The classic healthcare failure is the left hand not knowing what the right hand is doing. A patient sends a message, it lands in a shared inbox, three people assume someone else has it, and the patient hears nothing. The design fix is ownership you can see: who received the message, the expected reply time, and a clear line about what the message channel is not for.

Before and after, illustrative example: on the left a patient’s message about feeling dizzy on new tablets shows only “Sent”; on the right the same message is marked “Received by the Larkfield care team” on Tuesday 6 October, with “Usual reply within 2 working days, by Thu 8 Oct, assigned to the nurse team” and a notice that messages are not for urgent problems, with a number to call instead.
Illustrative example: "Sent" is where the patient's worry starts. Ownership and a date are where it ends.

Clinician workflows, EHR screens and complex data

A guard dog that barks at every leaf is useless the night a burglar turns up. Clinician software trains the same reflex: dozens of alerts with the same red badge, most of them irrelevant, so people learn to click through all of them. Alert fatigue is a design problem before it is a discipline problem.

Clinician-facing healthcare UX best practices come down to respecting a scarce resource, their attention, with a queue waiting. Group by urgency and reason, not by arrival time. Put the one decision in front and the supporting data one click behind it. Keep layouts stable so muscle memory works. Show where a number came from and when it was recorded. And never make a clinician retype what the patient already entered.

Before and after, illustrative example: on the left a clinician inbox in a desktop window with nine identical red “Alert” rows sorted by time; on the right the same inbox grouped into “Needs a decision today” with two items (a blood-pressure reading above the care-team range and a refill declined by the pharmacy), each with its source, time and owner, followed by “Review this week” (4) and “For information” (3).
Illustrative example: nine red badges are noise. Two items with reasons and owners are a to-do list.

Complex data needs the same discipline. Trends beat tables of raw values, units and dates always travel with numbers, and missing data looks missing rather than like a zero. The same goes for patient-facing charts from wearables and home devices: a line of readings without the care team’s range, the date of each reading and an honest gap where the device was off is a very pretty source of anxiety. Every minute a clinician spends hunting through tabs is a minute the clinic pays for and the patient doesn’t get.

AI in healthcare products: a draft is not a diagnosis

AI doesn’t impress us. It is new machinery for the same old problem: a product presenting something with more confidence than it has earned. Think of a line judge who is confident, fluent and watching a different match. Generated summaries, symptom checkers and chat assistants can be genuinely useful, as long as the interface never presents generated output as clinical truth.

Mixed-media illustration: a drawn chat card from an app assistant carries a bold orange label “Diagnosis” across the top; a real steel robotic arm hanging from the top edge peels the orange label away, revealing a lime label underneath reading “Draft for your clinician to review”.
Same text underneath. Very different promise on top.

Design rules for AI features in care:

  • Label it for what it is. A draft summary, a suggestion, a question to ask your clinician. Never a diagnosis.
  • Show what it is based on. “Based on what you entered today”, not an air of omniscience.
  • Keep a clinician in the loop wherever output touches clinical decisions, and show the person when that review has or hasn’t happened.
  • Drop the confidence percentages. “92% likely” means nothing to a worried person and too much to a lawyer.
  • Make it editable before it is sent, so the patient can correct what the model misunderstood.
Before and after, illustrative example: on the left an assistant card “AI diagnosis: Likely migraine, Confidence: 92%” with a “Book treatment” button; on the right a card labelled “Draft summary for your clinician” and “Not a diagnosis”, listing three reported symptoms “Based on your answers today”, a warning to call emergency services for severe or sudden symptoms, and the buttons “Send to Dr. Reyes for review” and “Edit before sending”.
Illustrative example: the assistant prepares the conversation. The clinician still has it.

Compliance is a constraint, not a usability plan

Passing the building inspection proves the stairs meet the code. It doesn’t prove anyone can find the stairs. Compliance works the same way in healthcare products. Privacy, security and accessibility requirements are real constraints, and good design works inside them from the first sketch. But a compliant product can still be unusable, and “legal signed it off” is a cover-your-backside strategy, not a user experience.

Mixed-media illustration: a drawn phone screen shows a patient portal drawn as a maze of dead-end corridors traced in orange, with a framed certificate reading “Compliance: passed” pinned beside it; a real steel robotic arm from a table clamp at the frame edge traces a single lime path through the maze with its fingertip to a door labelled “Book follow-up”.
The certificate is real. So is the maze.

The opposite mistake is just as expensive: treating every requirement as a reason to add a wall of text, another checkbox, another timeout. Talk to your compliance and security people early, ask what the requirement actually protects, and design the least painful way to meet it. They usually prefer that to rewriting the terms page for the fifth time. “First, do no harm” is a fine oath. Most roadmaps never took it.

What to test before release

Tasting the sauce after it has gone out to four hundred guests is not quality control. It is an apology tour. Healthcare products need testing before release, on the critical journeys, with representative people, and on the unhappy paths as well as the happy ones.

Illustrative example: a pre-release test plan listing six critical scenarios (book a follow-up visit, read a new result, request a refill, recover from a failed record match, join a video visit on a weak connection, act for a family member) with the participants for each and what counts as a pass.
Illustrative example: every critical journey gets a real task, real participants and a pass signal agreed in advance.

What we check before a healthcare release, at minimum:

  • Task completion on critical journeys, unaided, by representative participants, including older users and assistive-technology users.
  • Comprehension: after reading a result or instruction, can the person say in their own words what happens next?
  • Failure paths: trigger each predictable error and check that the person can continue.
  • Roles: log in as patient, caregiver and staff member and check that each sees what they should, and nothing more.
  • Interruptions: leave mid-flow, come back later, switch devices, and see what survives.
  • Accessibility: automated checks plus manual testing with screen readers, zoom and keyboard.

If the product is already live and people are struggling, start from evidence rather than a redesign. A focused UX audit of a live healthcare product finds the most consequential problems first, so the fixes go where the phone calls come from.

Focused UX audit

Your portal works. Your front desk says otherwise.

We review the critical journeys in your live product, find where patients and staff get stuck, and rank the fixes by what each failure costs you.

Book a focused UX audit

Signals that show the experience is improving

Downloads count the people who came through the door. Healthcare cares whether they reached the right room. Measure the critical journey and the work around it: whether patients reach the next step, whether staff have the information they need, and where calls or rework still accumulate. Clinical owners can connect those product signals to the care measures they manage.

Illustrative example: three columns for measuring a healthcare product: product signals design can move (task completion per critical journey, drop-off by step, errors followed by a successful retry, tasks finished only on a second or third try), operational signals the clinic feels (calls about tasks the app should handle, portal messages needing manual handling, booked slots left unused, duplicate records), and what neither proves (clinical outcomes).
Illustrative example: connect task completion to the operational work around the patient journey.

Useful product signals: completion rate per critical journey, where people drop off, how often an error is followed by a successful retry, and how many people finish a task only on the second or third attempt. Useful operational signals: calls and messages about tasks the product should handle, requests needing manual rework, unused booked slots, duplicate records. Watch them before and after a change, per journey, and you’ll know whether the work paid.

Use these signals to focus the next design decision: the journey patients can now finish, the repeated question staff no longer need to answer and the care-team handoff that has become clear. Keep clinical measures with the people responsible for care, and connect product improvements to the work they support.

Why ANODA designs the whole care loop

A patient portal can look modern while patients still call to ask what a result means, staff re-enter the same information and nobody can see who owns the next step. Replacing the dashboard theme leaves that cost running. ANODA designs the connected journey across patient, caregiver and care-team work: the information each person needs, the next action, the failure states and the handoff.

For Clay Healthcare, our work included auditing and redesigning the care-team web CRM and designing the patient mobile experience on a shared design foundation, with flows, wireframes, interface states and an organised handoff. The value of that approach is a care loop that reads as one service rather than separate screens competing for the same information.

Bring ANODA the journey patients abandon or staff work around. We will make the next step clear, keep the right information with the right role and give engineering a coherent design to build. The outcome you are aiming for is fewer avoidable questions, less rework and a healthcare product people can use with confidence.

Where to start with healthcare UX

If this guide made you uneasy about your own product, good. That is cheaper than a complaint. Start in this order, and stop at the first question without a clear answer:

  1. Do we know who uses each critical journey and in what condition they arrive?
  2. Have we ranked those journeys by what a failure costs?
  3. Have we watched representative patients, caregivers and staff attempt them?
  4. Does every high-stakes step show the next safe action, and every failure a way forward?
  5. Can a person with low vision, a tremor or a second language complete them alone?
  6. Do people know who can see their information and who will act on it, by when?
  7. Do our journey and operational measures show where patients and staff need the next improvement?

The bill for leaving it alone never stops arriving: in calls, rework, empty slots and people who quietly stop using the product you built for them. Define the user and the clinical context, make the next safe action explicit, validate with representative people, and keep product guidance apart from medical advice. That is healthcare UX design. The rest is decoration.

Healthcare product design

Patients, clinicians and the front desk, in one journey that holds together.

Bring us the product, the people who use it and the constraints you work under. ANODA will design the journeys, states and handoffs your team can build, so patients know what to do next and staff can keep the care loop moving.

Talk to us about your healthcare product

Related reading

All articles