IEC 62366 Usability Engineering for Medical Devices: Complete Guide

Why Usability Engineering Matters for Medical Devices

Use errors are among the leading causes of medical device adverse events. The FDA has reported that use errors contribute to a significant proportion of device recalls and adverse event reports submitted through MAUDE. The ECRI Institute has repeatedly listed usability-related hazards among its top health technology risks. These are not abstract statistics. They represent patients who received the wrong drug dose because a nurse misread a pump interface, surgeons who activated the wrong mode on an electrosurgical unit, and home users who failed to detect a critical alarm because the device's auditory signal was indistinguishable from a kitchen appliance.

The critical insight that underpins usability engineering for medical devices is this: when a user makes an error while operating a device, the root cause is usually the device's design, not the user's competence. A clinician who has been on shift for twelve hours, working in a noisy ICU with multiple alarms competing for attention, is not a defective component. They are a normal user operating under normal conditions. The device must be designed to support safe use under those conditions.

Usability engineering is the discipline that makes this possible. It is the systematic application of knowledge about human behavior, perception, cognition, and physical capabilities to the design of medical device user interfaces. When done well, it produces devices that are intuitive to learn, efficient to use, and resistant to use errors that could harm patients.

IEC 62366-1:2015 is the international standard that defines the usability engineering process for medical devices. Together with FDA human factors guidance and EU MDR requirements, it forms the regulatory foundation for ensuring that devices are safe and effective in the hands of real users.

This guide covers everything you need to know to implement usability engineering effectively — from the standard's requirements through practical study design to regulatory submission strategy.

IEC 62366-1:2015 Overview

Scope and Purpose

IEC 62366-1:2015 (formally titled "Medical devices — Part 1: Application of usability engineering to medical devices") specifies a process for manufacturers to analyze, specify, develop, and evaluate the usability of a medical device as it relates to safety. The standard was developed by IEC Technical Committee 62 (Electrical equipment in medical practice), Subcommittee 62A, jointly with ISO.

The standard applies to all medical devices, not just electronic or software devices. If a device has a user interface — and virtually every device does, even if the "interface" is the physical form factor of a syringe or the labeling on a package — IEC 62366-1 applies.

The scope explicitly includes:

• All types of medical devices (active, non-active, implantable, IVD)
• All user interfaces (hardware controls, software GUIs, displays, alarms, labeling, packaging, instructions for use)
• All users (healthcare professionals, patients, lay caregivers, technicians who install or service the device)
• All environments of use (hospital, clinic, home, ambulance, field)

IEC 62366-1 focuses exclusively on usability as it relates to safety. It does not address general user satisfaction, aesthetics, or commercial usability goals — although those are legitimate design objectives, they fall outside the standard's scope. If a use error cannot result in harm, the standard does not require you to address it. In practice, most manufacturers extend their usability engineering programs beyond the minimum safety scope because good usability is also good business.

Evolution of the Standard

The current standard has its roots in IEC 62366:2007, which was the first international standard dedicated to usability engineering for medical devices. That original edition was a single-part standard that combined both normative requirements and informative guidance in a single document. While it established the foundational framework — use specification, use-related risk analysis, formative and summative evaluation — industry feedback identified several areas for improvement: the standard's scope was sometimes interpreted as limited to electronic devices, the integration with ISO 14971 was not sufficiently explicit, and the mixture of mandatory requirements and advisory guidance in a single document created confusion during audits.

In 2015, IEC Technical Committee 62 published a major restructuring. The standard was split into two parts: IEC 62366-1:2015, containing only the normative requirements, and IEC 62366-2:2016, containing the informative guidance, rationale, and worked examples. The 2015 revision clarified that the standard applies to all medical devices with a user interface — not just electronic or software devices — and strengthened the connection to ISO 14971 by explicitly requiring integration of use-related risk analysis with the overall risk management process. The concept of "primary operating functions" was refined, and the requirements for summative evaluation were made more explicit. Amendment 1 to IEC 62366-1 was published in 2020 (IEC 62366-1:2015/AMD1:2020), introducing targeted clarifications including updates to definitions, alignment with the 2019 edition of ISO 14971, and editorial corrections. Manufacturers implementing the standard today should work from the consolidated version that incorporates Amendment 1.

Regulatory Recognition

IEC 62366-1 is recognized across all major regulatory frameworks:

Regulatory Framework	Status of IEC 62366-1
EU MDR (2017/745)	Harmonized standard. Conformity creates a presumption of conformity with relevant GSPRs (Annex I)
EU IVDR (2017/746)	Harmonized standard. Same presumption of conformity as under MDR
FDA (United States)	Recognized consensus standard. Referenced in FDA human factors guidance documents
Health Canada	Recognized standard under MDSAP
PMDA (Japan)	Referenced in Japanese medical device regulations
TGA (Australia)	Recognized via MDSAP participation
MDSAP	Audited as part of design control requirements across all participating authorities

Key Definitions

IEC 62366-1 introduces terminology with precise definitions that differ from everyday usage. Misunderstanding these terms causes audit findings, misdirected design efforts, and flawed study protocols.

Term	IEC 62366-1 Definition	Why It Matters
Use error	User action or lack of user action while using the medical device that leads to a different result than intended by the manufacturer or expected by the user	This is the central concept. Use errors are not user failures — they are design failures. The device did not adequately support the user in achieving the intended result.
Abnormal use	Conscious, intentional act or deliberate omission of an act that is counter to or violates normal use as intended by the manufacturer	Abnormal use is explicitly outside the scope of IEC 62366-1. You are not required to design against a user who intentionally misuses the device. This is handled under ISO 14971 as reasonably foreseeable misuse.
User interface	All means by which the user and the medical device interact, including all points of contact between the user and the device	Much broader than a screen. Includes hardware controls, physical form factor, packaging, labeling, instructions for use, alarms, indicators, connectors, accessories.
Use specification	Documentation of the intended use, the intended users, the intended use environments, and the user interface of the medical device	The foundational document of the usability engineering process. Everything else builds on this.
Primary operating function	Function of a medical device intended to be applied to or used on the patient or function that the user interacts with that has a direct impact on patient safety	Determines which device functions require the most rigorous usability engineering attention.
Accompanying document	Document that accompanies a medical device and contains information for the user, including instructions for use	Part of the user interface as defined by the standard. Labeling and IFU are subject to usability evaluation.
Use-related hazardous situation	Hazardous situation resulting from a use error or the characteristics of the user interface that impair the user's ability to recognize, understand, or act on information	The link between usability and risk management. This is where IEC 62366-1 connects to ISO 14971.
Formative evaluation	Evaluation conducted during the user interface design process to improve the design	Iterative testing to identify and fix problems. No pass/fail criteria.
Summative evaluation	Evaluation of the user interface to ensure that users can use the medical device safely and as intended	Validation testing. Has predetermined acceptance criteria and a structured study protocol.

The distinction between use error and abnormal use is one of the most important boundaries in usability engineering. If a nurse sets a pump to deliver 10 mL/hr instead of 1.0 mL/hr because the decimal point on the display is too small to see, that is a use error — the manufacturer's problem. If a nurse deliberately bypasses a safety interlock to administer an unauthorized drug, that is abnormal use — outside the scope of IEC 62366-1 (though it must still be considered in the ISO 14971 risk analysis as reasonably foreseeable misuse).

Abnormal Use: Subcategories and the Boundary With Reasonably Foreseeable Misuse

Abnormal use is not a monolithic concept. IEC 62366-1 and its companion guidance recognize that intentional deviations from intended use fall along a spectrum of intent and severity. Understanding the subcategories is important for correctly classifying observed behaviors during usability studies and for determining which behaviors must be addressed in the risk management process.

Subcategory	Description	Example	Addressed By
Violation	Deliberate deviation from established procedures, often motivated by a perceived benefit such as saving time or simplifying a workflow	A nurse routinely skips a recommended priming step on an infusion pump because it adds 30 seconds to setup and has never caused a problem	ISO 14971 as reasonably foreseeable misuse. IEC 62366-1 does not require designing against violations, but manufacturers should consider whether the design inadvertently encourages them.
Disregard	Conscious decision to ignore known safety instructions or warnings, typically due to low perceived risk	A home user ignores a "do not immerse in water" warning because the device appears sealed	ISO 14971 as reasonably foreseeable misuse. May also indicate a labeling usability problem if the user did not notice or understand the warning.
Reckless behavior	Willful disregard for safety with awareness that the action could cause harm	A technician removes a safety guard during maintenance and operates the device without replacing it	ISO 14971 if reasonably foreseeable. Typically addressed through engineering interlocks rather than labeling.
Sabotage	Intentional action with the specific purpose of causing harm	A person deliberately tampers with a device to injure a patient	Outside the scope of both IEC 62366-1 and ISO 14971's reasonably foreseeable misuse. May be addressed through physical security measures or cybersecurity controls.

The boundary between use error and abnormal use is not always obvious. The critical question is intent. If the user intended to perform the correct action but the device design led them to a different result, it is a use error regardless of how careless the user appeared. If the user consciously chose to deviate from the intended use, it is abnormal use. However, when a design consistently induces violations — for example, when a safety step is so time-consuming or poorly integrated into the workflow that the majority of users skip it — the manufacturer should consider whether the design itself is contributing to the behavior, which shifts the analysis back toward use error territory.

