FDA Human Factors and Usability Engineering

Human factors is a safety-engineering discipline

FDA's August 2026 final guidance addresses the application of human factors and usability engineering to medical devices. Its purpose is to maximise the likelihood that devices will be safe and effective for the intended users, uses and use environments by reducing use errors and resulting harm.

The focus is not whether users like the product. It is whether the user interface supports correct perception, understanding and action under realistic conditions. The interface includes physical controls, displays, software, alarms, packaging, labels, instructions, training, accessories and connections.

MTL-110 — Usability and Human Factors provides the general engineering process, while MTL-314 — IEC 62366-1 Usability Engineering explains the international standard.

Start with a specific use specification

Define intended users, patient populations, use environments, operating principles and important use scenarios. Distinguish user groups when differences in capabilities, responsibilities, knowledge or workflow could affect safe operation.

• Clinical professionals, lay users, carers, installers and service personnel may need separate analysis.
• Consider sensory, cognitive, physical, language and experience characteristics.
• Include environmental factors such as lighting, noise, interruptions, mobility, protective equipment and network availability.
• Describe infrequent, emergency, cleaning, maintenance and recovery tasks—not only routine operation.
• Use complaints, recalls, incident databases and comparable-device experience to identify known problems.

The intended users and environments should remain consistent with MTL-102 — Intended Purpose, Users and Use Environments.

Analyse use-related risk through interaction

Use-related risk analysis examines how interface characteristics, user actions or omissions and environmental conditions can lead to hazardous situations. Describe the sequence from perception and cognition through action, device response and possible harm.

Do not assign blame to “user error” and stop the analysis. Investigate the interface, task, information, environment and organisational context that make the error foreseeable. Use findings to derive risk controls and evaluation needs.

Critical tasks determine validation scope

A critical task is a user task which, if performed incorrectly or not performed, would or could cause serious harm. Identify critical tasks from the use-related risk analysis and support the decision with clinical and technical reasoning.

Break tasks down sufficiently to reveal what the user must perceive, understand and do. Include tasks that detect or recover from faults, interpret results, respond to alarms, maintain the device or configure safety-significant settings. The critical-task list should trace to validation scenarios and acceptance rationale.

Prefer design controls over warnings and training

Risk controls should follow the hierarchy of designing hazards out or reducing them through the user interface before relying on protective information or training. Labelling and training may be necessary, but users can forget, misunderstand or be unable to access them when needed.

Turn important interface controls into design inputs. Define the required presentation, control behaviour, constraints, feedback and error recovery so that implementation and verification are objective. Link those inputs to the hazard-related use scenario they control.

Formative evaluation improves the design

Formative studies are iterative learning activities performed while the interface can still change. They can use sketches, mock-ups, prototypes, simulations and partial systems. Their purpose is to expose misunderstanding, unsafe strategies and design weaknesses—not to produce a regulatory pass result.

• Evaluate high-risk concepts early.
• Observe behaviour rather than relying only on opinions.
• Use representative users where user characteristics matter.
• Investigate the reason for each error, close call and difficulty.
• Record design decisions and confirm that changes address the finding.
• Repeat evaluation when risk or design uncertainty remains.

Good formative work reduces the chance that final validation discovers a fundamental problem too late to resolve economically.

Human-factors validation evaluates the final interface

Human-factors validation should demonstrate that the production-equivalent user interface can be used by intended users under expected conditions without use errors or problems that would result in unacceptable risk. It is distinct from general product validation and from formative research.

The protocol should define objectives, user groups, critical tasks, scenarios, conditions, training decay where relevant, data collection and analysis. Testing should avoid coaching and should include all safety-relevant materials that users receive. Simulations must preserve the interaction conditions that matter to risk.

Participants and conditions must be representative

Recruit participants who reflect the characteristics of each distinct intended-user population. Sample size should support discovery of use problems and a persuasive qualitative safety conclusion. FDA guidance has traditionally recommended at least 15 participants for each distinct user population, but the study still requires a device-specific rationale and may need more or different evidence.

Represent the expected range of experience and capability. Avoid substituting company personnel or convenient experts for actual users. Reproduce environmental and workflow conditions sufficiently to challenge the critical tasks, including realistic distractions, time pressure, accessories and information sources.

Analyse causes, not just completion rates

Record use errors, close calls, difficulties, unexpected behaviours and subjective feedback. Follow up after task performance to understand the participant's reasoning without contaminating later tasks.

For each significant observation, determine the likely root cause and its relationship to the interface, information, training, environment and prior knowledge. Reassess risk and decide whether redesign is needed. A high percentage of successful task completion does not neutralise one credible error that could cause serious harm.

The submission should show how risk shaped the interface

FDA may expect a human-factors engineering report that explains the device and users, use-related risk analysis, critical tasks, interface design, formative evaluation, validation protocol, participants, results, root-cause analysis and residual-risk conclusions.

Make the evidence traceable and configuration-specific. Explain deviations and unresolved use problems. The report should enable a reviewer to understand why the tested interface, labelling and training are representative of what will be marketed.

Use MTL-113 — Design Controls and Technical Documentation to connect this material to the wider design evidence.

Evaluate interface changes throughout the lifecycle

Changes to displays, controls, alarms, labels, packaging, workflows, users, environments or connected systems can create new use-related risk. Evaluate whether existing analysis and validation remain applicable and what additional formative or validation work is needed.

Feed complaints, service records, training issues, incidents and field observations into the usability-engineering process. A successful premarket study does not prove that the interface will remain adequate after product or context changes.

Common misconceptions

Practical readiness checklist

• Are intended-user populations and environments defined precisely?
• Does the interface boundary include hardware, software, packaging, labelling and training?
• Have known use problems and comparable-device experience been reviewed?
• Are hazard-related use scenarios and critical tasks traceable?
• Were design controls evaluated iteratively through formative work?
• Is the validation interface production-equivalent?
• Are participants and conditions representative?
• Does the protocol avoid coaching and test all critical tasks?
• Were errors, close calls and difficulties analysed for root cause?
• Are residual-risk and release conclusions supported?
• Are changes and post-market signals fed back into usability engineering?