Medical Device UX Design: Standards, Process and Interface Principles

Medical device UX design is the work of making a device's interface safe and effective for the people who actually use it, in the conditions they actually use it in. Unlike most product design, it's part of a regulated engineering process. In medical devices, usability is treated as a safety property: a confusing screen is a hazard, and regulators expect you to show that you found and reduced those hazards before launch.

This guide covers what that means in practice: which standards apply, how the design process works, which interface principles matter most, and what changes when the "device" is software running on a phone.

What medical device UX design covers

The term covers more than the screen on a hospital machine. In practice, medical device UX includes four kinds of interfaces:

• Graphical interfaces on devices themselves, such as infusion pumps, ventilators, patient monitors and surgical consoles.
• Software as a Medical Device (SaMD): software that performs a medical function on its own, such as an app that analyzes images or calculates a dose.
• Companion and connected-device apps that control a device or display its data, such as an app paired with a continuous glucose monitor or an insulin pen.
• Home-use devices operated by patients and caregivers, where users have no training and may have limited vision, dexterity or health literacy.

Each one has a physical side too: labels, packaging and instructions for use are part of the user interface in regulatory terms, and they're evaluated alongside the screens.

How it differs from healthcare UX

Healthcare UX in general covers patient portals, booking apps, EHR screens and wellness products. Most of those aren't regulated as medical devices, so teams can ship, measure and iterate freely. Medical device UX sits under design controls. Every design decision that affects safety has to be traceable to a requirement and a risk analysis, changes after validation can trigger new testing, and the final design has to be backed by evidence from users.

That doesn't mean slow or old-fashioned design. It means the research and testing you'd want anyway become required, documented and repeatable.

Why usability is a safety requirement

The clearest evidence comes from infusion pumps. In its Infusion Pump Improvement Initiative white paper, the FDA reported that it received about 56,000 adverse event reports associated with infusion pumps between 2005 and 2009, and that manufacturers ran 87 recalls in that period. The agency concluded that many of the problems were related to deficiencies in device design and engineering, including user interface issues such as ambiguous on-screen instructions that could lead to dosing errors.

Alarm design is the other well-known case. When devices alarm constantly and most alarms aren't actionable, clinicians start to tune them out, a pattern known as alarm fatigue. The Joint Commission issued a Sentinel Event Alert on alarm safety in 2013, and alarm management has remained a hospital patient safety priority since.

The lesson regulators drew is simple: when a well-trained, careful person makes the same error repeatedly with a device, the device design is part of the cause.

Standards and regulations designers need to know

IEC 62366-1: the usability engineering process

IEC 62366-1 is the core international standard. It doesn't tell you what a good screen looks like. It defines a process: describe the intended users, uses and use environments; identify the user interface characteristics related to safety; analyze what could go wrong; evaluate the design with users along the way; and validate the final design. Its companion report, IEC/TR 62366-2, gives practical guidance on applying it. Notified bodies in the EU and the FDA both expect to see this kind of process in the technical file.

FDA human factors guidance

In the US, the FDA's guidance Applying Human Factors and Usability Engineering to Medical Devices sets out what the agency expects. Guidance documents are formally recommendations, not regulations, but in practice the FDA expects human factors evidence for devices where use errors could cause serious harm, and submissions without it tend to stall. The guidance centers on critical tasks: user tasks that, if performed incorrectly or not at all, could cause serious harm.

The quality system side changed in 2026 too. The FDA's Quality Management System Regulation, which aligns US device quality requirements with ISO 13485, took effect on February 2, 2026. Design controls and usability work now sit inside that framework.

The medical device UX design process

User and use environment research

Start by defining every distinct user group, because they behave differently: ICU nurses, home patients, caregivers, technicians who set up the device, people who clean and reprocess it. Then study where they use it. A pump in an emergency department is operated at night, under time pressure, with gloves on, while other alarms sound. A home device may be used by someone with arthritis and poor eyesight in a dim kitchen. Observation in real settings beats interviews here, because people underreport the workarounds they rely on.

Use-related risk analysis and critical tasks

Next, map every user task and ask what could go wrong at each step: misreading a value, pressing the wrong control, skipping a step, misunderstanding a message. This is often called a use-related risk analysis. Tasks where an error could lead to serious harm become critical tasks. They drive the rest of the work: what gets the most design attention, which mitigations are needed, and what must be tested in validation.

The order of mitigations matters. Removing a hazard by design is better than adding a protective measure, and both are better than a warning in the manual. "We'll mention it in the instructions" is the weakest fix, and reviewers know it.

Prototyping and formative evaluation

Formative evaluations are the iterative tests you run while the design can still change. They range from expert reviews and cognitive walkthroughs to usability tests with a handful of representative users on clickable prototypes or early hardware. Their job is to find problems, not to prove the design works, so small samples and fast cycles are fine. Run them early: a misunderstanding found in a Figma prototype costs hours, the same one found after software verification can cost months.

Summative (validation) testing

Summative or validation testing shows that the final design can be used safely and effectively by representative users performing critical tasks in realistic conditions. It uses production-equivalent devices, realistic environments and the actual labeling and training users would receive. The FDA guidance points to at least 15 participants per distinct user group. Testers record use errors, close calls and difficulties, then interview participants to find the root cause of each one.

Validation isn't a pass/fail exam on a usability score. Errors can occur, but each one on a critical task has to be understood and either fixed or shown to be acceptable in the risk analysis.

The usability engineering file