The relationship to ISO 14971 is critical. While IEC 62366-1 explicitly excludes abnormal use from its scope, ISO 14971:2019 requires manufacturers to consider "reasonably foreseeable misuse" during hazard identification. Reasonably foreseeable misuse includes violations and disregard — behaviors that are predictable based on knowledge of human behavior and published adverse event data. Sabotage is generally not considered reasonably foreseeable. Reckless behavior falls in a gray area that must be assessed case by case. Manufacturers must document how they classified borderline behaviors and the rationale for including or excluding them from the risk analysis.

IEC 62366-1 vs IEC 62366-2: Mandatory Requirements vs Advisory Guidance

IEC 62366-1 is the normative standard — it defines what you must do. IEC 62366-2:2016 (titled "Guidance on the application of usability engineering to medical devices") is an informative technical report — it provides advice on how to do it.

Aspect	IEC 62366-1:2015	IEC 62366-2:2016
Document type	International Standard (normative)	Technical Report (informative)
Status	Mandatory requirements	Advisory guidance
Auditable	Yes — auditors and Notified Bodies assess conformity against IEC 62366-1	No — not auditable. Provides recommendations and examples.
Content	Defines the process requirements, required inputs and outputs, and documentation	Explains rationale, provides examples, describes methods, offers practical advice
Scope	What the usability engineering process must include	How to implement the process effectively
Length	Approximately 35 pages	Approximately 80 pages
Relationship	Defines requirements	Provides implementation guidance for IEC 62366-1 requirements

In practice, you should read IEC 62366-2 before attempting to implement IEC 62366-1. The normative standard is deliberately concise — it tells you the "what" but leaves enormous flexibility in the "how." IEC 62366-2 fills this gap with worked examples, rationale for each requirement, descriptions of evaluation methods, and discussion of edge cases.

However, Notified Bodies and FDA reviewers will assess your work against IEC 62366-1's requirements. If your process meets IEC 62366-1 but uses different methods than those suggested in IEC 62366-2, you are compliant. If your process follows IEC 62366-2's suggestions but fails to meet IEC 62366-1's requirements, you are not compliant.

The Usability Engineering Process: Step by Step

IEC 62366-1 defines a structured process that runs in parallel with — and is integrated into — the overall medical device design and development process. The process is iterative, not linear. You will cycle back through earlier stages as you learn from evaluations and as the design evolves.

Step 1: Prepare the Use Specification

The use specification is the foundation of the entire usability engineering process. It documents four essential elements:

1. Intended use and intended medical indication

What the device is intended to do, and for what clinical purpose. This should align with your device's intended use statement as defined in your regulatory strategy and risk management plan.

2. Intended user profiles

Who will use the device. For each user group, characterize:

• Professional qualifications (licensed physician, registered nurse, patient with no medical training)
• Experience level (expert user, trained user, novice user, lay user)
• Physical capabilities and limitations (visual acuity, dexterity, strength, cognitive ability)
• Language and literacy level
• Age range
• Training that can be assumed or that will be provided

3. Intended use environments

Where and under what conditions the device will be used:

• Physical environment (ICU, operating room, home bedroom, ambulance, outdoor)
• Lighting conditions (bright OR lights, dim nighttime ward, variable home lighting)
• Noise levels (quiet clinic, noisy emergency department, MRI suite)
• Distractions and interruptions (multiple alarms, phone calls, other patients)
• Protective equipment (gloves, gowns, masks that may impair dexterity or visibility)
• Temperature, humidity, cleanliness requirements

4. User interface description

The elements of the device that the user interacts with:

• Displays and indicators
• Controls (buttons, knobs, touchscreens, foot pedals)
• Connectors, ports, cables
• Physical form factor (size, shape, weight, grip)
• Alarms and alerts (auditory, visual, haptic)
• Labeling, packaging, and instructions for use
• Software user interface (screens, menus, navigation, data entry)

The use specification is a living document. As you learn more about your users and use environments through research and testing, update it. A use specification written at the start of design that is never revised is a red flag to auditors — it suggests the manufacturer did not actually engage with real users.

Step 2: Conduct User Research and Contextual Inquiry

Before you can design a user interface, you need to understand your users and the context in which they work. IEC 62366-1 does not prescribe specific user research methods, but it requires that the use specification be based on actual knowledge of users and use environments — not assumptions.

Effective user research methods include:

Method	Description	When to Use
Contextual inquiry	Observe users in their actual work environment. Watch how they perform tasks, interact with existing devices, manage interruptions, and recover from errors.	Early in development. Essential for understanding the real use environment.
Interviews	Structured or semi-structured conversations with representative users about their tasks, challenges, workarounds, and mental models.	Throughout development. Useful for exploring user expectations and identifying latent needs.
Task analysis	Systematic decomposition of user tasks into steps, decision points, and information requirements.	During use specification development. Feeds directly into use-related risk analysis.
Workflow analysis	Mapping the broader clinical workflow in which the device will be used, including interactions with other devices, systems, and people.	Early in development. Identifies integration points and handoff risks.
Literature review	Analyzing published studies, adverse event reports (MAUDE, vigilance databases), recall data, and complaint records for similar devices.	Very early. Identifies known use problems with predicate or similar devices.
Expert consultation	Engaging clinical advisors, human factors consultants, or key opinion leaders to review design concepts and identify potential use issues.	Throughout development. Supplements direct user research.

Contextual inquiry deserves special emphasis. There is no substitute for watching real users in real environments. The gap between how designers imagine a device will be used and how it is actually used in practice is consistently and dramatically large. A device that works perfectly in a quiet, well-lit usability lab may fail catastrophically in a chaotic emergency department at 3 AM.

Step 3: Use-Related Risk Analysis

Use-related risk analysis is the bridge between usability engineering and risk management. It identifies the hazardous situations that could result from use errors or from characteristics of the user interface that impair the user's ability to use the device safely.

This analysis must be integrated with the overall risk management process defined by ISO 14971. In practice, this means your risk management file and your usability engineering file share a common analysis — the use-related hazards, hazardous situations, risks, and risk controls should appear in both documents, cross-referenced and consistent.

The use-related risk analysis should address:

1. Identify use-related hazards — What could go wrong during user interaction with the device? Consider each user task, each UI element, and each use scenario.
2. Identify potential use errors — For each task, what errors could the user make? Consider errors of commission (doing the wrong thing), omission (not doing something), and errors in sequence, timing, or magnitude.
3. Identify use-related hazardous situations — What happens when those errors occur? Does the use error lead directly to a hazardous situation, or does it interact with other factors?
4. Estimate the severity of harm — If the hazardous situation results in harm, how severe is it?
5. Estimate the probability of harm — How likely is it that the use error will occur, and that it will result in harm?
6. Evaluate risk acceptability — Is the estimated risk acceptable per the criteria defined in your risk management plan?
7. Define risk control measures — If the risk is not acceptable, what design changes, protective measures, or information for safety can reduce it?

The hierarchy of risk controls for use-related risks follows the same precedence as ISO 14971:

1. Inherent safety by design — Eliminate the possibility of the use error through design (e.g., connectors that physically cannot be connected incorrectly, removing unnecessary complexity from the interface)
2. Protective measures — Add engineering controls that detect and prevent use errors (e.g., confirmations for critical actions, soft limits, interlocks)
3. Information for safety — Provide warnings, alerts, labels, or training that inform the user about the risk (e.g., warning labels, alarm messages, training programs)

Relying primarily on information for safety (warnings, training, labeling) to control use-related risks is a known weakness in usability engineering programs. Both FDA and EU Notified Bodies scrutinize this. If you identify a serious use-related risk and your only mitigation is a warning label or a training requirement, expect pushback. Design-based risk controls are always preferred.

Step 4: User Interface Specification

The user interface specification translates the use specification and use-related risk analysis into concrete, measurable requirements for the user interface. It defines what the user interface must do and how it must perform.

The UI specification should address:

• Functional requirements — What functions must the UI provide? What information must be displayed? What controls are needed?
• Performance requirements — Response times, display update rates, alarm latencies, accuracy of controls
• Physical requirements — Size, shape, weight, reach distances, viewing angles, font sizes, color contrast
• Cognitive requirements — Information density, complexity of navigation, number of steps to complete critical tasks
• Error prevention requirements — Specific design features that prevent or mitigate identified use errors
• Accessibility requirements — Support for users with reduced capabilities (vision, hearing, dexterity)
• Labeling and IFU requirements — Content, format, language, placement of safety-critical information

Each requirement in the UI specification should trace back to either the use specification (supporting the intended use) or the use-related risk analysis (mitigating an identified risk). This traceability is essential for both design controls compliance and usability engineering file completeness.

Step 5: User Interface Design and Implementation

The design phase translates the UI specification into an actual user interface. This is where industrial designers, software UI designers, human factors engineers, and clinical advisors collaborate to create a design that meets the specified requirements.

IEC 62366-1 does not prescribe design methods. You can use wireframes, interactive prototypes, physical mockups, 3D-printed models, or any combination appropriate for your device. The standard requires that the design be evaluated (through formative evaluations) and that the final design be validated (through summative evaluation).

Key design principles that are well-established in human factors engineering for medical devices:

• Consistency — Similar functions should look and behave similarly. Controls should follow established conventions (e.g., clockwise to increase).
• Visibility — The current state of the device should be apparent to the user. Critical information should not be hidden in menus.
• Feedback — The device should confirm user actions promptly and unambiguously.
• Constraint — The design should prevent incorrect actions where possible (e.g., color-coded connectors, forced-function designs).
• Error tolerance — The design should allow users to recognize and recover from errors before harm occurs.
• Simplicity — The interface should present only the information and controls needed for the current task. Unnecessary complexity increases use error risk.
• Mapping — The relationship between controls and their effects should be natural and intuitive.

