Maps to
QMSR / ISO 13485: §820.30(b) Design and development planning.
ISO 13485: §7.3.2 Design and development planning
IEC 62366: §4.1.1 USABILITY ENGINEERING PROCESS
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.
Amendment 1 (2020) refined the standard without making fundamental process changes: it updated the normative reference from ISO 14971:2007 to ISO 14971:2019, aligned terminology (e.g., ISO 13485 reference updated to 2016 edition), added training explicitly as a permissible option alongside information for safety in the §4.1.2 risk-control priority hierarchy, introduced the concept of 'use difficulty' (close calls and near-misses that do not result in an actual use error), added a normative §5.10 and Annex C pathway for evaluating a User Interface of Unknown Provenance (UOUP) — covering legacy, inherited, and third-party UI components — and replaced 'action error' with 'physical mismatch' in the use-error taxonomy. The consolidated edition is designated IEC 62366-1:2015+AMD1:2020 CSV.
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.1 requirements.