Maps to
QMSR / ISO 13485: §820.30(b)
ISO 13485: §7.3.2
IEC 62366: §4.1
Requirement text
The manufacturer shall establish, document, and maintain a usability engineering process that covers the entire device development lifecycle. The process must address user interface design, formative evaluation during development, and summative (validation) evaluation prior to release. Risk control activities related to the user interface must be integrated with the overall risk management process.
What changed
IEC 62366-1:2015 replaced the 2007 first edition with a major restructuring. The standard was split into Part 1 (normative requirements) and Part 2 (IEC TR 62366-2, informative guidance and methods). The scope broadened to include hazards of all types including psychological hazards, not just direct physical hazards.
The standard introduced a formative/summative evaluation framework not present in 2007. The 2007 requirement to identify primary operating functions was removed — instead, the 2015 version mandates identification and evaluation of hazard-related use scenarios. A concept of User Interface of Unknown Provenance (UOUP) was added, allowing simplified evaluation for legacy or off-the-shelf interfaces based on post-market data.
Amendment 1 (2020) further refined the standard: it updated the ISO 14971 reference to the 2019 edition, introduced bidirectional exchange between risk management and usability engineering (previously one-directional), added training as a third priority risk control measure alongside information for safety, introduced the concept of 'use difficulty' (close calls and observed problems that don't result in actual use errors), and replaced 'action error' with 'physical mismatch' to encourage broader analysis of use problems.
Atomic constraints
- •A documented usability engineering process must exist and be integrated into the device development process.
- •The process must cover user interface design activities, formative evaluations, and summative evaluation.
- •Risk control measures related to user interface design must be identified and linked to the risk management file.
- •Information for safety as it relates to usability (warnings, labeling) must be evaluated as part of the usability process.
- •The usability engineering process must be maintained throughout the device lifecycle.
Common gaps
Usability engineering disconnected from risk management
majorThe 2020 amendment requires bidirectional exchange between risk management (ISO 14971) and usability engineering. Auditors look for a direct link between use errors identified in the Usability File and hazards listed in the ISO 14971 Risk File. Many manufacturers run these as parallel but disconnected processes.
No documented usability engineering process
majorMany manufacturers, especially smaller companies, have no formal usability engineering process. They may perform some usability activities ad hoc but lack the documented process with defined activities, responsibilities, and deliverables that IEC 62366-1 requires. Usability is treated as optional UX polish rather than a safety-related regulatory requirement.
Evidence signals
- •
FILE_EXISTS
Usability.*Plan|Usability.*Evaluation|SOP.*Development|Software.*Development.*SOP
- •
CONTENT_MATCH
Does this document define a usability engineering process that includes user interface design, formative evaluation activities, summative evaluation requirements, and integration with risk management for UI-related hazards?
Audit defense
The Usability Engineering process for [your product] is defined in our Software Development SOP and Usability Evaluation Plan (Doc ID: [your document ID]). UI-related risk control measures are tracked in the Risk Table and verified through usability testing activities, fulfilling IEC 62366-1 section 4.1 requirements.