Step 6: Formative Evaluation

Formative evaluations are conducted during the design process to identify usability problems and inform design improvements. They are iterative — you run a formative evaluation, identify problems, modify the design, and evaluate again. There is no fixed number of formative evaluations required; you continue until the design is mature enough for summative evaluation.

Purpose: Discover usability problems, not prove the design is safe. Formative evaluations are diagnostic, not validative.

Methods commonly used in formative evaluations:

Method	Description	Typical Participants	Fidelity Level
Heuristic evaluation	Human factors experts review the UI against established usability principles and guidelines	3-5 HF experts (no end users required)	Any fidelity (paper, wireframe, prototype, final)
Cognitive walkthrough	Analysts step through user tasks and evaluate whether the UI supports each step logically	Analysts with or without end users	Low to medium fidelity
Simulated use testing	Representative users perform realistic tasks with a prototype in a simulated environment	5-15 representative users per user group	Medium to high fidelity
Think-aloud protocol	Users verbalize their thoughts while using the device, revealing their mental model and points of confusion	5-10 representative users	Medium to high fidelity
Expert review	Clinical and human factors experts review the design and identify potential use problems	3-5 domain experts	Any fidelity

Sample sizes for formative evaluations: There is no regulatory minimum. The widely cited Nielsen/Landauer guideline of 5 users to identify approximately 85% of usability problems is a reasonable starting point for each user group, but the appropriate sample size depends on the complexity of the device, the diversity of users, and the maturity of the design. For devices with multiple distinct user groups (e.g., physician, nurse, patient), you need participants from each group.

Documentation: Formative evaluations should be documented, but the documentation standard is less formal than for summative evaluations. Record what you tested, who participated, what tasks were performed, what problems were identified, and what design changes were made in response. This documentation becomes part of the usability engineering file.

Do not skip formative evaluations and go straight to summative testing. This is one of the most common mistakes manufacturers make. Summative evaluation is a validation test — if significant usability problems emerge during summative testing, you may need to redesign and revalidate, costing months and significant budget. Formative evaluations are where you find and fix problems cheaply.

Step 7: Summative Evaluation (Human Factors Validation Testing)

Summative evaluation is the final, formal assessment of whether users can use the medical device safely and as intended. It is a validation activity — the usability equivalent of design validation under ISO 13485 clause 7.3.7.

Purpose: Provide objective evidence that the final user interface design supports safe and effective use, specifically for tasks associated with use-related hazards.

Study Design Essentials:

1. Define the tasks to evaluate

Focus on tasks associated with critical use scenarios — those where a use error could result in harm. Not every device function needs to be included in the summative evaluation. The tasks should be derived from your use-related risk analysis and should cover all primary operating functions and safety-critical tasks.

2. Define participant groups and sample sizes

Participants must be representative of the intended user population. For each distinct user group, the FDA human factors guidance recommends a minimum of 15 participants. This number is based on the statistical reasoning that 15 users provide approximately 90-95% confidence that a use error with a true occurrence rate of approximately 5% or greater will be observed at least once.

User Group	Recommended Minimum (FDA)	Rationale
Healthcare professional (e.g., nurse)	15	Primary clinical user
Physician	15	If a distinct user group with different tasks
Patient or lay caregiver	15	If device is used at home or by patients
Biomedical technician	15	If setup, installation, or maintenance tasks are safety-critical

If your device has only one user group, 15 participants may suffice. If you have three distinct user groups, you need 45 participants.

3. Simulate the use environment

The test environment should replicate the intended use environment as closely as practically possible. For a hospital device, this might mean a simulated hospital room with realistic lighting, noise (including competing alarms), distractions (simulated phone calls, interruptions), and the user wearing appropriate PPE. For a home-use device, a simulated home environment.

4. Use a validated study protocol

The protocol should include:

• Clear task descriptions (without teaching the user how to perform the task)
• Objective success/failure criteria for each task
• Data collection methods (direct observation, video recording, task completion logs)
• Post-task and post-study interview questions to understand the root cause of any observed use errors or difficulties
• Procedures for handling close calls, near misses, and use difficulties that do not meet the definition of use error

5. Analyze results

For each task, document:

• Whether each participant completed the task successfully
• All observed use errors, use difficulties, and close calls
• Root cause analysis for each use error — was it due to perception (the user did not see the information), cognition (the user saw it but misunderstood it), or action (the user understood it but performed the wrong physical action)?
• Whether the use error, if it occurred in real clinical use, could result in harm

Pass/Fail Analysis:

IEC 62366-1 does not define universal pass/fail criteria — the acceptance criteria must be defined by the manufacturer based on the risk analysis. However, the standard and FDA guidance are clear on the general principle: if a summative evaluation reveals use errors associated with critical tasks that could result in serious harm, and those errors cannot be attributed to simulation artifacts or resolved through minor UI modifications, the device has not demonstrated acceptable usability and further design changes are needed.

A common framework for pass/fail analysis:

Observation	Analysis Required	Typical Outcome
No use errors on critical tasks	Document the result. Usability is supported.	Pass
Use errors on critical tasks, all with clear root causes that can be mitigated without design change (e.g., simulation artifact, training gap addressable by existing training)	Document root cause analysis and justification.	Conditional pass with justification
Use errors on critical tasks attributable to UI design	Redesign required. May need repeat summative evaluation.	Fail — redesign and retest
Use difficulties or close calls on critical tasks	Document and assess whether the difficulties suggest a latent design problem that could manifest as use errors in real use	Requires judgment — may warrant further formative evaluation

The Usability Engineering File

The usability engineering file (UEF) is the complete documentation package that demonstrates the manufacturer has applied the usability engineering process defined by IEC 62366-1. It is the usability equivalent of the risk management file defined by ISO 14971.

The UEF is not a single document — it is a collection of documents, records, and references. It must be maintained throughout the product lifecycle and updated as the device design evolves, post-market data is collected, and changes are made.

Required Contents

UEF Section	Contents	Source
Use specification	Intended use, user profiles, use environments, user interface description	IEC 62366-1, clause 5.1
User research records	Contextual inquiry reports, interview summaries, task analyses, literature reviews	IEC 62366-1, clause 5.1 (as input to use specification)
Use-related risk analysis	Identification of use-related hazards, use errors, hazardous situations, risk estimates, risk controls	IEC 62366-1, clause 5.3 (integrated with ISO 14971)
User interface specification	UI requirements derived from use specification and risk analysis	IEC 62366-1, clause 5.4
UI design description	Description of the implemented user interface design	IEC 62366-1, clause 5.5
Formative evaluation records	Protocols, results, identified usability problems, design changes made	IEC 62366-1, clause 5.7
Summative evaluation records	Protocol, participant demographics, task descriptions, results, use error analysis, root cause analysis, conclusions	IEC 62366-1, clause 5.8
Traceability	Cross-references linking use-related risks to UI requirements to UI design to evaluation results	Required for design controls compliance
Post-market usability data	Complaint analysis, adverse event analysis, field observations related to usability	IEC 62366-1, clause 5.9 (lifecycle requirements)

The usability engineering file should be a self-contained, auditable record. An auditor should be able to pick up the UEF and trace the entire logic chain: who the users are, what could go wrong, what was designed to prevent those problems, how the design was tested, and what the results were. If the auditor has to search through your design history file, risk management file, and quality system to reconstruct this story, your UEF is incomplete.

Relationship to the Risk Management File

The UEF and the risk management file (per ISO 14971) overlap significantly. Use-related hazards appear in both. Risk controls for use errors appear in both. Some manufacturers maintain them as separate documents with cross-references; others integrate usability engineering into the risk management file.

Either approach is acceptable, but the cross-references must be complete and bidirectional. Every use-related hazardous situation in the risk management file should trace to the UEF. Every use-related risk control in the risk management file should be verified through the usability evaluation results documented in the UEF.

FDA Human Factors and Usability Engineering Guidance

The FDA has published several guidance documents that define its expectations for human factors engineering and usability engineering in medical device submissions. The most important are:

• "Applying Human Factors and Usability Engineering to Medical Devices" (FDA, 2016) — The primary guidance document
• "List of Highest Priority Devices for Human Factors Review" — Identifies device types where FDA routinely expects a full human factors submission
• "Design Considerations for Devices Intended for Home Use" (FDA, 2014) — Specific guidance for home-use devices

How FDA Guidance Aligns With and Differs From IEC 62366-1

The FDA guidance and IEC 62366-1 share the same fundamental philosophy and process structure. Both require use specification, use-related risk analysis, iterative design evaluation, and final validation testing. However, there are notable differences in terminology and emphasis.

Aspect	IEC 62366-1	FDA Human Factors Guidance
Terminology	"Usability engineering"	"Human factors engineering" (used interchangeably with "usability engineering")
Process name	Usability engineering process	Human factors engineering process
Formative studies	"Formative evaluation"	"Preliminary analyses and evaluations"
Summative studies	"Summative evaluation"	"Human factors validation testing" (HF validation test, HFVT)
Critical tasks	"Primary operating functions" and use-related hazardous situations	"Critical tasks" — explicitly defined as tasks where use errors could cause serious harm
Sample size	No minimum specified	Minimum 15 per user group recommended
Submission content	Usability engineering file	HFE/UE report or summary (specific content expectations for premarket submissions)
Scope	Safety-related usability	Safety-related usability, with emphasis on critical tasks
Risk analysis integration	Requires integration with ISO 14971	Requires use-related risk analysis; does not mandate ISO 14971 specifically but expects equivalent rigor
Post-market	Requires ongoing monitoring	Expects manufacturers to monitor and address use-related complaints and adverse events

