IEC 62366: Usability Engineering Process, File and Evidence

Introduction

IEC 62366 is built on one uncomfortable idea: a patient can be seriously harmed while every component of the device performs exactly as specified. The infusion pump delivered precisely the dose that was programmed into it; the problem is that the nurse programmed 10 mL/h when she meant 1.0, because the keypad accepted the entry without a confirmation step and the display rendered both values in the same visual weight. No circuit failed, no software crashed, no specification was violated — and the standard that owns this category of harm is not your ISO 14971 risk management process alone, and it is certainly not IEC 62304, which stops at verifying that the software does what the specification says.

This guide covers what IEC 62366-1:2015+AMD1:2020 actually requires and how it is enforced: the vocabulary that defines its scope, its position under the EU MDR and in FDA submissions after the May 2026 final guidance, the ten steps of clause 5 and the documents each one produces, the boundary between use error and abnormal use, formative and summative evaluation, user interfaces of unknown provenance, and the six gaps that reviewers find in usability engineering files more often than any others.

Table of Contents

• Why IEC 62366 exists: the hazard that needs no fault
• The European position: state of the art without presumption of conformity
• The FDA layer: two guidances, one process
• The 2016 process guidance
• The May 2026 submission guidance
• The process clause by clause: each output is the next input
• The usability engineering file is the deliverable
• Use error or abnormal use: the boundary that decides what you owe
• Formative and summative evaluation: cheap findings and expensive ones
• Formative: findings that can still change the design
• Summative: evidence, not exploration
• UOUP: the clause that saves legacy interfaces, with conditions
• The six gaps reviewers find first
• Frequently asked questions
• Conclusions

Why IEC 62366 exists: the hazard that needs no fault

Risk management as most engineering teams practise it is organised around failure. A component drifts, a weld cracks, a routine returns the wrong value — something in the device departs from its specification, and harm follows. The analytical machinery of fault trees and FMEAs is built for exactly this, and it is blind to the category of harm that IEC 62366 addresses: the device does everything it was designed to do, and a foreseeable human interaction with it still puts someone in a hazardous situation.

The standard's vocabulary is engineered to keep that category visible. The term is use error, deliberately not "user error": a user action, or the absence of one, that leads to a result different from what the manufacturer intended or the user expected. The renaming is not diplomatic softening. Calling it user error assigns the cause to the person and closes the investigation; calling it use error assigns the cause to the interaction between the user interface and a foreseeable user, which is something the manufacturer designed and can redesign. Slips, lapses and mistakes by a competent, attentive user are use errors. They are inside the scope of the standard, and the manufacturer owes analysis and, where the risk warrants it, design changes for every one of them that is foreseeable.

Normal use is the standard's scope boundary in the other direction: operation, including correct use and use error, that is in accordance with the accompanying documentation or with commonly accepted practice. What falls outside normal use is abnormal use — a conscious, intentional violation of the intended operation, the contraindicated shortcut a user takes knowing it is a shortcut. Abnormal use is excluded from the usability engineering process, but not from your obligations: it goes back to ISO 14971 as a risk to be considered, and the classification of a real-world event as abnormal use has to survive scrutiny. A workaround that half the user population performs because the intended workflow is impractical is not abnormal use; it is evidence that the use specification was wrong.

The 2020 amendment — the current consolidated edition is IEC 62366-1:2015+AMD1:2020 — sharpened exactly these definitions and their supporting figures, and left the clause numbering untouched. A file written against the 2015 clause structure does not need renumbering; it needs its vocabulary checked against the amended definitions, which is a smaller job and a more common gap.

The European position: state of the art without presumption of conformity

The EU MDR never names IEC 62366. What it does is state outcomes in Annex I that cannot be demonstrated without a usability engineering process. GSPR 5 requires manufacturers to eliminate or reduce as far as possible the risks related to use error, to reduce risks related to the ergonomic features of the device and the environment in which it is intended to be used, and to give consideration to the technical knowledge, experience, education and training of intended users. GSPR 22 extends this for devices intended for lay persons, who cannot be assumed to have any of those things. These are general safety and performance requirements like any others: they must be addressed in the technical documentation, and the demonstration must rest on evidence, not assertion.

