# IEC 62366-1

The usability engineering standard for medical devices: use specification, use errors, formative and summative evaluation, and how assessors check it.

Source: https://sted.digital/docs/standards/iec-62366-1 · Last reviewed 17 October 2026 · Strand Standards and regulations

IEC 62366-1 is the international standard for usability engineering of medical devices: the process that shows people can use your device's user interface safely, from use specification to summative evaluation. Notified bodies, UK approved bodies and the US FDA expect it. It is not certifiable on its own: you show conformity inside your device's conformity assessment.

## What it is and who it applies to

The formal designation is IEC 62366-1:2015+AMD1:2020, *Medical devices, Part 1: Application of usability engineering to medical devices*, published by the International Electrotechnical Commission. The 2015 first edition replaced IEC 62366:2007, and Amendment 1 was published on 17 June 2020; the IEC sells both as consolidated edition 1.1. A companion technical report, IEC/TR 62366-2:2016, gives guidance and examples but sets no requirements.

The standard covers usability only as it relates to safety. Its question is whether a person can use the device as intended without a use error that leads to harm, not whether they enjoy it. Two terms carry the weight. A use error is an action, or a missed action, that produces a different result from the one the manufacturer intended or the user expected. Abnormal use is deliberate misuse beyond any reasonable risk control, which you record when you see it but do not have to design against.

It applies to every manufacturer of a medical device with a user interface. That includes software as a medical device, because a screen, an alert or a result display is a user interface, and it includes the labelling and instructions for use. It assumes you manage risk under ISO 14971: usability engineering is the part of risk management that deals with use.

This is guidance to help you understand the requirement, not legal advice.

## Structure

Clauses 1 to 3 set out the scope, references and definitions. Clause 4 sets the principles and clause 5 the process, in nine steps. The informative annexes give rationale, examples and the route for older interfaces. The table paraphrases each part.

| Clause | What it asks for, in plain English | Covered in |
|---|---|---|
| 4.1 | Run a usability engineering process, and reduce use-related risk through design before you rely on warnings or training | This page |
| 4.2 | Keep a usability engineering file that holds or points to every output of the process | This page |
| 4.3 | Scale the effort to the device, its user interface and the risks of using it | This page |
| 5.1 | Describe who uses the device, for what, on whom, where, and how it works | This page; [ISO 13485 design and development](/docs/standards/iso-13485/design-and-development) |
| 5.2 and 5.3 | Find the user interface features that affect safety, the use errors people could make, and the hazards and hazardous situations they could lead to | This page; [the risk assessment guide](/docs/guides/risk-assessment) |
| 5.4 and 5.5 | Describe the hazard-related use scenarios, and choose which of them the summative evaluation must cover | This page |
| 5.6 | Write the user interface specification, including its safety-related requirements | This page |
| 5.7 | Plan the evaluations, formative and summative, with their methods and acceptance criteria | This page |
| 5.8 | Design and build the interface, and test it formatively as you go | This page |
| 5.9 | Run the summative evaluation and analyse every use error and difficulty it finds | This page |
| Annex C | Evaluate a user interface that was not developed under this standard | This page |

### Formative and summative evaluation

Formative evaluation (IEC 62366-1:2015 5.8) runs during design. It is exploratory: a cognitive walkthrough of a wireframe, a session with five nurses and a paper prototype, an expert review of an alarm screen. Its job is to find use problems while they are cheap to fix.

Summative evaluation (IEC 62366-1:2015 5.9) runs at the end, on an interface that is equivalent to the one you will ship, with representative users doing the tasks in the hazard-related use scenarios you selected. Every use error, close call and difficulty is analysed for its root cause and its effect on risk. If the residual use-related risk is not acceptable, you go back to design and evaluate again.

### Older interfaces

Annex C gives a route for a user interface of unknown provenance: one developed before the standard, or outside it. You use the post-market information you already have, identify the hazard-related use scenarios, and decide whether the [residual risk](/docs/glossary/residual-risk) is acceptable, rather than repeating the whole process for an interface that has a field history. A change to that interface brings the changed part under the full process.

## Certification and enforcement

No accredited certification scheme exists for IEC 62366-1, and no certificate to it opens a market. Assessors read your usability engineering file as part of your device's conformity assessment.

### In the EU