FDA's Critical Task Analysis

A central concept in FDA's human factors framework is the identification of critical tasks. FDA defines critical tasks as user tasks where a use error or use difficulty could result in serious harm to the patient, user, or bystander — or could result in the failure to achieve the device's primary clinical benefit.

The critical task analysis should:

1. List all user tasks required for safe and effective use of the device across its entire lifecycle (setup, use, maintenance, cleaning, disposal)
2. For each task, identify potential use errors (based on task analysis, FMEA, literature review, knowledge of similar devices)
3. For each potential use error, assess the potential harm
4. Classify tasks as "critical" if use errors could result in serious harm
5. Prioritize critical tasks for inclusion in the summative evaluation

FDA expects the summative evaluation (HFVT) to test all identified critical tasks. If your device has 40 critical tasks, all 40 must be evaluated. This is a higher bar than IEC 62366-1, which requires evaluation of tasks related to primary operating functions and use-related hazardous situations but does not use the term "critical tasks" with the same explicit categorization that FDA employs.

What FDA Expects in Premarket Submissions

For devices on FDA's priority list (or where FDA specifically requests HFE data), the premarket submission should include an HFE/UE summary that covers:

• Device description, intended users, intended use environments
• Summary of known use problems with the device type (including data from predicate devices, literature, and adverse event databases)
• Critical task analysis
• Summary of formative evaluation activities and key findings
• Summative evaluation protocol, participant demographics, results, use error analysis, and root cause discussion
• Residual use-related risk assessment
• Conclusion that the device can be used safely and effectively by the intended users in the intended use environments

FDA 2022 Draft Guidance: Risk-Based Framework for HFE Submissions

In December 2022, the FDA issued a draft guidance titled "Content of Human Factors Information in Medical Device Submissions," which proposes a significant refinement to how manufacturers determine what human factors information to include in premarket submissions. This guidance introduces a three-category, risk-based framework that replaces the previous binary approach (full HFE report or no HFE data).

The three-category framework is structured as follows:

Category	Risk Level	Required HFE Submission Content	Typical Device Examples
Category 1	Low use-related risk — devices with simple user interfaces, well-established use patterns, and minimal potential for use errors that could cause harm	Limited human factors information: a brief description of the device users, use environments, and user interface; a statement that the manufacturer applied usability engineering; identification of any known use-related problems with similar devices	Simple Class I/II devices with minimal user interaction, devices with well-established user interfaces identical to legally marketed predicates
Category 2	Moderate use-related risk — devices with user interfaces that present some potential for use errors that could cause harm, but where the use-related risks are well-characterized and manageable	Abbreviated HF report: use specification summary, critical task identification, summary of use-related risk analysis, summary of formative evaluation activities and key findings, and a rationale for why summative testing is not warranted (or limited summative results)	Moderate-complexity Class II devices, devices with modified user interfaces compared to predicates, devices with new but low-risk user interface features
Category 3	High use-related risk — devices with complex user interfaces, new interaction paradigms, critical tasks where use errors could cause serious harm, or devices intended for lay users in uncontrolled environments	Full HF report with summative testing: complete use specification, critical task analysis, use-related risk analysis, detailed formative evaluation summaries, full summative evaluation (HFVT) protocol and results including use error analysis and root cause analysis, residual risk assessment	Complex Class II/III devices, devices on FDA's priority list, combination products, home-use devices with critical tasks, devices with novel user interfaces

The draft guidance also provides a decision flowchart that helps manufacturers determine which category applies to their device. Key decision factors include:

• Whether the device is on FDA's list of highest priority devices for human factors review
• Whether the device has a new or significantly modified user interface compared to the predicate
• Whether the device introduces new critical tasks
• Whether the device is intended for use by lay users (patients or caregivers) in home or non-clinical settings
• The severity of potential harm from use errors on critical tasks

As of the date of this guide, the 2022 draft guidance has not been finalized. Manufacturers should monitor FDA's guidance page for the final version. However, the three-category framework provides a useful conceptual model for scaling HFE efforts and submission content even before the guidance is finalized. The underlying principle — that the depth of HFE documentation should be proportionate to the use-related risk — is consistent with both IEC 62366-1 and the FDA's 2016 final guidance.

EU MDR Usability Requirements

The EU Medical Devices Regulation (MDR 2017/745) establishes usability requirements through its General Safety and Performance Requirements (GSPRs) in Annex I. Unlike FDA guidance, which is device-specific, the MDR requirements apply to all medical devices placed on the EU market.

Key GSPR Requirements Related to Usability

GSPR	Requirement Summary	Usability Relevance
5	Devices shall be designed to reduce risks related to ergonomic features, the user interface, and the environment in which the device is intended to be used	Direct usability requirement. Mandates that the design minimizes use-related risks arising from ergonomic and UI factors.
14.1	Devices and their manufacturing processes shall be designed to eliminate or reduce as far as possible the risk of infection, including by facilitating safe cleaning and decontamination	Usability of reprocessing procedures — can users effectively clean and disinfect the device?
14.2(d)	Information included by the manufacturer on the device itself, packaging, or IFU for safe use shall consider the knowledge, experience, education, training, and use environment of intended users	Requires user-centered design of labeling and IFU. Not just regulatory text, but information designed for the actual user.
22	Devices with a diagnostic or measuring function shall be designed and manufactured to provide sufficient accuracy, precision, and stability for their intended purpose, taking account of the reasonably foreseeable conditions of use	The "conditions of use" clause requires consideration of how the user's interaction with the device affects measurement accuracy.
23.1-23.4 (Software)	Software shall be developed in accordance with the state of the art, considering IT security, verification, validation, and the interaction between software and its environment	For software devices, usability of the software UI is a core design requirement.

How Notified Bodies Audit Usability Under EU MDR

Notified Bodies assess usability engineering as part of design controls audits. They will typically:

1. Verify that a usability engineering process has been applied (per IEC 62366-1 as the harmonized standard)
2. Review the usability engineering file for completeness
3. Check that the use-related risk analysis is integrated with the ISO 14971 risk management file
4. Assess whether formative and summative evaluations were conducted with appropriate rigor
5. Verify that use-related risks identified in the risk analysis are addressed through design changes (not solely through labeling and training)
6. Confirm that post-market surveillance includes monitoring for use-related adverse events and use problems
7. Evaluate the traceability between GSPRs, use-related risks, UI requirements, and evaluation results

Under the MDR, the presumption of conformity with usability-related GSPRs is achieved by demonstrating conformity with IEC 62366-1. If you do not follow IEC 62366-1, you must demonstrate through alternative means that your usability engineering process meets the GSPR requirements — a significantly harder burden of proof.

Use-Related Risk Analysis: Connecting Usability to ISO 14971

The integration between IEC 62366-1 and ISO 14971 is one of the most technically important aspects of usability engineering for medical devices. These two standards are designed to work together, and auditors expect to see a seamless connection between them.

How the Standards Interact

ISO 14971 defines the overall risk management framework. IEC 62366-1 defines the usability engineering process that feeds into and draws from that framework.

The interaction points are:

ISO 14971 Activity	IEC 62366-1 Contribution
Hazard identification	Use-related risk analysis identifies hazards arising from user interaction with the device
Risk estimation	Use-related risk analysis estimates the probability and severity of harm from use errors
Risk evaluation	Use-related risks are evaluated against the same risk acceptability criteria used in the overall risk management process
Risk control	UI design changes, protective measures, and information for safety are implemented as risk controls for use-related risks
Residual risk evaluation	Summative evaluation provides objective evidence of the effectiveness of use-related risk controls
Overall residual risk evaluation	Usability evaluation results feed into the overall benefit-risk determination
Post-production monitoring	Post-market usability data (complaints, adverse events related to use errors) feeds back into the risk management process

Practical Integration Approach

The most effective approach is to maintain a single, integrated risk analysis that includes both non-use-related and use-related hazards. In this analysis:

• Use-related hazards are identified using task analysis and FMEA of user interactions
• Each use-related hazardous situation is linked to the specific user task, user interface element, and potential use error that could cause it
• Risk controls include both design changes to the user interface and non-UI risk controls (e.g., hardware safety interlocks)
• The effectiveness of UI-related risk controls is verified through usability evaluations (formative and summative)
• Cross-references connect each row in the risk analysis to the relevant sections of the usability engineering file

AAMI HE75: Human Factors Engineering Design Reference

AAMI HE75:2009/(R)2018, titled "Human factors engineering — Design of medical devices," is one of the most important complementary documents to IEC 62366-1. While IEC 62366-1 defines the process requirements for usability engineering (what you must do), AAMI HE75 provides detailed, evidence-based design guidance for the physical and cognitive aspects of medical device user interfaces (how to design them well).

Role and Scope

AAMI HE75 is a comprehensive human factors design reference spanning approximately 400 pages. It covers the full range of user interface design considerations for medical devices, including:

• Display design (visual displays, color coding, typography, information hierarchy)
• Control design (buttons, knobs, sliders, touchscreens, foot pedals)
• Auditory signals and alarm design
• Labeling and instructions for use
• Physical ergonomics (reach, grip, force, posture)
• Workspace and environmental design
• User interface design for specific user populations (elderly, pediatric, users with disabilities)
• Software user interface design principles
• Connectors and connection design (prevention of misconnections)

