Healthcare UX Design: Compliance, Clinical Workflows and How to Scope the Work

By Nick Babich

Key Takeaways

• Aesthetics are not compliance: A polished consumer portfolio tells you nothing about whether a team can produce the usability engineering documentation a regulated product needs.
• Design for competing users: Patients, clinicians and administrators need different views of the same data, so role-based design is the default, not an extra.
• Treat alerts as a safety feature: Every unnecessary interruption trains clinicians to click past warnings, including the critical ones.
• Design for interoperability: Your interface can only show what HL7 FHIR and the specific EHR deployment can actually deliver, and how often.
• Budget for slow, expensive research: Clinician recruiting, PHI handling and on-site observation make healthcare research cost more and take longer than consumer research.

Healthcare UX design is the work of making clinical and patient software safe, compliant and fast for people who use it under pressure. After reviewing 96 digital health design portfolios over the past three years, I found that fewer than 18% documented how they run HIPAA-compliant user research or IEC 62366 human factors validation.

Most design teams approach healthcare with the same playbook they use for consumer SaaS. They focus on minimizing friction and creating clean, minimalist interfaces. But in healthcare, removing the wrong friction causes patient harm. If you are comparing outside partners, start with the healthcare UX design agencies we have evaluated; this guide covers what the work itself involves, so you can brief it, scope it and judge the results.

Designing for digital health requires a different mental model. You are designing for stressed clinicians, anxious patients and rigid regulatory frameworks at the same time. Based on my experience evaluating digital product agencies, a successful project balances clinical workflows, patient safety, data privacy and interoperability constraints long before anyone draws a wireframe.

The Conflicting Needs of Healthcare Users

Consumer applications usually serve one primary user. Healthcare applications almost always serve competing user groups, and a successful product mediates those conflicts inside the interface.

• Patients: Plain language, price transparency and emotional reassurance.
• Clinicians: High data density, precise clinical terminology and speed.
• Administrators: Billing codes, compliance checklists and throughput metrics.

If you design a patient portal that gives users total, unfiltered access to raw lab values with no context, you create anxiety for the patient and a flood of support messages for the clinician. If you design an Electronic Health Record (EHR) interface purely for physician speed, administrators lose the structured documentation they need to process claims.

You cannot satisfy everyone on a single screen. In my experience reviewing complex system architectures, the strongest teams design role-based views that translate the same underlying data into different contextual experiences.

Clinical Workflows and the Risk of Alert Fatigue

Doctors and nurses do not use software in quiet, distraction-free offices. They use it while walking down hospital corridors, wearing nitrile gloves, holding tablets and talking with patients. They are interrupted constantly.

When you design for clinicians, cognitive load is directly tied to patient safety.

A common mistake I see in early-stage health tech is a "helpful" pop-up alert for every potential drug interaction or missing data field. This creates alert fatigue. The Agency for Healthcare Research and Quality's patient safety primer on alert fatigue in clinical decision support notes that clinicians generally override the vast majority of computerized order entry warnings, even critical alerts that warn of potentially severe harm.

When every notification is framed as an emergency, nothing is an emergency. To design safe clinical workflows:

• Reserve modals for critical risk: Interrupt only for errors that could seriously harm the patient.
• Use inline validation for the rest: Flag non-critical missing information where it sits, without blocking the task.
• Save state persistently: If an application logs a nurse out after 10 minutes of inactivity and deletes their drafted clinical notes, the UX has failed the reality of the workflow.

The Compliance Layer: HIPAA, FDA and IEC 62366

You cannot design healthcare software without understanding its regulatory boundaries. Your design decisions directly affect legal compliance.

HIPAA and Data Privacy

In the United States, HIPAA governs how Protected Health Information (PHI) is handled. The HHS guidance on the HIPAA minimum necessary standard requires covered entities to limit the use and disclosure of PHI to what is needed for the purpose, and to define which roles need which categories of information. From a UX perspective, that means interfaces should expose only the PHI a user needs for the task in front of them.

It also means designing clear session timeouts and audit logs that do not get in the way of emergency care. If a patient is coding, a doctor cannot spend two minutes on two-factor authentication. You need a secure "break the glass" emergency access flow that is logged and reviewed afterward.

FDA Oversight and Software as a Medical Device (SaMD)

If your software analyzes patient data to diagnose a condition or recommend treatment, it may qualify as Software as a Medical Device and fall under FDA oversight.

For regulated devices, the FDA expects human factors work. Its overview of human factors and medical devices says the main goal of the process is to minimize use-related risks and confirm that users can operate the device safely and effectively. I highly recommend reading it before you brief your design team.

IEC 62366

IEC 62366-1 is the international standard for applying usability engineering to medical devices. It specifies a process to analyze, specify, develop and evaluate usability as it relates to safety, including the risks of use errors. If you hire an outside team to design a regulated product, they must know how to produce the documentation that goes into a Usability Engineering File.

Designing for Interoperability and HL7 FHIR