The [EU MDR](/docs/standards/eu-mdr) asks manufacturers to reduce, as far as possible, the risks of use error from the device's ergonomic features and its use environment, and to consider the knowledge, training and condition of the intended users (EU MDR Annex I, section 5). Further sections cover ergonomic displays and devices for lay users. A usability engineering file built to IEC 62366-1 is the usual evidence for those requirements, and it sits in the technical documentation a notified body reviews.

As at the amendment of 11 June 2026, EN 62366-1 was not among the harmonised standards listed under Regulation (EU) 2017/745 in Implementing Decision (EU) 2021/1182, so following it gives no automatic presumption of conformity. Notified bodies treat it as the state of the art all the same: expect to show conformity with it or justify an equivalent.

The device's class under [EU MDR Annex VIII](/docs/standards/eu-mdr/classification) sets who checks the file. A notified body reviews technical documentation for class IIa, IIb and III devices; a Class I device without a measuring, sterile or reusable surgical function is self-declared, and the file still has to exist.

### In Great Britain and the US

In Great Britain, EN 62366-1:2015 with its 2020 amendment has been a designated standard under [UK MDR 2002](/docs/standards/uk-mdr-2002) since 17 January 2026, replacing the older EN 62366:2008. Designation gives a presumption of conformity with the essential requirements the standard covers. The MHRA also publishes guidance on applying human factors and usability engineering to medical devices.

In the US, the FDA lists the amended IEC 62366-1 among its recognised consensus standards. Its human factors guidance is the counterpart text, and it expects a human factors validation test, the FDA's name for a summative evaluation, for devices with critical tasks.

The usual findings are a summative study run on a prototype rather than a production-equivalent interface, participants who do not match the use specification, and use errors recorded without a root-cause analysis. Each one delays the certificate until it is closed.

## How the pieces fit

The process starts from the use specification (IEC 62366-1:2015 5.1): who uses the device, where and for what. From it you find the user interface characteristics that matter for safety and the use errors people could make (IEC 62366-1:2015 5.2), and the hazards and hazardous situations those errors could cause (IEC 62366-1:2015 5.3). These become hazard-related use scenarios (IEC 62366-1:2015 5.4), and you select the ones the summative evaluation must cover (IEC 62366-1:2015 5.5).

![A sequence of eight steps: use specification (5.1), user interface characteristics and use errors (5.2), hazards and hazardous situations (5.3), hazard-related use scenarios selected for summative evaluation (5.4 and 5.5, highlighted), user interface specification (5.6), evaluation plan (5.7), design and formative evaluation (5.8) and summative evaluation (5.9), with a dashed line from summative evaluation back to the user interface specification, and the usability engineering file (4.2) underneath holding every output.](/images/docs/iec-62366-1-loop.svg)

The scenarios drive the rest. The user interface specification (IEC 62366-1:2015 5.6) turns them into design requirements, the evaluation plan (IEC 62366-1:2015 5.7) says how you will test them, design and formative evaluation iterate until the interface looks right, and the summative evaluation proves it. A summative result with unacceptable residual risk sends you back to the specification. The usability engineering file (IEC 62366-1:2015 4.2) holds every output, and it links into the risk management file because each use error is also a risk.

An assessor follows one thread: a hazard-related use scenario, the design requirement it produced, the formative finding that changed the design, and the summative task that showed the change worked.

## In this section

IEC 62366-1 is covered on this page; it has no sub-pages. The topics it depends on and feeds into have their own pages:

- [IEC 62304](/docs/standards/iec-62304): how do you plan, build, test and maintain the software behind the interface?
- [ISO 13485 design and development](/docs/standards/iso-13485/design-and-development): how do design inputs, verification and validation work for the device as a whole?
- [ISO 13485 quality management system](/docs/standards/iso-13485/quality-management-system): what quality system must your usability process sit inside?
- [EU MDR classification](/docs/standards/eu-mdr/classification): what class is your device, and who will review the usability file?
- [EU MDR technical documentation](/docs/standards/eu-mdr/technical-documentation): where does the usability engineering file go in the file a notified body reviews?
- [UKCA marking under UK MDR 2002](/docs/standards/uk-mdr-2002/ukca-marking): how does the same evidence support a UKCA mark in Great Britain?

## How Sted maps it

IEC 62366-1 is one of the standards, regulations and schemes in Sted's catalogue.