Unlike IEC 62366-1, AAMI HE75 does not define a process. It is a design reference — a compendium of human factors principles, design guidelines, anthropometric data, and evidence-based recommendations that designers and human factors engineers consult when making specific design decisions.

FDA Recognition

AAMI HE75 is recognized by the FDA as a consensus standard. FDA's recognition means that manufacturers can declare conformity with specific clauses of AAMI HE75 as part of their premarket submission, and the FDA will accept this declaration as evidence that the relevant design aspects meet human factors engineering best practices.

In practice, FDA reviewers are familiar with AAMI HE75 and may reference it when evaluating whether a device's user interface design reflects the state of the art. If a device uses a 6-point font for critical safety information when AAMI HE75 recommends a minimum of 12-point font for such information, an FDA reviewer may cite this as a design deficiency — even if the manufacturer did not explicitly claim conformity with AAMI HE75.

How AAMI HE75 Differs From IEC 62366-1

Aspect	IEC 62366-1	AAMI HE75
Document type	Process standard (normative requirements)	Design reference (informative guidance)
Focus	What usability engineering activities to perform	How to design specific UI elements for safe and effective use
Scope	Safety-related usability process for all medical devices	Detailed design guidance for physical, cognitive, and perceptual aspects of medical device user interfaces
Auditable	Yes — defines mandatory process requirements	Not directly auditable as a process standard, but referenced as state of the art for design decisions
Typical use	Structuring the usability engineering program, satisfying regulatory requirements	Making specific design decisions (font size, button spacing, alarm frequency, color contrast), resolving design trade-offs with evidence
Regulatory status	Harmonized standard (EU), recognized consensus standard (FDA)	Recognized consensus standard (FDA)

Practical Integration

The most effective approach is to use IEC 62366-1 to structure the usability engineering process and AAMI HE75 to inform specific design decisions within that process. When writing the user interface specification (IEC 62366-1, clause 5.4), reference AAMI HE75 for evidence-based design parameters — minimum font sizes, recommended color contrast ratios, alarm frequency ranges, button dimensions, and control-display relationships. When conducting formative evaluations, use AAMI HE75 criteria as a benchmark for heuristic evaluation. When analyzing use errors in summative evaluation, consult AAMI HE75 to determine whether the design deviated from established human factors principles.

User Interface of Unknown Provenance (UOUP)

One of the most practically significant — and frequently misunderstood — concepts in IEC 62366-1 is the User Interface of Unknown Provenance (UOUP). Defined in clause 5.10 and elaborated in Annex C, the UOUP concept provides a simplified evaluation pathway for user interface components that were not originally designed under a usability engineering process compliant with IEC 62366-1.

What Is a UOUP?

A UOUP is any user interface element, component, or sub-system that is incorporated into a medical device but was not developed under the manufacturer's usability engineering process. The "unknown provenance" does not mean the origin is literally unknown — it means the component was not developed with the specific usability engineering rigor required by IEC 62366-1 for the medical device context in which it is now being used.

Common examples of UOUPs include:

• COTS (commercial off-the-shelf) hardware components: Standard computer mice, keyboards, trackballs, displays, barcode scanners, and printers that are incorporated into a medical device system
• COTS software components: Operating system user interfaces (Windows, Linux), third-party software libraries with user-facing elements, web browsers used as part of a medical device workflow
• Legacy device interfaces: User interfaces from a predicate device or a previous device generation that was designed and marketed before the manufacturer implemented IEC 62366-1
• Third-party sub-systems: Modules or accessories from other manufacturers that have their own user interfaces (e.g., a third-party patient monitor integrated into a surgical system)
• Standard clinical peripherals: Foot pedals, hand switches, or touchscreen overlays sourced from general-purpose suppliers

When Does the UOUP Process Apply?

The UOUP process applies whenever a manufacturer incorporates a user interface element that was not developed under the manufacturer's own usability engineering process for the specific device. This is an extremely common situation — very few medical device manufacturers design every component of their user interface from scratch.

The UOUP process does not exempt these components from usability engineering. Rather, it provides a streamlined, risk-based evaluation method that avoids the impractical requirement of conducting a full usability engineering process retroactively on components that may have years or decades of established use.

The Five-Step UOUP Evaluation Process

IEC 62366-1 Annex C describes a simplified evaluation process for UOUPs. The process is structured as five steps:

Step	Activity	Description
1	Identify the UOUP	Document each user interface element that qualifies as a UOUP. Record its source, its function in the medical device, and the user tasks that involve it.
2	Identify use-related hazards	Using the device's use-related risk analysis, identify the hazards associated with user interaction with the UOUP. What could go wrong when users interact with this component in the medical device context?
3	Search for evidence of problems	Gather evidence about the UOUP's usability performance. Sources include: complaint data from the component manufacturer, adverse event reports (MAUDE, vigilance databases) for devices using the same component, published literature, the manufacturer's own field experience, and user feedback.
4	Evaluate the evidence	Assess whether the available evidence indicates that the UOUP introduces unacceptable use-related risks in the medical device context. Consider whether known use problems with the component are relevant to the medical device application.
5	Determine the need for additional action	Based on the evaluation, decide whether additional risk controls, design modifications, or usability testing are needed. If the evidence indicates acceptable usability performance, document the rationale. If the evidence is insufficient or indicates problems, conduct targeted usability evaluation activities.

Practical Examples

Example 1: Standard keyboard and mouse for a hospital workstation. A diagnostic imaging workstation uses a standard USB keyboard and mouse. These are UOUPs. The manufacturer identifies that critical diagnostic tasks (adjusting window/level, measuring structures) are performed via the keyboard and mouse. Evidence review reveals that standard keyboards and mice have extensive use history in clinical settings with no significant reported use problems related to the basic input functions. The manufacturer documents this evidence and concludes that the standard keyboard and mouse do not introduce unacceptable use-related risks. No additional testing of the keyboard and mouse themselves is required — though the overall workstation interface that uses these inputs must still undergo the full usability engineering process.

Example 2: Legacy infusion pump interface. A manufacturer is updating the software of an infusion pump that has been on the market for eight years. The physical user interface (buttons, display layout, alarm indicators) was designed before the manufacturer implemented IEC 62366-1. The physical interface is a UOUP. The manufacturer reviews complaint data, MAUDE reports, and internal field service records. The review reveals three documented use errors related to the button layout (users pressing the wrong button when wearing gloves). The manufacturer determines that additional risk controls are needed — specifically, a software confirmation step for critical dose changes — and conducts targeted formative evaluation of the modified workflow. The physical interface does not need to be redesigned from scratch, but the identified risk must be mitigated.

Example 3: Third-party barcode scanner. A pharmacy dispensing system incorporates a third-party handheld barcode scanner. The scanner is a UOUP. The manufacturer identifies that barcode scanning is a critical task (scanning the wrong medication could lead to a dispensing error). Evidence review shows the scanner model is widely used in healthcare settings with a known failure mode: the scanner occasionally misreads damaged or poorly printed barcodes. The manufacturer implements a software verification step (displaying the scanned medication name for user confirmation) and includes barcode scanning tasks in the summative evaluation of the overall system.

The UOUP process is not a shortcut to avoid usability engineering. It is a pragmatic mechanism for handling the reality that medical devices are complex systems built from many components, not all of which were designed specifically for the medical context. The key principle is that the manufacturer remains responsible for the usability and safety of the complete device, including all UOUP components. The UOUP evaluation must be documented in the usability engineering file, and auditors will expect to see evidence that the manufacturer considered the usability implications of every incorporated component.

Formative Evaluations: Methods, Timing, and Practical Considerations

When to Conduct Formative Evaluations

Formative evaluations should be conducted throughout the design process. The general principle is: evaluate early, evaluate often, and evaluate at increasing levels of fidelity.

Design Phase	Formative Evaluation Type	Fidelity	Typical Focus
Concept development	Expert review, heuristic evaluation	Paper sketches, wireframes	Overall layout, workflow, information architecture
Early design	Cognitive walkthrough, think-aloud with paper prototypes	Low fidelity (paper, clickable wireframes)	Navigation, task flow, terminology, mental model alignment
Detailed design	Simulated use testing with interactive prototypes	Medium fidelity (interactive prototype, partial functionality)	Task completion, error rates, comprehension of critical information
Pre-validation	Simulated use testing with near-final design	High fidelity (functional prototype or production-equivalent)	Full task performance, identification of remaining usability issues before summative evaluation

Sample Sizes for Formative Evaluations

There is no regulatory minimum sample size for formative evaluations. The goal is to find and fix problems, not to achieve statistical significance. General guidance:

• Heuristic evaluation: 3-5 human factors experts. Research shows that 3-5 evaluators identify the large majority of heuristic violations.
• Usability testing (think-aloud, simulated use): 5-8 participants per user group for each round of testing. This is typically sufficient to identify the major usability problems. After fixing those problems, test again with another 5-8 participants to verify fixes and identify any remaining issues.
• Specialized evaluations (e.g., testing with elderly patients, testing in low-light conditions): Sample size depends on the variability of the user population. More diverse populations require larger samples.

Documenting Formative Evaluations

For each formative evaluation, document:

1. Objective — What question were you trying to answer?
2. Method — What evaluation method was used?
3. Prototype/device description — What was tested, at what fidelity level?
4. Participants — How many, from which user group, with what characteristics?
5. Tasks — What tasks were evaluated?
6. Findings — What usability problems were identified? Categorize by severity and type.
7. Recommendations — What design changes were recommended?
8. Design changes made — What was actually changed in response?
9. Open issues — What problems remain to be addressed in subsequent iterations?

