Why Usability Engineering Is a Medical Device Safety Control

Key points#

• The user interface includes every point of interaction: controls, displays, connectors, alarms, packaging, labels, instructions, accessories, setup, cleaning, and maintenance tasks.
• Use-related risk analysis connects user actions and omissions to hazards, hazardous situations, and possible harm.
• Formative evaluations diagnose problems while the design can still change. Human factors validation evaluates the final interface under realistic conditions.
• A completion rate is not enough. Every critical error, close call, difficulty, and knowledge failure needs root-cause and residual-risk analysis.
• FDA's May 2026 final guidance uses a risk-based framework for how much human-factors information belongs in a marketing submission.

Follow the harm pathway through the interface#

Imagine an infusion pump whose motor, sensors, and dose calculation all meet specification. A user enters a value in the wrong unit because the display places two choices too close together. The device then delivers exactly what was entered. Technical function is correct, but the device-use system is unsafe.

That example explains why usability engineering is not a cosmetic review. Human factors examines how intended users perceive information, decide, act, and recover within expected use environments. The interface can create, reveal, block, or amplify a hazardous sequence. Safety work therefore has to include human interaction alongside hardware, software, biological, and manufacturing risks.

IEC 62366-1:2015+A1:2020 specifies a process to analyze, specify, develop, and evaluate device usability as it relates to safety. ISO 14971:2019 supplies the broader risk-management process. FDA's 2016 human factors guidance describes how these ideas apply to user-interface development, and its May 2026 final guidance sets out a risk-based framework for the information recommended in marketing submissions.

Define users, uses, environments, and the entire interface#

The phrase "intended user" should be more specific than clinician or patient. Relevant characteristics can include professional role, experience, and literacy. They can include language, sensory or motor ability, and health state. They can include stress, protective equipment, and whether a caregiver is involved. Distinct user groups may interact with different parts of the same product.

Use environment changes performance. Consider lighting, noise, interruptions, and space. Consider connectivity, infection-control practices, other alarms, and gloves. Consider mobility, emergency pressure, and access to help. A product used in an operating room, ambulance, community clinic, and home does not have one uniform setting.

The interface is also broader than a screen. It can include:

• physical controls, displays, icons, sounds, and vibration;
• connectors, tubing, cartridges, and accessories;
• packaging, sterile barriers, labels, and instructions;
• setup, pairing, calibration, charging, and software updates;
• cleaning, reprocessing, maintenance, and disposal; and
• information handed between the device and another person or system.

A use specification organizes these elements before you test anything. Without it, studies may recruit convenient participants, omit a rare setting, or validate only the most polished part of the interface.

Map tasks to hazards before choosing a test#

Use-related risk analysis breaks intended workflows into tasks. It asks how an action, omission, or delay could contribute to harm. It asks the same of a misunderstanding or a response to unexpected behavior. Inputs include the device risk analysis, complaints and recalls for related products, and prior evaluations. They include field observations, standards, and known use problems.

A useful chain is:

1. user and use environment;
2. task and interface element;
3. foreseeable use error or difficulty;
4. hazardous situation;
5. potential harm and severity;
6. existing risk control; and
7. evidence needed to evaluate that control.

FDA defines a critical task by the potential for serious harm if it is performed incorrectly or not performed. Frequency does not erase severity. A task used once during emergency setup can be critical even if routine users encounter it rarely. Conversely, an irritating but harmless extra click may deserve improvement without being a critical safety task.

The analysis should remain a living record. New prototypes, formative findings, and complaints can add hazards or change the task list. So can interface changes and post-market information. Traceability matters because the final validation should cover the critical tasks that remain in the final design.

Use formative work to change the design#

Formative evaluation asks why users struggle and what should change. Methods can include expert review, cognitive walkthroughs, and interviews. They can include contextual observation, simulated tasks, and iterative usability sessions. Early work may use sketches or simple prototypes; later work should resemble the real workflow more closely.

The objective is diagnosis, not a ceremonial pass rate. Observers should record errors, close calls, and hesitation. They should record workarounds, difficulty, and user explanations. The team then looks for root causes such as ambiguous labels, weak feedback, poor mapping between controls and effects, hidden system state, inconsistent sequences, memory burden, or an alarm that does not communicate priority.

