Healthcare UX UI

What is healthcare UX UI?

Healthcare UX UI is the research, interaction design and interface design of software used by clinicians, patients and health staff. UX covers field research, task flows and error prevention, while UI covers screens, components, copy and visual hierarchy. Together they decide how quickly and safely people complete clinical and administrative tasks.

Why health software design is different

• Interrupted users: Clinicians move between patients, rooms and devices throughout a shift, so each screen must survive an interruption and make the current patient obvious on return.
• Errors with clinical cost: Selecting the wrong patient, misreading a unit or missing an abnormal result can harm someone, so the design has to prevent and catch mistakes.
• A wide range of patients: Patient apps serve people who are unwell, anxious, older, using a screen reader or reading in a second language.
• Many roles on one record: Physicians, nurses, front desk staff, billers, caregivers and patients see different parts of the same data with different permissions.

Which rules shape clinician and patient interfaces?

Accessibility, device and privacy rules all reach the interface. These are the ones a design plan should name.

• Section 504: Under 45 CFR 84.84, an HHS-funded provider's websites and mobile apps must conform to WCAG 2.1 Level AA. The May 2026 interim final rule set the deadlines at 11 May 2027 for providers with 15 or more employees and 10 May 2028 for the rest.
• WCAG 2.2 as a target: Many teams design to WCAG 2.2 AA, which adds criteria on focus visibility, target size and accessible authentication. Meeting 2.2 AA also meets 2.1 AA.
• FDA human factors: For device software, FDA's human factors guidance expects teams to identify use-related risks and validate the interface with representative users performing critical tasks.
• HIPAA Security Rule: Automatic logoff is an addressable specification in 45 CFR 164.312, which shapes session timeouts, lock screens and what a notification shows on a shared device.
• Section 1557 language access: HHS rules under Section 1557 require covered entities to take reasonable steps to give people with limited English proficiency meaningful access, which affects patient copy and translation.

Certified EHR developers have one more item to check. The HTI-5 final rule, published in October 2026, removed or revised a set of certification criteria, so check its criteria list for the current safety-enhanced design requirement, 45 CFR 170.315(g)(3), before planning certification usability work.

How should research with clinicians and patients be run?

Research works best in the setting where the software is used, with the people who will use it. Interviews in a meeting room miss the interruptions and workarounds that shape a real shift.

• Contextual inquiry: Shadow clinicians during real shifts with consent and the unit's approval, and note every interruption, handoff and workaround such as sticky notes or a second screen.
• Patient and caregiver interviews: Include older adults, people who use assistive technology and people who read in a second language, and talk to caregivers who manage a relative's account.
• Role inventory: List every role and what each may see, edit, sign or delegate, since permissions shape navigation as much as layout does.
• Artifact review: Collect paper forms, printed lists and spreadsheets people keep beside the current system. They show what the software fails to provide.
• Privacy in research: Observing care exposes PHI. Agree with the client which notes and recordings may be kept, strip identifiers from research files and keep screen recordings off personal devices.

Questions that surface workarounds

• What do you write down outside the system, and why?
• Which alert or prompt do you dismiss without reading?
• When did you last pick the wrong patient or order, and what made it easy?
• What do you check in a second system before you trust this one?
• For patients: what did you do the last time you could not find a result or message?

How does the design process move from research to release?

Four stages repeat for each major workflow: research, design, validate, and ship and measure. Skipping validation is the expensive shortcut, because usability and accessibility problems found after release cost more to fix.

• 1. Research: Observe, interview and map the workflow, then pick the riskiest task to design first, such as medication ordering, result review or intake.
• 2. Design: Write the task flow with the information needed at each step, place abnormal values and allergies first, use safe defaults and confirmations for risky actions, and build from an accessible component library.
• 3. Validate: Test clickable prototypes with real users on realistic tasks before engineering starts, run screen reader and keyboard sessions, and review use-error scenarios such as wrong patient and wrong dose.
• 4. Ship and measure: Track time on task, errors and abandoned flows by release, tag support tickets by screen and give clinician feedback a named owner.

Writing a task flow testers can use

A usable task flow names the user role, the starting point, each step, the data shown at that step and the decision the user makes. It also lists what can go wrong at each step and how the screen prevents or reveals it. For a result review flow, that means the patient identity check, the abnormal flag, the comparison with the last value and the action taken, with a note on where an interruption is likely. Testers then score sessions against the same steps, so findings map straight back to design changes.

Clinician screens versus patient screens

Clinician and patient interfaces need different rules because their users differ in training, frequency of use and stakes. Treat them as separate design systems that share components.

• Frequency: Clinicians use the screen many times a day, so density, shortcuts and fast scanning help. Patients use it occasionally and need guidance on each step.
• Training: Clinicians are trained on the system. Patients are not, so labels must explain themselves and errors must be easy to undo.
• Information: Clinicians need values with units, reference ranges and trends. Patients need the same values in plain language with a clear next step.
• Choices per screen: Clinician screens can carry more actions if critical data stays visible. Patient screens should offer few choices and one primary action.
• Persuasion: Patient flows should avoid dark patterns that push people into consent, sharing or payment.

Caregiver and proxy access

Patient apps often serve a parent, adult child or paid caregiver acting for someone else. Design the switch between accounts so the current person is always named on screen, and match proxy permissions to the role the provider has approved, such as messages and appointments without access to sensitive notes.

How much usability testing is enough?

No rule fixes a number for formative tests during design. Test each role on the riskiest tasks, fix what fails, and test again until those tasks pass without critical use errors.

Device software is different. FDA's human factors guidance recommends at least 15 participants for each distinct user group in the human factors validation test, run on the final interface with representative users and realistic conditions.

Accessibility needs its own sessions. Automated checks catch only part of WCAG issues, so include people who use screen readers, switch access or magnification, and test with the keyboard alone on every new flow.

Score every session, formative or summative, on the same four measures so results compare across rounds and design versions.

• Task success: Whether the participant finished the task without help.
• Use errors: Each wrong selection, missed value or unsafe action, with its potential harm.
• Close calls: Moments where the participant caught their own error, which show where the design almost failed.
• Time and effort: Time on task and the number of screens or clicks, compared across design versions.

What each stage should deliver

This checklist turns the process into deliverables a product owner can review.

• Research: Workflow maps, a role and permission inventory, interview notes stripped of identifiers and a ranked list of risky tasks.
• Design: Task flows, an information hierarchy for each clinical screen, plain-language patient copy, translations where needed and an accessible component library.
• Validation: Prototype test reports per role, screen reader and keyboard findings, and a use-error review for safety-critical tasks.
• Regulatory: A Section 504 accessibility plan with the right compliance date, and for device software a human factors file with validation results.
• Measurement: Task time and error metrics, accessibility checks in CI with manual review of changed screens, and a feedback loop with an owner.

How Agnotic can help

Research and design pay off only when engineering builds what was tested. Agnotic Technologies plans the two together through a healthcare fractional CTO engagement: field research with clinicians and patients, prototype testing on the riskiest tasks, an accessible component library and the build that ships it.

For device software, Agnotic can set up the use-error review and human factors records the manufacturer's quality system needs.

Sources

• eCFR: 45 CFR 84.84, web and mobile accessibility (Section 504)
• Federal Register: Section 504 compliance date extension (May 2026)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• FDA: Applying Human Factors and Usability Engineering to Medical Devices
• 45 CFR 164.312: HIPAA technical safeguards
• HHS: Section 1557 of the Affordable Care Act
• ASTP/ONC: HTI-5 final rule