IEC 62366-1 Explained: The Usability Engineering Standard in Plain English

IEC 62366-1 is the international standard for applying usability engineering to medical devices. If your device sells in Europe, the US, or most major markets, it applies to you. The full title is dry. The consequences of getting it wrong are not: gaps in your usability engineering file are a common source of notified body findings and regulator questions.



This guide walks through what the standard actually asks for, without the committee language.

What IEC 62366-1 Covers (and What It Doesn't)

IEC 62366-1 defines a process for designing safe use of a device. It doesn't tell you what your interface should look like. It tells you how to identify use-related hazards, design against them, and prove you did.



The standard's scope is safety, not satisfaction. A device can be clunky and still conform, as long as use errors don't create unacceptable risk. (Your customers will care about clunky. The standard won't.)

Normal Use vs. Abnormal Use

One scope note that trips teams up: the current edition centers on use errors in normal use, including the predictable slips and mistakes real users make. A nurse who mis-keys a dose because two fields look identical is normal use. A user who tapes over an alarm because it annoys them has crossed into "abnormal use": deliberate disregard that sits largely outside the engineering controls the medical device standard requires, though it still feeds risk management.

The Usability Engineering Process, Step by Step

The standard lays out a sequence. In simplified terms:

1. Define the use specification - intended users, use environments, and the device's purpose.
2. Identify safety -related interface characteristics and known use problems with similar devices.
3. Identify hazard -related use scenarios, the moments where a use error could cause harm.
4. Select the scenarios for summative evaluation.
5. Define the user interface specification and design the interface.
6. Run formative evaluations as the design evolves.
7. Run the summative evaluation on the final design and document the results.
   

The sequence isn't strictly linear. Formative findings routinely send teams back to update the use specification or the hazard list, and the standard expects that loop.



If that arc looks familiar, it should. It's the same formative-then-summative rhythm FDA expects. The paperwork differs; the engineering logic doesn't. For a deeper look at how the two evaluation types divide the work, see our guide to formative vs. summative usability testing.

Everything the process produces lives in the usability engineering file: the use specification, risk-related analyses, evaluation protocols, results, and the rationale connecting them. It doesn't have to be one physical document; it has to be a traceable body of evidence.

In practice, the spine of a strong file is a traceability matrix. One axis lists the hazard-related use scenarios from your risk analysis; the other shows where each one was evaluated, what happened, and what changed as a result. When that matrix is complete, the rest of the file almost assembles itself. When it's missing, reviewers have to reconstruct your logic, and they rarely reconstruct it charitably.

What Reviewers Actually Look For

The most common gaps we see aren't missing studies. They're missing connections: a summative protocol that doesn't trace to the risk analysis, user groups in the use specification that never appear in testing, or design changes made after evaluation with no assessment of their impact.

IEC 62366-1 vs. FDA Guidance: Same Spirit, Different Paperwork

The standard and FDA's human factors guidance are philosophically aligned, and FDA recognizes IEC 62366-1 as a consensus standard. But conformity to the standard alone doesn't automatically satisfy FDA. The agency has its own expectations, like the 15-participants-per-user-group benchmark for validation and its specific view of critical tasks.

In Europe, the standard carries similar weight: notified bodies reviewing under the MDR expect to see a usability engineering process, and IEC 62366-1 is the recognized way to demonstrate one. The companion technical report, IEC/TR 62366-2, adds practical how-to guidance if your team wants more than the normative text.



Plan one program that satisfies both instead of running two parallel efforts. Our post on demystifying human factors validation unpacks the FDA side.

Where Teams Get Into Trouble

The pattern is consistent. The standard gets handed to regulatory affairs, who treat it as a documentation exercise. Usability work gets back-filled at the end to populate the file. Then the summative study surfaces a real design problem — at the most expensive possible moment.



What we always tell device teams is this: the file is the output of good usability engineering, not the substitute for it. Write-ups can be fixed in a week. Designs can't.

Building Conformance Without Building a Bureaucracy

The standard demands rigor. Nothing in it demands headcount. A small, well-run program with a clear use specification, honest formative rounds, and a traceable file conforms just as well as a sprawling one.

Scale the effort to the risk. A low-risk device with two user groups doesn't need the same program as an infusion pump used by nurses, patients, and caregivers across home and clinical settings.



As an industry leader in supporting research for regulated products, UX Firm helps device makers run that lean version of conformance: studies designed to satisfy IEC 62366-1 and FDA in a single program, with documentation that survives notified body scrutiny. It's the benefit of a boutique team that has produced the required research reports many times over, rather than learning on your timeline.

Conforming Is a Process, Not a Plaque

IEC 62366-1 rewards teams that do usability engineering continuously and document as they go. Start the file on day one, test early, and the summative study becomes the closing chapter of a story you've already written.



If your usability engineering file has gaps, or hasn't been started at all, reach out to UX Firm before your next regulatory milestone rather than after it.