The uncomfortable part is the harmonisation status. EN 62366-1:2015+A1:2020 exists as a European standard, and the Commission's standardisation request listed it for adoption under the MDR — but as of this writing it has not been cited in the Official Journal under Regulation (EU) 2017/745. The implementing decisions that updated the MDR harmonised standards list through 2026 added biological evaluation standards, symbols, electrical safety and other families; usability is not among them. The practical consequence: applying IEC 62366-1:2015+AMD1:2020 gives you no formal presumption of conformity under Article 8 of the MDR. What it gives you is the state of the art, which is what Annex I actually demands — and no Notified Body reviewer will accept a technical file that addresses GSPR 5 through some process other than the one this standard describes, unless that process is demonstrably equivalent, which is a harder argument than simply applying the standard.

For medical electrical equipment there is a second route into the same obligation. IEC 60601-1-6, the usability collateral to IEC 60601-1, is essentially a bridge document: it takes the general standard's requirements and discharges them by pointing at IEC 62366-1. A manufacturer testing against the 60601 series arrives at the same process from a different door.

Do not confuse "not harmonised" with "optional". The MDR requirement is the outcome — use-error risk reduced as far as possible. The standard is the only generally recognised way to demonstrate that outcome, and the absence of an OJ citation changes the legal mechanics of the claim, not the expectation of the reviewer reading your file.

The FDA layer: two guidances, one process

The United States does not adopt IEC 62366-1 as a legal requirement either, but FDA recognises the standard and has built its human factors expectations on the same skeleton. Since mid-2026 the US framework rests on two documents that divide the work cleanly between them: how to run the process, and what to submit.

The 2016 process guidance

"Applying Human Factors and Usability Engineering to Medical Devices", final since February 2016, is the process document, and it states several things the IEC standard deliberately does not. It defines critical tasks — tasks where a use error would or could cause serious harm — as the organising unit of validation. It sets the number the industry has memorised: a minimum of fifteen participants per distinct user population in human factors validation testing. And it constrains the conditions: validation is run with the final or production-equivalent user interface, participants representative of actual users, training that reflects what real users will actually receive — including the realistic decay of that training over time, which is why "we trained the participants immediately before the test" is a finding, not a method.

The May 2026 submission guidance

On 29 May 2026 FDA issued the final guidance "Content of Human Factors Information in Medical Device Marketing Submissions", replacing the December 2022 draft and answering the question the 2016 document left open: which submissions need what. It establishes a risk-based framework with three Human Factors Submission Categories, from a brief rationale with no validation data up to a full human factors engineering report, and adds a decision point specifically addressing whether validation testing data belongs in the submission at all. Two operational details matter for planning. The eSTAR submission templates prompt for the HF Submission Category from 1 August 2026, so the categorisation is no longer an internal judgement you can defer — it is a field in the submission. And the guidance notes that human factors information should be maintained by the manufacturer regardless of whether it is submitted, which quietly relocates the enforcement of the weaker categories from premarket review to QMSR inspection. Category 1 is not an exemption from the work; it is an exemption from showing the work in advance.

For a manufacturer serving both markets, the efficient reading is that FDA's expectations sit on top of the IEC process rather than beside it. Run clause 5 of IEC 62366-1 as written, carry the FDA layer — critical tasks, the fifteen-participant minimum, the training and labelling rules, the submission category logic — wherever the guidance states something the standard does not, and one usability engineering file serves both. Running two parallel processes produces two half-maintained files and reviewers on both sides asking why they disagree.

The process clause by clause: each output is the next input