All of this is documented: user profiles, use environments, task analysis, use-related risk analysis, formative findings and design changes, the validation protocol and report. Designers don't usually write the file, but their decisions and rationale feed it, which is why design work in this field needs clear records of what changed and why.

Interface design principles for medical devices

Make critical information readable at a glance. The value a clinician needs most (current dose, flow rate, patient vital) should be the largest and most stable element on the screen. Secondary details can wait behind a tap.

Remove ambiguity from numbers and units. Many dosing errors start with formatting. Show units next to every value, use a leading zero for decimals (0.5, not .5), never add a trailing zero (5, not 5.0), and make the decimal point clearly visible. Where drug names look alike, tall-man lettering (for example, hydrOXYzine vs hydrALAzine) helps users tell them apart.

Design alarms by priority. High, medium and low priority alarms should look and sound different, follow consistent conventions, and say what to do, not just what happened. Fewer, more meaningful alarms are safer than many minor ones.

Protect critical actions. Starting an infusion, changing a therapy setting or deleting data should require deliberate confirmation that shows the exact values being confirmed. Generic "Are you sure?" dialogs get dismissed by habit.

Map physical and digital controls. When a device has buttons, knobs and a screen, their relationship should be obvious. The screen should reflect what the hardware is doing, and the same action shouldn't be possible in two inconsistent ways.

Never rely on color alone. Users may be color-blind, screens may be viewed in bright light or at an angle. Pair color with shape, text and position.

Design for the least able user in the group. For home-use devices this means larger text and targets, plain language, simple step sequences and recovery from mistakes. For clinical devices it means designing for interruption, because users are interrupted constantly.

Designing SaMD and connected-device apps

More and more medical device interfaces now run on phones, tablets and web browsers. That brings consumer UX expectations into a regulated space. Patients compare a glucose-monitoring app with their banking app, not with a hospital monitor.

A few things matter specifically here. Platform conventions help, but OS updates can change behavior you validated, so teams need a plan for re-verifying critical flows. Notifications are often safety-relevant, and users can silence them at the system level, so the app has to detect and communicate that. Data from a connected device can be delayed or missing, and the interface must make stale data obvious instead of showing the last value as if it were current. And when an app includes AI-based decision support, it should show users what the recommendation is based on and how confident it is, so clinicians can judge it rather than simply accept it.

This is the area where product design teams with mobile and SaaS experience add the most. At Glow we design healthcare products and work alongside clients' regulatory and human factors specialists rather than replacing them: we bring research, interaction design and prototyping speed, and they own the risk file and validation. Our work on EthosCE, a medical education platform, is an example of designing for clinicians' time and attention.

Common mistakes in medical device UX

Treating human factors as a final test. Teams that design first and run usability work just before submission often discover problems they can no longer afford to fix. Human factors work belongs at the start.

Designing for one user group. A device designed around nurses will fail with the biomedical technicians who configure it or the patients who take it home.

Testing in a quiet room. Formative and validation tests that ignore noise, interruptions, gloves, lighting and fatigue will miss the errors that happen in real use.

Fixing problems with warnings. Adding a caution label or a pop-up is quick, but it's the weakest mitigation. Reviewers expect design changes first.

Inconsistent patterns across a product line. When the same company's devices use different symbols, colors and confirmation patterns, clinicians who use several of them make transfer errors.

How to choose a medical device UX partner

Look for experience with regulated products and familiarity with IEC 62366-1 and FDA expectations, even if a separate human factors firm will run validation. Ask how they document design decisions and rationale, because that record matters later. Check that they do real user research with clinicians or patients, not just stakeholder interviews. And ask how they work with your regulatory, quality and engineering teams; the best results come when designers join risk discussions early instead of receiving requirements at the end.

For SaMD and connected apps, also look for strong mobile and web product design skills. Many failures in this category come from ordinary UX problems, such as confusing onboarding, unclear states and poor notification design, that become safety problems in a medical context. Our UX research work often starts there.

Good medical device UX design comes down to two things: knowing your users and use environments in detail, and treating every design decision on a critical task as a safety decision.

Frequently asked questions

What FDA regulations apply to medical device interface design?

Medical device design falls under FDA's quality system requirements, now the Quality Management System Regulation aligned with ISO 13485, which includes design controls. For usability, the FDA's guidance on applying human factors and usability engineering describes what the agency expects, including identifying critical tasks and running validation testing with representative users.

What is summative usability testing for medical devices?

Summative, or validation, testing shows that representative users can perform critical tasks safely and effectively with the final device, labeling and training in realistic conditions. The FDA guidance points to at least 15 participants per distinct user group, and every use error on a critical task must be analyzed for its root cause.

What is IEC 62366?

IEC 62366-1 is the international standard for usability engineering of medical devices. It defines a process for identifying users and use environments, analyzing use-related risks, evaluating the design with users, and validating the final user interface, all documented in a usability engineering file.

How is medical device UX different from healthcare UX?

Healthcare UX covers products like patient portals and booking apps, which are usually not regulated as medical devices. Medical device UX applies to products that are, so the design process must follow design controls, link decisions to risk analysis, and be backed by documented usability testing.

What's the difference between UI and HMI?

HMI, or human-machine interface, is the broader term for everything a person uses to operate a machine, including physical controls, displays, sounds and labels. UI is often used for the software screens specifically. In medical devices, regulators treat the whole HMI, including labeling and instructions, as the user interface.

----- END DOC CONTENT -----