Designers love to invent beautiful, centralized dashboards that aggregate a patient's entire medical history. The problem usually lies in the data architecture.

Healthcare data is fragmented across dozens of legacy systems. The modern standard for exchanging it is HL7 FHIR (Fast Healthcare Interoperability Resources), which defines data as modular "resources" such as patients, medications and observations.

Before you design a feature, ask your engineering team what data FHIR can actually pull from the specific EHR you are integrating with. If your interface relies on real-time heart rate data, but the hospital's EHR deployment only batch-updates that data every 24 hours, the design will not work in practice.

UX designers in healthcare must be technical enough to understand API constraints.

Executing Healthcare User Research

Research in healthcare is expensive, legally complex and hard to schedule. If you have not run a structured study before, read our guide to scoping a research phase before you commit budget, then add the healthcare-specific constraints below.

Recruiting and Costs

You cannot recruit oncologists on standard consumer testing platforms. Recruiting doctors requires specialized panels, and in the projects I have scoped, participant incentives alone run $300 to $500 per hour. That changes your research budget dramatically.

Handling PHI During Testing

Standard usability testing tools record screens and voices. If a participant reveals their own medical history during a session, the testing platform may now be storing PHI. Make sure your design partner has a Business Associate Agreement (BAA) in place with every research software vendor that could capture PHI.

Shadowing on the Floor

The most valuable healthcare research happens in person. Watching a nurse struggle with a drop-down menu while wearing gloves gives you insights you will never get on a remote video call. Contextual inquiry on hospital floors is essential.

Accessibility, Plain Language and Patient Trust

Healthcare applications must work for people with temporary, situational or permanent disabilities.

WCAG Compliance

In the United States, the HHS Section 504 rule on web and mobile accessibility requires health programs that receive federal funding to make their web content and mobile apps conform to WCAG 2.1 Level AA. I recommend designing to WCAG 2.2 AA so you meet that bar with room to spare. That covers color contrast, keyboard navigation and touch target sizes. Many patients are older adults or people managing a condition that affects vision or dexterity, and small fonts with low-contrast grays lose them fast.

Health Literacy

I write patient-facing copy for roughly a sixth-grade reading level. Patients do not understand "myocardial infarction." Use "heart attack." The NIH Clear & Simple guide to health communication explains how to check reading level with formulas such as SMOG and test materials with your audience.

How to Scope a Healthcare UX Project

Scoping digital health work means padding timelines for legal reviews, compliance checks and difficult recruiting. In the projects I have evaluated, a typical end-to-end redesign of a patient portal or clinician tool takes 3 to 6 months, or roughly 14 to 26 weeks across five phases.

Here is a realistic breakdown of project phases and what drives the cost of each:

Two scoping rules save the most money. First, define the regulatory boundary in discovery: whether the product is a medical device changes the documentation for every later phase. Second, lock FHIR data mapping before high-fidelity design, so you never polish screens the data cannot support. If your product also handles payments, identity checks or other regulated flows, our guide on designing compliance into regulated products covers the patterns that carry over.

Vetting an Outside Design Partner

When you evaluate an outside team for a healthcare project, set their consumer work aside. Before you sign a contract, ask for these specific pieces of evidence:

1. Usability engineering documentation: An anonymized Usability Engineering File or human factors report from a previous project.
2. Research protocols: How they handle PHI during remote usability testing and which platforms they have BAAs with.
3. Accessibility process: How they validate against WCAG beyond automated plugins, including testing with assistive technology users.
4. EHR experience: A time they had to change a design because of a data interoperability constraint.

If they stumble on these questions, they will learn on your dime.

Frequently Asked Questions

What is healthcare UX design?

It is UX work for clinical and patient software, such as EHR interfaces, patient portals, telehealth apps and clinical decision tools. It adds patient safety, privacy rules, accessibility and interoperability to the usual goals of usability and efficiency.

Do I need IRB approval to run usability testing on a healthcare app?

Usability testing with mock data that evaluates interface friction usually does not involve an Institutional Review Board. If you test with real patient data, or the study aims to show the software improves health outcomes, it can become human subjects research. Confirm with your compliance team or IRB before you recruit.

What is the difference between formative and summative testing?

Formative testing runs iteratively during design to find and fix usability problems. Summative testing happens at the end to show that the final interface can be used safely and effectively, and for regulated devices it becomes part of the evidence submitted to regulators.

How do you measure UX success in healthcare?

Avoid consumer metrics like time on site; in healthcare, a long session often means a confused clinician. Measure task metrics such as error rates and time to complete chart notes, plus business metrics such as support call deflection and lower patient no-show rates.

Conclusion

Building digital health products is not an exercise in aesthetics. It is an exercise in risk reduction and workflow design. Respect the limits of FHIR interoperability, budget realistically for clinical research, define the regulatory boundary early and hold your design partners to documented evidence. Do that, and you can build tools that improve both clinical efficiency and patient outcomes.