Healthcare UX design: designing for clinicians, patients and regulators

Good healthcare UX design makes the safe action the easy one for three audiences at once: clinicians working under time pressure and interruption, patients who differ widely in health literacy, ability and circumstances, and the regulators and assessors who will ask for evidence that use-related risks were found and controlled. What sets it apart from other product design is that a use error can harm someone. Which rules apply depends on what the product does and where it is sold, not simply on the fact that it handles health information.

This guide starts with that question, because it decides how much evidence the design work has to produce, and then takes each audience in turn. It is a design guide, not legal advice: classification and compliance decisions belong to your regulatory and legal leads.

Which rules apply where

Many health products sit under more than one of these at once. A patient app that also sends readings to a clinician dashboard can touch privacy law, accessibility law and, depending on its claims, medical device rules.

Two boundaries are easy to misread. First, "health" does not mean "medical device". A booking app or a care-coordination tool does not become a device because it handles health information, and FDA's general wellness policy, revised in January 2026, describes low-risk products intended only for general wellness. The guidance says a product is not a general wellness product if its labelling, advertising or user interface refers to specific diseases or prompts specific clinical action, so the words on its screens are part of that boundary, so treat claim copy as something your regulatory lead reviews. Second, HIPAA does not follow the data everywhere: it applies to covered entities and their business associates, and a direct-to-consumer app outside that relationship is more likely to meet the FTC rule instead.

Designing for clinicians: protect their attention, not just their time

The evidence on clinical software is not flattering. In a survey of 870 US physicians, electronic health records scored 45.9 out of 100 on the System Usability Scale, in the bottom 9% of scores across other industries, and each point of better usability was associated with 3% lower odds of burnout (Melnick and colleagues, Mayo Clinic Proceedings, 2020). A time-and-motion study of 57 physicians found that for every hour of direct clinical face time, nearly two more went on EHR and desk work during the clinic day (Sinsky and colleagues, Annals of Internal Medicine, 2016). Both are survey or observational studies of US doctors, so they show the size of the problem rather than which design change fixes it. Five principles follow, the first four resting on a randomised trial, a literature review or FDA guidance rather than on surveys alone.

Design for interruption, not for a quiet desk

Clinicians are interrupted, share workstations and move between patients. FDA's human factors guidance asks manufacturers to describe the real use environment, including noise, lighting, clutter and distraction, and to design for it. For software, that means a task that survives being abandoned halfway: draft state that persists, a clear "where was I" on return, and no silent timeouts that discard work.

Make the patient's identity unmistakable where the action happens

Wrong-patient errors are a design problem with trial evidence. In a randomised trial covering more than 900,000 ordering sessions, an alert asking clinicians to confirm the patient reduced a marker of wrong-patient orders by 16%; asking them to re-enter the patient's identifying details reduced it by 41% (Adelman and colleagues, JAMIA, 2013). Our reading is that the lesson extends beyond ordering: friction that requires attention works better than a dialogue that can be dismissed by habit. It also costs time (in the trial, about 6.6 seconds per ordering session against 0.5 seconds for the alert), so it belongs only where the consequence justifies it.

Keep alerts few enough to be believed

A 2006 review of 17 studies found drug safety alerts overridden in 49% to 96% of cases, and noted that an override is not always wrong (van der Sijs and colleagues, JAMIA, 2006). The authors pointed partly to the alerting systems themselves: low specificity, unclear information content and unnecessary workflow disruptions. Treat the override rate of each alert as a design metric. In our judgement, an alert that is overridden most of the time is likely teaching clinicians to ignore the next one.

Show the basis of every recommendation

FDA's clinical decision support guidance is, in effect, a specification for an explainable interface. To stay outside device regulation, it recommends that software tell the clinician the intended user and population, the inputs it relies on, a plain-language summary of how the recommendation was developed and validated, and the patient-specific knowns and unknowns, such as missing or unexpected data. It asks for this to be presented in a way that "avoids information overload", with the most decision-relevant information first and more detail on request. It also names automation bias, the tendency to over-rely on an automated suggestion, and treats time-critical use as a reason the clinician cannot independently review the basis. The same discipline is good design for any AI feature in a clinical product; our guide to human-in-the-loop UX patterns covers where to put the human check.

Keep evidence, interpretation, authority and action visibly separate

When data comes from another system, show its source and when it was last updated, so a failed feed is not read as a normal result. A summary can look like a diagnosis, a recommendation can look approved, and a completed form can look like completed care. The interface should show which of these a person is looking at, who is allowed to act on it, and what record the action creates.