Findings should lead to documented design action, further study, or a reasoned risk decision. Repeating a session with the same confusing interface does not reduce risk. FDA notes that design problems found late in validation can turn that validation into formative work, which usually means the design, risk file, and evaluation plan need another cycle.

Prefer controls that do not depend on perfect memory#

When the interface contributes to a hazardous sequence, a design control is generally more dependable than asking every user to remember a warning at the right moment. Examples include incompatible connectors, constrained choices, and clear units. They include differentiated controls, safe defaults, and confirmation for consequential actions. They include visible system state and alarms that support a timely response.

Protective measures and information for safety can supplement design. Training and labeling are important, especially for tasks that cannot be simplified further. Their limits should be explicit. A warning may be forgotten, unread, unavailable, or misunderstood under stress. Training can decay or fail to reach a new caregiver. If a feasible interface change can remove the ambiguity, relying only on instruction leaves the root cause in place.

Risk control also includes recovery. A device should make an error detectable when possible, communicate what happened, and support a safe correction. An alarm that announces a problem without telling the user which channel or patient is affected may detect failure without enabling recovery.

Validate realistic use of the final interface#

Human factors validation asks whether the final or sufficiently representative interface supports safe and effective use by intended users under expected conditions. FDA's 2016 guidance calls for representative participants, all critical tasks, the final interface, and realistic conditions. Scenarios should include relevant distractions, time pressure, and low light. They should include multiple alarms, physical constraints, or other factors identified in the use-related risk analysis.

Participants should receive only the training that intended users would actually receive and should use the available labeling as they would in practice. Coaching during a critical task can hide a design problem. Distinct user groups need suitable representation, because a nurse, patient, and caregiver may face different hazards. So may a reprocessing technician and a service engineer.

Validation data should include more than successful completion:

• use errors and omitted actions;
• close calls and recovery;
• difficulty, hesitation, and workarounds;
• knowledge-task responses for safety-critical information;
• participant comments collected without suggestive questioning; and
• the relationship between each event and potential harm.

Each safety-relevant event needs analysis. Was the scenario realistic? Did the participant misunderstand the display, forget training, follow an ambiguous instruction, or receive weak feedback? Could the event recur in actual use? Can a design modification reduce it? A high aggregate success rate cannot cancel one repeatable error that could cause serious harm.

If a change affects a critical task or its risk controls, additional validation may be needed. Your evidence should represent the marketed configuration, not a prototype that was later altered in a meaningful way.

Match FDA submission content to risk and change#

FDA finalized Content of Human Factors Information in Medical Device Marketing Submissions on May 29, 2026. The guidance covers 510(k) submissions, De Novo requests, premarket approval applications, and humanitarian device exemption applications. It is a companion to the 2016 process guidance, not a replacement for it.

The 2026 framework assigns one of three human-factors submission categories through a decision process:

• Category 1 calls for a conclusion and high-level summary supporting why a modification does not affect the device's human-factors considerations.
• Category 2 calls for a documented rationale, such as why there are no critical tasks or why human factors validation does not need to be submitted.
• Category 3 calls for a comprehensive human-factors report that includes validation of the final design.

The category is about recommended submission content. It does not mean lower-risk files can skip appropriate design and risk-management work. The guidance also includes a transition: FDA stated that it generally did not expect pending submissions or submissions received before August 1, 2026 to contain all newly recommended information, while remaining willing to review it if supplied. If you are working near that date, confirm the current FDA instructions for your submission.

A coherent report lets a reviewer follow one thread from intended users, uses, and environments through known problems, risk analysis, critical tasks, formative findings, design modifications, validation, root-cause analysis, and residual-risk conclusions. Cross-references can prevent duplication, but the reasoning should remain recoverable.

Continue the process after market entry#

Usability risk can change after launch. New software, accessories, or packaging may create new interactions. So may labels, user groups, care settings, or training. Complaints, service records, and adverse-event investigations can reveal conditions absent from premarket testing. So can workarounds and near misses.

Post-production information should feed back into the risk file. You can then decide whether the issue calls for investigation, interface change, or labeling or training change. The alternatives are field action, additional evaluation, or no action with documented rationale. Version control is essential because a finding may apply only to a particular configuration.

The central idea is simple: users are not outside the engineering system. Their capabilities, tasks, and environments are design inputs, and the interface is a risk-control surface. Usability engineering makes that safety argument visible, testable, and updateable across the device lifecycle.