Clause 5 of IEC 62366-1 is ten numbered steps, and the single most useful thing to understand about them is that they are not a checklist — they are a chain. Each step names the outputs of previous steps as its inputs. The use specification of 5.1 feeds the identification of user interface characteristics and potential use errors in 5.2. Both feed the identification of hazards and hazardous situations in 5.3, alongside the ISO 14971 risk analysis. Those become hazard-related use scenarios in 5.4, from which 5.5 selects the set that summative evaluation will test. The user interface specification of 5.6 exists to control the scenarios; the evaluation plan of 5.7 exists to test the specification; 5.8 iterates design and formative evaluation; 5.9 runs the summative evaluation against exactly the scenarios 5.5 selected; and 5.10 handles user interface elements of unknown provenance.

The chain structure has a consequence that manufacturers discover late and auditors exploit early: a defect propagates forward silently. If the use specification names one average user where the device actually has four distinct user populations — say, ICU nurses, home caregivers, paediatric patients and biomedical technicians — then the task analysis in 5.2 is incomplete, the hazardous situations in 5.3 are missing entire exposure pathways, the scenarios in 5.4 do not exist for the missing populations, the selection in 5.5 cannot select what was never generated, and the summative evaluation in 5.9 is run competently against the wrong set. Every downstream document is internally consistent and externally wrong. This is why remediation of a usability file almost never starts where the finding was raised; it starts at the earliest step whose output was defective, and everything downstream of it is reopened.

The other structural fact worth internalising is how the standard is enforced. Every requirement in IEC 62366-1 is verified the same way: by inspection of the usability engineering file. Not one clause is checked by interviewing the team, observing the work or testing the device directly. The standard says what must be recorded and where; conformity is the record. That makes the file the actual deliverable of the process, and it makes gaps in the file cheap for a reviewer to find and expensive for you to have missed — because a missing record is indistinguishable, from the reviewer's side of the table, from work that was never done.

The usability engineering file is the deliverable

Clause 4.2 requires the usability engineering file, and permits it to be an index — the results can live in your design history file, your risk management file, your EU MDR technical documentation, wherever your document architecture puts them, provided the file tells a reviewer where each required result is. In practice, the index model is what keeps the file maintainable: a duplicated file diverges from its sources within two design changes, and a diverged file is worse than a missing one, because it is evidence that contradicts your other evidence.

What must be findable through the file is specific, clause by clause. The table below is the inspection view: the deliverable each step produces, and what a competent reviewer — Notified Body auditor, FDA reviewer, or the internal auditor you should be sending in first — checks it against.

Two rows of this table do disproportionate work in reviews. The use specification of 5.1 must characterise every distinct user population, the use environments with their real conditions — lighting, noise, interruptions, gloves, the 3 a.m. shift — and the operating principle of the device. The temptation to write it for a single idealised user is strong because it makes every downstream document shorter, and it is the single most damaging economy in the whole process. And 5.3 requires hazardous situations, not hazards: not "electrical energy" but the circumstance in which a foreseeable user, performing a foreseeable task, is exposed to it. Files that record bare hazard lists have skipped the analytical step the clause exists for, and the gap surfaces two steps later when the use scenarios have no situations to be related to.

Use error or abnormal use: the boundary that decides what you owe

Every observed user action — in a formative session, in the summative evaluation, or in a post-market complaint — lands somewhere in a small classification tree, and where it lands decides what the manufacturer owes. Inside the accompanying documentation or commonly accepted practice, it is normal use. Within normal use, if the result was what the manufacturer intended and the user expected, it is correct use and requires nothing further. If the result diverged, it is a use error, it enters the analysis at 5.2, and it may generate a hazard-related use scenario with everything that follows from one. Only actions outside normal use altogether — conscious, intentional violations of the intended operation — are abnormal use and exit the usability engineering process, while remaining a consideration for risk management.

The tree looks trivial until you try to apply it under commercial pressure, because every incentive points toward the abnormal-use branch. Classifying a field event as abnormal use closes the usability question; classifying it as use error opens a design question with a potential CAPA and, in the worst case, a design change on a certified device. The test that keeps the classification honest is foreseeability and intent, judged from evidence rather than hope. A nurse silencing an alarm because the device alarms constantly for clinically irrelevant conditions has not committed abnormal use; she has responded foreseeably to an interface that trained her to ignore it, and alarm fatigue is a use-error mechanism the file must address. The reviewer reading your complaint-handling records will apply exactly this logic, and a pattern of events classified as abnormal use with no supporting evidence of intent reads as a manufacturer avoiding its own data.