Designing for patients: write and build for the person having a bad day

Patients use health products when they are unwell, anxious, caring for someone else, or all three. The literacy evidence sets the baseline. In England, 43% of working-age adults were below the level needed to understand and use everyday health information materials written in text, and 61% once the material involved numbers (Rowlands and colleagues, British Journal of General Practice, 2015). In the US, the 2003 National Assessment of Adult Literacy placed 36% of adults at basic or below-basic health literacy.

Write for the four in ten, and test numbers separately

The NHS service manual's health literacy guidance recommends researching with people who have low health literacy, and notes that this benefits all users. Treat readability scores as a way to find problem pages, not as proof of understanding. Test anything with numbers (doses, test results, risk, costs) on its own, because that is where the larger share of people struggle.

Design for access needs from the start

Use WCAG 2.2 AA as the floor, then test with people who use screen readers, magnification, switch access and voice control, and with older users. Point 5 of the NHS service standard asks teams to make sure everyone can use the service, including people who are offline or less confident online, so plan the assisted and offline route as part of the product, not as an exception.

Design for the person acting on someone's behalf

Parents, adult children and paid carers use health products on the patient's behalf. Proxy access needs its own permissions, its own wording ("your mother's appointment", not "your appointment") and a clear record of who did what.

Make privacy and consent something people can see

Show patients who can see their information and what has been shared. Where consent is the lawful basis under GDPR, Article 7 requires that withdrawing it is as easy as giving it, so the "stop sharing" control should be as findable as the "share" button. Be careful not to build consent screens where consent is not the basis: care delivery can rely on a different Article 9 condition, such as Article 9(2)(h) for the provision of health or social care, and a consent dialogue that changes nothing misleads the patient. Ask your data protection lead which basis applies, and design the transparency for that basis.

Say what the product is not for

Every patient product needs a clear route for when the app is the wrong channel: urgent symptoms, a result that worries someone, a question only a clinician can answer. That escalation copy is also part of what the product claims to do, so it is one of the places where design and regulatory status meet.

Designing for regulators: the design work is the evidence

Regulators and assessors do not use the product, but they read the record of how it was designed. For a medical device, FDA's human factors guidance and IEC 62366-1 describe broadly the same chain, and each link is a design activity:

1. Describe who uses it, where and for what. IEC 62366-1 calls this the use specification. FDA treats user populations as distinct when their characteristics would likely affect how they use the device or when their tasks differ, for example clinicians and lay users, or adults and children.
2. Find the critical tasks. FDA defines a critical task as one which, if performed incorrectly or not at all, would or could cause serious harm, where harm includes compromised medical care. A use-related risk analysis lists every task and marks which are critical.
3. Iterate with formative evaluation. Early tests with prototypes, run to find design weaknesses and unanticipated use errors while the interface can still change.
4. Validate the final interface. FDA's human factors validation testing uses an interface that represents the final design, representative users and sufficiently realistic conditions, and recommends, in general, at least 15 participants from each distinct user population (more for some device types).
5. Trace it. Each critical task should connect to the risk it carries, the design control that reduces it and the test that shows the control works.

How much of that record goes into a US submission now depends on risk. FDA's guidance on the content of human factors information in marketing submissions, finalised on 29 May 2026, sorts submissions into three categories, and only the highest asks for a full report with validation testing. The work still has to be done to know which category applies.

Products that are not devices meet a lighter version of the same idea. In England, DCB0129 expects the manufacturer to run clinical risk management for the system, and the hazards that come from how people use the interface belong in that hazard log. A US EHR module certified under 170.315(g)(3) must document its user-centred design process and report summative test results. In both cases, a team that has written down its users, its critical tasks and its test findings has most of the evidence already.

A practical rule: if your team cannot name the critical tasks in your product, it is not ready to design the screens that carry them.

When the three audiences pull against each other

Many of the hard decisions in healthcare UX are trade-offs between these audiences. These rules are a starting point for settling them; your clinical and regulatory leads decide where the lines finally sit.

Where Tcules fits

Tcules is a digital product design studio creating ambitious new software products and making established ones better, with product design as the foundation and design engineering and software development carrying the work into launch-ready software. For health and care products, that work begins with the real care or operating pathway: the people involved, the evidence they use, the decisions each role may make, and the hand-offs where things go wrong. Your clinical, legal and regulatory owners decide which controls apply; we design and build the agreed product behaviour within those decisions. See how we approach HealthTech and care product design.