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
- What healthcare UX design covers, and who it serves
- Why healthcare is not consumer SaaS with a stethoscope sticker
- Start from critical journeys, not from screens
- Research with patients, caregivers and clinical staff
- Design for the state people are actually in
- Make the next safe action explicit
- Write for comprehension, not for the chart
- Accessibility is part of safety
- Privacy, consent and role boundaries build trust
- Identity, onboarding and patient records
- The journeys that break most often
- Clinician workflows, EHR screens and complex data
- AI in healthcare products: a draft is not a diagnosis
- Compliance is a constraint, not a usability plan
- What to test before release
- Signals that show the experience is improving
- Why ANODA designs the whole care loop
- 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.

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.

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.

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.

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.
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.

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.

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.

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.

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.

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.

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.
Privacy, consent and role boundaries build trust
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.
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.

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:
- Do we know who uses each critical journey and in what condition they arrive?
- Have we ranked those journeys by what a failure costs?
- Have we watched representative patients, caregivers and staff attempt them?
- Does every high-stakes step show the next safe action, and every failure a way forward?
- Can a person with low vision, a tremor or a second language complete them alone?
- Do people know who can see their information and who will act on it, by when?
- 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.