The same boundary does quiet work in the risk file. Because a use error requires no device fault, the probability side of use-related risk estimation cannot lean on component failure rates — and the standard's own position, shared with the FDA guidance, is that the probability of a use error is generally not quantifiable in any defensible way. Use-related risk is therefore driven by severity, which is why 5.5 selects scenarios for summative evaluation by the severity of the potential harm, not by any estimate of likelihood. If your benefit-risk analysis discounts use-related risks by an invented probability, a reviewer will strike the discount.

Formative and summative evaluation: cheap findings and expensive ones

The standard requires two kinds of evaluation, and the difference between them is not rigour or sample size. It is what a finding costs when it arrives.

Formative: findings that can still change the design

Formative evaluation, planned in 5.7 and performed through 5.8, runs while the design can still absorb what it learns. Methods are flexible — cognitive walkthroughs, simulated-use sessions with early prototypes, heuristic reviews, five users around a foam model — and the output is a design change, recorded with the finding that produced it. A file with no formative record is announcing that the first time real users met the interface was the summative evaluation, at which point every finding is a finding against a frozen design. The absurdity of skipping formative work is that it is the cheap part: a formative round costs days and changes the design; a failed summative costs a redesign, a repeated study, and a delayed submission.

Summative: evidence, not exploration

Summative evaluation under 5.9 is a different instrument. It is run on the final or production-equivalent user interface, under conditions of use realistic enough to carry the conclusion, against the hazard-related use scenarios selected in 5.5 — and its purpose is not to discover problems but to demonstrate, with objective evidence, that the interface can be used safely by the intended users in the intended environment. For the US market, the 2016 guidance sets the fifteen-participant minimum per distinct user population and the rules on training and labelling during the test. Every use error, close call and difficulty observed is analysed for its relationship to the interface design, and the residual risk that remains flows into the overall benefit-risk determination. What summative evaluation is not, in either framework, is a validation of the scenario set itself: it evaluates what 5.5 selected, and if the selection was built on a defective use specification, the study will be run correctly against the wrong scenarios — the most expensive way to discover a gap that a one-day review of the file would have found a year earlier.

UOUP: the clause that saves legacy interfaces, with conditions

Clause 5.10 and Annex C address the situation every established manufacturer is in: a device whose user interface, or part of it, predates the current process — a user interface of unknown provenance. Rerunning the full clause 5 chain on an interface that has been in the field for a decade would be both enormous and, in one specific sense, wasteful: the field history is itself evidence. The UOUP route lets the manufacturer rely on that evidence — post-market data, complaint history, known use errors — in place of parts of the prospective process, for the unmodified portions of the interface.

The conditions are where files fail. The rationale has to be documented: which interface elements are UOUP, what the boundary is between them and anything new or modified, and what the post-market evidence actually shows. Anything modified is not UOUP — the modification and its interactions with the inherited elements go through the full process. And the post-market evidence has to be examined honestly, because a complaint history containing use-error patterns is not a free pass; it is an input to 5.3 that the manufacturer is now on record as possessing. This matters acutely for software devices, where interfaces are rebuilt far more often than hardware: a reskinned UI on a software as a medical device product is a modified interface, and claiming UOUP over it because the underlying workflow "is the same" is the kind of argument that survives exactly until a reviewer opens both versions side by side.

The six gaps reviewers find first

Usability engineering files fail in patterns. The six below account for most of the findings raised against them in Notified Body reviews, FDA deficiency letters and internal audits — and because of the chain structure of clause 5, the two critical ones sit at the top of the process, where they contaminate everything downstream.

The pattern behind the pattern is worth stating. Almost none of these gaps come from teams that lack usability expertise; they come from teams that read the standard as a set of parallel obligations rather than a sequence of dependencies, satisfied each clause locally, and never checked that each document actually consumes the outputs the previous one produced. The single most effective internal control is correspondingly simple: before the summative evaluation is scheduled, one competent person reads the file end to end, following each named input backward, and writes down every place the chain breaks. It is a one-day exercise, and it is the difference between finding the broken link yourself and paying a test laboratory to demonstrate it for you.