Common Use Errors vs Use Problems: Categorization and Analysis

Understanding the taxonomy of use-related observations is essential for accurate analysis and effective design improvement.

Definitions

Term	Definition	Example
Use error	User action or lack of action that leads to a different result than intended by the manufacturer or expected by the user	User sets infusion rate to 100 mL/hr instead of 10 mL/hr due to ambiguous display
Use difficulty	The user perceives or reports difficulty using the device, even though the task was ultimately completed correctly	User struggles to read a small label but eventually reads it correctly
Close call / near miss	The user begins to make a use error but catches and corrects it before the error is completed	User starts to connect a tube to the wrong port, notices the color coding, and connects to the correct port
Use problem	Broader term encompassing use errors, use difficulties, and close calls	Any observation of the user struggling, erring, or nearly erring during device use

Root Cause Categories for Use Errors

When a use error is observed, the analysis must identify the root cause. Use errors generally fall into three categories based on the stage of human information processing that failed:

Root Cause Category	Description	Example	Design Implication
Perception error	The user did not perceive the information needed to perform the task correctly	User did not see a warning message because it was displayed in low contrast on a cluttered screen	Improve visibility — larger text, higher contrast, better placement, remove clutter
Cognition error	The user perceived the information but misunderstood or misinterpreted it	User saw the dose display but misinterpreted "1.0" as "10" due to a small decimal point	Improve clarity — larger decimal points, units displayed prominently, use of leading zeros
Action error	The user understood the correct action but executed it incorrectly	User intended to press the "Start" button but pressed the adjacent "Bolus" button due to small button size and close spacing	Improve physical design — larger buttons, greater spacing, distinct tactile feedback, confirmation dialogs for critical actions

Every use error observed in summative testing should be analyzed to the root cause level. Simply counting errors is not sufficient. The root cause tells you what to fix. Two devices with the same number of use errors can have completely different underlying problems — one may have a visibility issue, the other a comprehension issue — requiring completely different design solutions.

Usability for Software as a Medical Device (SaMD) and Software-Driven Devices

Software-based medical devices present unique usability engineering challenges that extend beyond physical device design.

Platform and Context Variability

SaMD may run on multiple platforms (iOS, Android, Windows, web browsers) with different screen sizes, input methods, and interaction paradigms. The use specification must address each platform, and the usability evaluation must cover all supported platforms — or provide a justification for testing on a subset.

Interaction Complexity

Software interfaces offer virtually unlimited design possibilities, which paradoxically increases the risk of usability problems. Physical devices constrain interaction through their form factor; software devices do not. This means software designers must impose constraints deliberately through UI design patterns.

Update and Iteration Cycles

Software devices are updated more frequently than hardware devices. Each update that modifies the user interface is a potential source of new use errors, especially if the update changes an interaction pattern that existing users have learned. The usability engineering process must address the impact of UI changes on existing users — including the risk of "negative transfer" where learned behavior on the old interface leads to use errors on the new interface.

SaMD-Specific Considerations

Consideration	Description
Display variability	Font sizes, colors, and layouts may render differently across devices. Test on representative hardware.
Network dependency	If the device requires network connectivity, consider the usability impact of latency, disconnection, and data synchronization failures. How does the user know the device is not connected?
Input methods	Touchscreen, mouse/keyboard, voice — each has different error profiles. Touch targets must be sized appropriately for the input method (minimum 44x44pt for touch per Apple HIG, similar guidelines from Google).
Accessibility	Software accessibility standards (WCAG, Section 508) may apply. Screen readers, color blindness modes, and assistive technology compatibility affect usability for users with disabilities.
Notifications and alerts	Software alarm management is a significant usability and safety concern. How does the device alert the user? How does the user distinguish critical alerts from informational messages? What happens if the user's phone is on silent?
Data entry	Free-text data entry is a significant source of use errors. Prefer structured inputs (dropdowns, sliders, segmented controls) over free-text fields for safety-critical data.
Clinical decision support	If the SaMD presents clinical recommendations, the user must be able to understand the basis for the recommendation, its confidence level, and its limitations. Opaque "black box" outputs are a usability and safety concern.

IEC 62304 and IEC 62366 Integration for Software

For software medical devices, IEC 62304 (software lifecycle) and IEC 62366-1 (usability engineering) must be applied concurrently. The software design process defined by IEC 62304 should incorporate usability requirements from IEC 62366-1, and the usability evaluation results should feed back into software verification and validation.

The UI specification from IEC 62366-1 becomes a subset of the software requirements specification under IEC 62304. Formative evaluations can be aligned with software development sprints or milestones. Summative evaluation typically aligns with the software validation phase.

Usability Engineering for Drug-Device Combination Products

Drug-device combination products — such as pre-filled syringes, auto-injectors, metered-dose inhalers, transdermal patches, and drug-eluting implants — present unique and heightened usability engineering challenges. These products combine a drug component and a device component into a single integrated system, and the user's interaction with the device directly determines whether the drug is delivered safely and effectively.

Why Combination Products Demand Rigorous Usability Engineering

The fundamental challenge is that use errors with combination products can result in both device-related harm and drug-related harm simultaneously. A use error with a standalone device may cause a burn, a laceration, or a missed diagnosis. A use error with a combination product can cause all of those — plus an overdose, underdose, wrong route of administration, or medication error that triggers an adverse drug reaction.

The FDA has identified combination products as a high-priority area for human factors engineering. The agency's guidance document "Human Factors Studies and Related Clinical Study Considerations in Combination Product Design and Development" (2016) establishes expectations that go beyond the standard IEC 62366-1 process.

Key Challenges Specific to Combination Products

Challenge	Description	Usability Implication
Medication errors	Use errors can result in wrong dose, wrong drug, wrong route, or wrong timing — categories of medication error that have established clinical severity classifications	The critical task analysis must explicitly map use errors to medication error categories and assess the clinical consequences of each
Self-administration by patients	Many combination products (insulin pens, auto-injectors, inhalers) are used by patients at home with no clinical supervision	Users may have no medical training, limited dexterity (e.g., rheumatoid arthritis patients using an auto-injector), low health literacy, or cognitive impairment. The device must be usable by the least capable intended user under the least favorable intended conditions.
Dose preparation and delivery	The user must correctly prepare and deliver the drug — steps that involve both the device mechanism and the drug handling	Errors in dose dialing, cartridge insertion, needle attachment, priming, injection technique, and dose confirmation are all potential sources of harm
Storage and handling	Many combination products have specific storage requirements (temperature, orientation) that the user must follow	Labeling and packaging must clearly communicate storage requirements in a way that lay users understand and follow
Multi-step use sequences	Combination products often require a sequence of steps (assemble, prime, dial dose, inject, hold, remove, dispose) where errors in any step can compromise drug delivery	The entire use sequence must be evaluated, not just individual steps. Users may skip steps, perform steps out of order, or fail to complete the full sequence.
Needle-based delivery	Needle phobia, injection anxiety, and pain avoidance can cause users to inject too quickly, remove the needle too early, or avoid self-injection altogether	The usability engineering process must consider the psychological and emotional aspects of self-injection, not just the mechanical aspects

FDA Expectations for Combination Product Human Factors

FDA expects combination product manufacturers to:

1. Conduct a comprehensive use-related risk analysis that covers both device-related and drug-related hazards, including all categories of medication error
2. Include medication error scenarios in the critical task analysis — not just device malfunction scenarios
3. Test the complete user experience including the instructions for use, packaging, labeling, and any training materials as part of the usability evaluation
4. Evaluate the full use sequence from opening the package through disposal of the used device
5. Include actual drug preparation and delivery tasks in summative testing (using placebo or simulated drug product where appropriate)
6. Assess the effectiveness of the IFU as a standalone training mechanism, since many combination products are used by patients who receive the IFU as their only form of training
7. Provide a detailed analysis of observed use errors that maps each error to its potential clinical consequence (e.g., "user failed to prime the pen, resulting in an estimated underdose of 2 units")

Regulatory Pathway Considerations

Combination products may be regulated by FDA's Center for Drug Evaluation and Research (CDER), Center for Biologics Evaluation and Research (CBER), or Center for Devices and Radiological Health (CDRH), depending on the primary mode of action. Regardless of which center has lead jurisdiction, all three centers expect human factors data. The Office of Combination Products coordinates review, and human factors is a shared review responsibility.

For EU MDR, combination products that incorporate a drug as an integral part are regulated as medical devices (Article 1(8)), and the full IEC 62366-1 usability engineering process applies. The drug component is subject to a consultation procedure with a medicines authority, but the usability engineering of the device component remains the manufacturer's responsibility under the MDR framework.

Combination products are among the most frequently cited device types in FDA human factors deficiency letters. The most common finding is that the manufacturer tested the device component in isolation without evaluating the complete use sequence including drug preparation, dose setting, delivery, and post-delivery steps. Always test the complete user experience — from the moment the user opens the package to the moment they dispose of the used product.

Integration With Design Controls (IEC 62366 + ISO 13485 Clause 7.3)

Usability engineering is not a standalone activity — it is embedded within the design control process defined by ISO 13485 clause 7.3. The following table maps IEC 62366-1 activities to design control phases:

ISO 13485 Design Control Phase	IEC 62366-1 Activity	Deliverable
7.3.2 Design and development planning	Plan the usability engineering process; define resources, timeline, responsibilities	Usability engineering plan (can be part of the design plan)
7.3.3 Design and development inputs	Use specification; user research; use-related risk analysis; UI specification	Use specification, use-related risk analysis, UI specification
7.3.4 Design and development outputs	UI design and implementation	User interface design documentation
7.3.5 Design and development review	Review usability evaluation results at design reviews; review adequacy of use-related risk controls	Design review records documenting usability review
7.3.6 Design and development verification	Formative evaluations verify that the UI meets the UI specification	Formative evaluation reports
7.3.7 Design and development validation	Summative evaluation validates that users can use the device safely in the intended use environment	Summative evaluation report
7.3.8 Design and development transfer	Ensure manufacturing does not alter UI characteristics that affect usability (e.g., label print quality, screen calibration)	Transfer verification records
7.3.9 Control of design and development changes	Assess usability impact of any design change that affects the user interface	Change control records with usability impact assessment

For FDA-regulated products, usability engineering must also align with 21 CFR 820 design controls (or the new QMSR which references ISO 13485). The mapping is essentially the same — design inputs include usability requirements, design outputs include the UI design, verification includes formative evaluation, and validation includes summative evaluation. Ensure your design history file (DHF) references or incorporates the usability engineering file.

Common Audit Findings and Regulatory Submission Pitfalls

Based on published Notified Body findings, FDA deficiency letters, and industry experience, the following are the most frequent usability engineering problems encountered during audits and regulatory reviews.

Process-Level Findings

Finding	Description	How to Avoid
No usability engineering process	The manufacturer did not apply IEC 62366-1 at all, or applied it only superficially	Establish the process from the start of design. Do not treat usability as an afterthought.
Use specification missing or incomplete	No documented analysis of intended users, use environments, or user interface elements	Write the use specification early and update it throughout development. Base it on actual user research, not assumptions.
No user research	The use specification is based entirely on the design team's assumptions about users and use environments	Conduct contextual inquiry, user interviews, or at minimum a thorough literature review of known use problems with similar devices.
Use-related risk analysis not integrated with ISO 14971	The usability engineering file and risk management file exist in isolation, with no cross-references	Use a single risk analysis or maintain rigorous bidirectional traceability between the two files.
Formative evaluations not documented	The manufacturer claims to have conducted formative evaluations but has no records	Document every formative evaluation, even informal ones. Records do not need to be elaborate, but they must exist.
No traceability	Cannot trace from use-related risk to UI requirement to design feature to evaluation result	Build the traceability matrix as you go. Do not attempt to reconstruct it retroactively.

Summative Evaluation Findings

Finding	Description	How to Avoid
Participants not representative	Participants were engineers or company employees, not representative of intended users	Recruit participants who match the user profiles in the use specification. Screen for relevant qualifications and experience.
Tasks not based on risk analysis	The summative evaluation tested general usability rather than tasks associated with critical use scenarios	Derive summative evaluation tasks directly from the use-related risk analysis and critical task analysis.
No acceptance criteria	The summative evaluation had no predefined pass/fail criteria	Define acceptance criteria before the study. Base them on the risk analysis.
Use errors not analyzed to root cause	Use errors were counted but not analyzed for root cause (perception, cognition, action)	Conduct post-task interviews and root cause analysis for every observed use error.
Inadequate use environment simulation	Testing was conducted in a quiet, well-lit room with no distractions — not representative of actual use	Simulate the intended use environment, including lighting, noise, distractions, gloves, and time pressure.
Training provided during study	Participants were trained or coached during the study in a way that would not occur in real use	Provide only the training that actual users would receive. Do not coach participants or provide hints.

Regulatory Submission Pitfalls

Pitfall	Description	How to Avoid
Submitting too late	Usability data submitted only after FDA requests it, causing review cycle delays	Include usability data in the initial submission for any device on FDA's priority list or any device with significant user interaction.
Incomplete HFE report	The HFE/UE report does not include all elements expected by FDA (known use problems, critical task analysis, formative summary, summative results, residual risk assessment)	Follow the FDA guidance document structure. Address every section, even if briefly.
Dismissing use errors without justification	Summative evaluation results show use errors on critical tasks, and the manufacturer dismisses them as "user training issues"	Provide rigorous root cause analysis for every use error. If training is the mitigation, demonstrate that the training program is effective and will reach all users.
Relying solely on labeling and training	All use-related risk controls are warnings, instructions, or training requirements — no design changes	Demonstrate that design-based risk controls were considered and implemented where feasible. Labeling and training should be the last resort.

Practical Tips for Implementing a Usability Engineering Program

Starting a Program From Scratch

If your organization has not previously implemented a formal usability engineering process, the following approach provides a practical starting path:

1. Assign responsibility. Designate a human factors lead — either an internal hire or an external consultant. This person needs both human factors expertise and regulatory knowledge.

2. Write a usability engineering SOP. Define your organization's standard process for usability engineering, referencing IEC 62366-1 and applicable FDA guidance. The SOP should cover when usability engineering is required, what activities are mandatory, roles and responsibilities, and documentation requirements.

3. Integrate into design controls. Modify your design and development procedures to include usability engineering milestones — use specification at design input, formative evaluations at design review, summative evaluation at design validation.

4. Build a participant recruitment pipeline. Summative evaluations require 15+ participants per user group. Start building relationships with clinical sites, patient advocacy groups, and professional organizations that can provide access to representative users. Use a recruitment screener aligned with your use specification.

5. Invest in a usability testing facility or partnership. You need a space to conduct simulated use testing — either an internal usability lab or a relationship with a contract research organization (CRO) that specializes in medical device human factors.

6. Train your design team. Designers, engineers, and project managers should understand the basics of human factors engineering, common use error patterns, and the regulatory requirements. They do not need to become human factors specialists, but they need to recognize usability issues and understand the process.

Ongoing Program Management

• Review post-market data for use-related trends. Analyze complaints, adverse event reports, and customer feedback for patterns that suggest use problems. Feed these findings back into the risk analysis and use them to guide design improvements in future device versions.
• Maintain the usability engineering file as a living document. The UEF does not end at product launch. Post-market findings, design changes, and new user research should be incorporated throughout the product lifecycle.
• Benchmark against similar devices. Monitor adverse event databases (FDA MAUDE, EU vigilance systems) for use-related events involving similar devices. These events may indicate risks that your device shares.
• Plan for international requirements. If you market devices in multiple jurisdictions, your usability engineering program must satisfy the most stringent requirements. In practice, this usually means satisfying both FDA expectations (15 participants per group, critical task analysis) and EU MDR requirements (IEC 62366-1 conformity, GSPR traceability).

Cost-Effective Usability Engineering

A common concern, especially for smaller manufacturers, is the cost of usability engineering. The following strategies can make the process more efficient without compromising quality:

• Start early. Finding and fixing usability problems during concept development (with paper prototypes and expert reviews) costs a fraction of what it costs to fix them after summative evaluation failure.
• Combine formative evaluations with other design activities. Formative usability testing can be combined with clinical feedback sessions, design reviews, or prototype demonstrations.
• Use remote testing where appropriate. For SaMD and software devices, remote usability testing (with screen sharing and video) can reduce the cost and logistics of participant recruitment, especially for geographically distributed user populations. However, remote testing is generally not appropriate for summative evaluations of physical devices where the use environment must be simulated.
• Leverage existing data. Adverse event databases, published literature, and complaint records for predicate or similar devices provide valuable input to the use-related risk analysis without requiring original research.
• Scale the effort to the risk. IEC 62366-1 and FDA guidance both recognize that the depth of usability engineering should be proportionate to the risk. A simple, single-function, Class I device does not need the same program as a complex, multi-modal, Class III life-sustaining device. Document your rationale for the level of effort, and ensure it is justified by the risk analysis.

Key Success Factors

The organizations that implement usability engineering most effectively share several characteristics:

• Leadership commitment. Usability engineering is a cross-functional activity that requires time, budget, and organizational support. It cannot succeed as a side project run by one engineer.
• Early integration. Usability is considered from the first concept sketch, not bolted on at the end of development.
• User access. The design team has regular, direct contact with representative users — not filtered through marketing or sales.
• Iterative culture. The organization expects and plans for multiple design iterations based on evaluation feedback. Finding usability problems is treated as a success (the process is working), not a failure (the design team made mistakes).
• Documentation discipline. Records are created contemporaneously with activities, not reconstructed retroactively for audits.

The most expensive usability engineering program is one that is implemented after a summative evaluation failure, an FDA deficiency letter, or an adverse event. Invest in the process upfront, and it will pay for itself many times over in reduced development risk, faster regulatory clearance, and safer devices for patients.

Summary: The Usability Engineering Process at a Glance

Step	IEC 62366-1 Clause	Key Output	Integration Point
Use specification	5.1	Documented users, environments, UI elements	ISO 14971 intended use, ISO 13485 design inputs
User research	5.1 (input)	Contextual inquiry reports, task analyses	Informs use specification and risk analysis
Use-related risk analysis	5.3	Identified use-related hazards, risks, risk controls	ISO 14971 risk management file
UI specification	5.4	Measurable UI requirements	ISO 13485 design inputs
UI design and implementation	5.5, 5.6	Implemented user interface	ISO 13485 design outputs
Formative evaluation	5.7	Evaluation reports, design improvements	ISO 13485 design verification / review
Summative evaluation	5.8	Validation report, use error analysis	ISO 13485 design validation
Post-market monitoring	5.9	Ongoing usability data analysis	ISO 14971 production and post-production, ISO 13485 CAPA