Sted treats it as mandatory when a product with a user interface carries design responsibility under a device regulation that applies to you, or when a clinical investigation is planned or running. It is committed when you already keep a usability engineering file, and while the device regulation is still pending, so is IEC 62366-1. Those rules work from your recorded answers; the AI model does not decide them.

Sted recommends it with its reasons, and you select it or leave it. Administrators and Policy and Process Owners make that choice. Choosing it and pressing **Update and generate framework** builds the documents it needs.

For IEC 62366-1 Sted's knowledge base carries the Usability Engineering Procedure (PRC-UEP) and the Enhanced Summative Evaluation Procedure (PRC-ESE), with record templates from the Use Specification and User Interface Specification (REC-USUI) and the Use Error and Hazard Analysis (REC-UEHA) to the Summative Evaluation Plan (REC-SEP) and Summative Evaluation Report (REC-SER). The procedures are drafted for your organisation for you to review and approve, and each [record template](/docs/glossary/record-template) gives your [evidence](/docs/glossary/evidence) a fixed shape. The Usability Engineering File (REC-UEF) comes with a suggested annual review, scheduled only once you pick a first due date. See [Records](/docs/product/records), [Documents](/docs/product/documents) and [Classification and applicability](/docs/product/classification-and-applicability) for how they work in StedOS.

Sted does not run your evaluations, recruit participants or judge whether residual risk is acceptable. It holds the procedures, plans, file and results as [documented information](/docs/glossary/documented-information) in your [quality management system](/docs/glossary/qms), under your own [document control](/docs/guides/document-control).

For IEC 62366-1 Sted's knowledge base carries three procedures, the Usability Engineering Procedure (PRC-UEP), Enhanced Summative Evaluation Procedure (PRC-ESE) and Software Development Lifecycle Procedure (PRC-SDLP), and 11 record templates: the Usability Engineering File (REC-UEF, suggested annual review), Use Specification and User Interface Specification (REC-USUI), Use Error and Hazard Analysis (REC-UEHA), Formative Evaluation Plan and Report (REC-FEPR), Summative Evaluation Plan (REC-SEP), Summative Evaluation Report (REC-SER), Human Factors Engineering Report (REC-HFE), Enhanced Summative Evaluation Requirement Review (REC-ESER), Summative Re-evaluation Record (REC-SRE), Software Requirements Specification (REC-SRS) and Verification and Validation Plan (REC-VVP), with a six-row process catalogue.
33 periodic record types come with a suggested frequency, but nothing is scheduled until you pick a first due date.

Sted does not run formative or summative evaluations or recruit participants. It holds the plans, the usability engineering file and the results you record.

## Frequently asked questions

Q: Do I need a summative evaluation for a Class I device?
A: Usually, yes. IEC 62366-1 scales the effort to the risk of use errors, not to the regulatory class, so a Class I device whose misuse could harm someone still needs summative evidence for its hazard-related use scenarios. What can shrink is the size of the study, not the need for one.

Q: What is the difference between formative and summative evaluation?
A: Formative evaluation happens while you design, to find use problems early and cheaply; it can be informal, with a few users or an expert review. Summative evaluation happens at the end, on a production-equivalent interface with representative users, and produces the objective evidence that the interface can be used safely. Only the summative results close the file.

Q: Does IEC 62366-1 apply to software with no physical device?
A: Yes. A screen, a workflow, an alert or a result display is a user interface, and so are the instructions for use. Software as a medical device needs the same use specification, use-error analysis and summative evaluation as a hardware device, and it often has more hazard-related use scenarios because of how much it displays.

Q: How many participants does a summative evaluation need?
A: IEC 62366-1 sets no number. The FDA's human factors guidance recommends at least 15 participants from each distinct user group, and many manufacturers use that figure for every market so one study serves both. Each group you name in the use specification, such as nurses, patients or carers, counts separately.

Q: What is a user interface of unknown provenance?
A: It is a user interface, or part of one, that was not developed under IEC 62366-1, typically on a device already on the market. Annex C gives a shorter route for it: use the post-market information you have, identify the hazard-related use scenarios, and evaluate the residual risk instead of re-running the whole process.

Q: Is IEC 62366-1 a harmonised standard under EU MDR?
A: No. As at the amendment of 11 June 2026, the list of harmonised standards under Regulation (EU) 2017/745 did not include it. In Great Britain the amended edition has been a designated standard since 17 January 2026, which gives a presumption of conformity with the essential requirements it covers.