Frequently asked questions

Is IEC 62366-1 mandatory for CE marking?

The standard itself is not legally mandatory, and it is not currently cited in the Official Journal under the MDR, so it carries no presumption of conformity. What is mandatory is the outcome: Annex I of the MDR requires use-error risk to be eliminated or reduced as far as possible. Applying IEC 62366-1 is the recognised state-of-the-art way to demonstrate that outcome, and Notified Bodies review usability evidence against its process in practice.

What is the difference between IEC 62366-1 and IEC 62366-2?

IEC 62366-1 is the normative standard: it contains the requirements, focused on safety, and is the document conformity is claimed against. IEC TR 62366-2 is a technical report — guidance on applying the process, extending also to usability goals beyond safety. You comply with part 1; you consult part 2.

What is the difference between use error and abnormal use?

A use error is a foreseeable action, or omission, within normal use that produces a result the manufacturer did not intend or the user did not expect — slips, lapses and mistakes included. It stays inside the usability engineering process. Abnormal use is a conscious, intentional violation of the intended operation. It exits the usability process but remains a consideration for risk management, and classifying an event as abnormal use requires evidence of intent, not convenience.

How many participants are required for summative usability testing?

IEC 62366-1 does not set a number. The FDA 2016 human factors guidance sets the figure used in practice for the US market: a minimum of fifteen participants per distinct user population in human factors validation testing. A device with three distinct user populations therefore needs at least forty-five participants, which is one more reason the use specification has to get the populations right at the start.

Which edition of IEC 62366-1 is current?

IEC 62366-1:2015 as amended by AMD1:2020 — the consolidated edition 1.1. The amendment clarified definitions and figures without changing the clause numbering, so files written against the 2015 structure remain structurally valid but should be checked against the amended definitions. The European adoption is EN 62366-1:2015+A1:2020.

What is a user interface of unknown provenance (UOUP)?

A user interface, or part of one, that was designed before the current usability engineering process existed and for which full prospective records are unavailable. Clause 5.10 and Annex C allow the manufacturer to rely on post-market evidence for the unmodified elements instead of rerunning the full process, provided the rationale, the boundary of what counts as unmodified, and the supporting field data are documented in the file.

What is the difference between formative and summative evaluation?

Formative evaluation runs during design, with flexible methods, and exists to find and fix problems while the design can still change. Summative evaluation runs on the final or production-equivalent interface, against the hazard-related use scenarios selected under clause 5.5, and exists to generate objective evidence of safe use. Formative findings are cheap; summative findings arrive against a frozen design and are the expensive kind.

Conclusions

IEC 62366-1 is a short standard with one original idea and one enforcement mechanism. The idea is that a hazardous situation needs no fault: a device performing exactly to specification can still put a foreseeable user in harm's way, and the manufacturer owns that interaction because the manufacturer designed the interface that shapes it. The enforcement mechanism is the usability engineering file, because every clause is verified by inspecting it — which makes the file the real deliverable, and makes the chain of documents inside it the thing to get right.

The practical discipline follows from the structure. Get the use specification right first, because every defect in it propagates silently through nine downstream steps. Record hazardous situations, not hazard lists. Select summative scenarios by severity and justify the exclusions. Run formative evaluation early enough for its findings to be cheap. And before anyone books a summative study, have one person read the file end to end following the named inputs backward — the one-day exercise that finds what the test laboratory would otherwise be paid to demonstrate.

If you want the whole process taught in the order the standard builds it, clause by clause and with the FDA layer alongside, the IEC 62366-1 usability engineering course covers all ten steps in thirteen modules, with a workbook that runs a gap analysis on your own file.

Related articles

• IEC 62304: The Complete Guide to Medical Device Software Lifecycle
• ISO 14971 Risk Management for Medical Devices
• Benefit-Risk Analysis for Medical Devices
• Software as a Medical Device (SaMD)