Usability engineering is not a regulatory checkbox. It is a systematic discipline for understanding how humans interact with medical devices and designing those devices to support safe, effective use. Done well, it prevents patient harm, reduces recalls, accelerates regulatory clearance, and produces devices that clinicians and patients actually want to use. Done poorly — or not done at all — it puts patients at risk and exposes manufacturers to regulatory action, litigation, and reputational damage.

IEC 62366-1 provides the framework. The work of applying it well belongs to the teams that design, build, and bring medical devices to market.

Frequently Asked Questions

Does IEC 62366 apply to IVDs?

Yes. IEC 62366-1:2015 explicitly applies to in vitro diagnostic (IVD) medical devices. The standard's scope statement includes "all types of medical devices," and IVDs are medical devices under all major regulatory frameworks (EU IVDR, FDA, MDSAP). IVDs present significant usability challenges — particularly point-of-care and home-use IVDs (e.g., blood glucose meters, rapid diagnostic tests, home pregnancy tests) where lay users perform analytical procedures that were traditionally performed by trained laboratory personnel. Under the EU IVDR (2017/746), IEC 62366-1 is a harmonized standard, providing a presumption of conformity with the relevant General Safety and Performance Requirements. The FDA also expects human factors data for IVDs with significant user interaction, particularly home-use IVDs and point-of-care tests.

How many participants are needed for summative evaluation?

IEC 62366-1 does not specify a minimum number of participants. The standard requires that the summative evaluation be sufficient to provide "objective evidence" that the user interface supports safe use, but leaves the sample size determination to the manufacturer. However, the FDA human factors guidance recommends a minimum of 15 participants per distinct user group. This recommendation is based on the binomial probability reasoning that 15 participants provide approximately 90-95% confidence that a use error with a true occurrence rate of 5% or greater will be observed at least once during the study. If your device has multiple distinct user groups (e.g., physician, nurse, and patient), you need 15 participants per group. Some manufacturers use larger samples (20-25 per group) for higher-risk devices or when the user population is particularly diverse. Smaller samples may be justified for devices with a very limited user population (e.g., a device used only by interventional cardiologists), but the rationale must be documented and defensible.

What is the difference between formative and summative evaluation?

Formative evaluations are conducted during the design process to identify usability problems and guide design improvements. They are diagnostic in nature — the goal is to find problems, not to prove the design is adequate. Formative evaluations have no pass/fail criteria, can use prototypes at any fidelity level, and typically involve smaller participant groups (5-8 per user group). You can conduct as many formative evaluations as needed, and the findings drive design changes.

Summative evaluation is the final, formal validation of the user interface design. It is conducted with the final or near-final design, uses predefined acceptance criteria, follows a validated study protocol, and involves a representative sample of intended users (typically 15+ per user group per FDA guidance). The summative evaluation is a pass/fail assessment — it provides objective evidence that the device can be used safely by the intended users in the intended use environment, or it reveals use errors that require design changes and potential retesting. In the FDA framework, summative evaluation is referred to as "Human Factors Validation Testing" (HFVT).

Is IEC 62366-1 mandatory?

The mandatory status of IEC 62366-1 depends on the regulatory jurisdiction and the manufacturer's regulatory strategy. In the European Union, IEC 62366-1 is a harmonized standard under both the MDR and IVDR. Conformity with the harmonized standard creates a presumption of conformity with the relevant GSPRs, which is the simplest and most widely accepted path to demonstrating compliance. A manufacturer could theoretically demonstrate compliance with the GSPRs without following IEC 62366-1, but this requires alternative evidence and is significantly harder to defend during a Notified Body audit. For FDA-regulated products, IEC 62366-1 is a recognized consensus standard. The FDA does not mandate specific standards, but manufacturers who declare conformity with recognized standards benefit from a streamlined review. FDA's human factors guidance documents set expectations that align closely with IEC 62366-1. In MDSAP-participating countries (United States, Canada, Australia, Brazil, Japan), usability engineering is audited as part of design control requirements, and IEC 62366-1 is the accepted benchmark. In practical terms, IEC 62366-1 is the de facto global standard for medical device usability engineering, and deviating from it creates unnecessary regulatory risk.

What about legacy or predicate devices?

Devices that were designed and marketed before the manufacturer implemented IEC 62366-1 — often called legacy devices — are not exempt from usability engineering requirements. However, the standard provides pragmatic mechanisms to address them. The UOUP (User Interface of Unknown Provenance) process defined in IEC 62366-1 clause 5.10 and Annex C allows manufacturers to evaluate legacy user interfaces using a simplified, evidence-based approach rather than conducting a full retrospective usability engineering process. For predicate devices in the FDA context, the known use problems with the predicate should be documented and addressed in the new device's use-related risk analysis. If the new device uses the same user interface as the predicate, the manufacturer should gather evidence from complaint data, adverse event reports, and published literature to evaluate whether the legacy interface is acceptably safe. If evidence suggests use problems, targeted usability evaluations should be conducted to identify specific design improvements.

How does IEC 62366-1 relate to AAMI HE75?

IEC 62366-1 and AAMI HE75 are complementary but fundamentally different documents. IEC 62366-1 is a process standard — it defines what usability engineering activities the manufacturer must perform (use specification, risk analysis, formative evaluation, summative evaluation). AAMI HE75 is a design reference — it provides detailed, evidence-based guidance on how to design specific user interface elements (display design, control design, alarm design, labeling, physical ergonomics). Think of IEC 62366-1 as the playbook that tells you which activities to execute, and AAMI HE75 as the reference library that informs your specific design decisions within those activities. Both are recognized by the FDA as consensus standards. The most effective approach is to use them together: follow IEC 62366-1 for the process framework, and consult AAMI HE75 for specific design parameters and evidence-based recommendations when making UI design decisions.

Can usability testing be done remotely?

Remote usability testing is acceptable for formative evaluations, particularly for software-based medical devices (SaMD) and devices with software-driven user interfaces. Screen sharing, video conferencing, and remote observation tools can effectively capture usability data for software interactions. Remote testing offers practical advantages: easier recruitment of geographically distributed participants, lower logistic costs, and the ability to conduct rapid iterative testing.

However, remote testing has significant limitations for summative evaluation, especially for physical devices. Summative evaluations require simulation of the intended use environment (lighting, noise, distractions, protective equipment), observation of physical interactions with the device (grip, force, manipulation), and the ability to detect subtle use difficulties that may not be visible on a video feed. For these reasons, summative evaluations for physical medical devices should generally be conducted in person, in a controlled simulation environment. For purely software-based devices where the only user interface is a screen-based application, remote summative testing may be defensible if the manufacturer can demonstrate that the remote testing conditions adequately replicate the intended use environment and that all critical observations can be captured remotely. Document the rationale for remote testing and any limitations in the study report.

What is the Usability Engineering File?

The Usability Engineering File (UEF) is the comprehensive documentation package that records the manufacturer's application of the usability engineering process as defined by IEC 62366-1. It is the usability equivalent of the risk management file under ISO 14971. The UEF is not a single document but rather a collection of documents, records, and references that together provide a complete, traceable record of how usability was addressed throughout the device lifecycle. Required contents include: the use specification, user research records, use-related risk analysis, user interface specification, UI design documentation, formative evaluation records, summative evaluation report, traceability matrices, and post-market usability data. The UEF must be a self-contained, auditable record — an auditor should be able to trace the full logic chain from user needs through risk identification, design decisions, evaluation results, and residual risk assessment without needing to search through other parts of the quality system. The UEF is maintained as a living document throughout the product lifecycle.

Do I need usability testing for a Class I device?

IEC 62366-1 applies to all medical devices regardless of classification. However, the standard and regulatory guidance recognize that the depth of usability engineering should be proportionate to the use-related risk, not simply the device classification. A Class I device with a simple user interface and minimal potential for use errors that could cause harm (e.g., a tongue depressor, a simple bandage) would require a less extensive usability engineering program than a Class I device with a more complex interface or safety-critical user interactions. The key question is not the classification but whether use errors could result in harm. If they could, usability engineering is needed. For low-risk Class I devices, the usability engineering process may be appropriately scaled: a documented use specification, a brief use-related risk analysis confirming minimal use-related risks, and a rationale for why formal usability testing is not warranted may be sufficient. For Class I devices with more significant user interaction (e.g., powered surgical instruments classified as Class I in some jurisdictions), formative evaluation and potentially summative evaluation may be needed. Document the rationale for the level of usability engineering effort, tied to the use-related risk analysis.

What is a critical task?

A critical task, as defined in FDA human factors guidance, is a user task associated with use scenarios where a use error or use difficulty could result in serious harm to the patient, user, or bystander, or where a use error could result in failure to achieve the device's intended clinical benefit. Critical tasks are the highest-priority focus of the usability engineering process — they must be included in the summative evaluation, and risk controls for use errors on critical tasks receive the most rigorous scrutiny from FDA reviewers.

Examples of critical tasks include: setting a drug dose on an infusion pump, interpreting a diagnostic result, activating a defibrillator, connecting a ventilator circuit, self-injecting with an auto-injector, and responding to a critical alarm. The identification of critical tasks is derived from the use-related risk analysis: any task where a use error could lead to a hazardous situation with serious severity is a candidate for classification as a critical task. FDA expects manufacturers to identify all critical tasks and to test every one of them in the summative evaluation. IEC 62366-1 uses slightly different terminology ("primary operating functions" and tasks associated with "use-related hazardous situations") but the underlying concept is the same — focus your most rigorous usability engineering attention on the tasks where the consequences of use error are most severe.