---
title: The Usability Engineering File: Complete Contents Checklist
description: Usability engineering file checklist MDR: every artifact required by EN 62366-1 clauses 5.1 to 5.9, mapped to MDR Annex I.
authors: Tibor Zechmeister, Felix Lenhard
category: Usability Under MDR
primary_keyword: usability engineering file checklist MDR
canonical_url: https://zechmeister-solutions.com/en/blog/usability-engineering-file-checklist
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# The Usability Engineering File: Complete Contents Checklist

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **The usability engineering file is the single audit-facing artefact that proves a medical device meets MDR Annex I §5, §22 and §23. EN 62366-1:2015+A1:2020 clauses 5.1 to 5.9 define exactly what it must contain: use specification, user groups, user interface specification, hazard-related use scenarios, use-related risk analysis, formative evaluation records, and the summative evaluation report. Anything missing is a finding.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- The usability engineering file (UE file) is the deliverable EN 62366-1:2015+A1:2020 requires manufacturers to compile and maintain throughout the lifecycle.
- Its structure is fixed by EN 62366-1 clauses 5.1 to 5.9, covering preparation, use specification, user interface specification, hazard-related use scenarios, risk analysis, formative evaluation, and summative evaluation.
- MDR Annex I §5 and §22 require manufacturers to reduce risks related to use error, which is why notified bodies open the UE file on every audit.
- Missing artefacts are the most common usability finding in Tibor's audit experience, and they almost always point to a missing use specification or an undocumented summative evaluation.
- The UE file is cross-referenced with the risk management file under EN ISO 14971:2019+A11:2021 and with the instructions for use under MDR Annex I §23.
- This checklist maps each EN 62366-1 clause to the artefact it requires so a startup team can self-assess before submission.

## Why the usability engineering file exists (Hook)

Tibor has opened hundreds of technical files during notified body audits. The one folder that reveals whether a startup understands usability engineering, or whether it bolted it on two weeks before submission, is the usability engineering file. A strong UE file reads like a narrative: who the users are, where they use the device, what could go wrong, how the team tested for it, and what evidence proves the device is safe. A weak UE file reads like a loose pile of PDFs.

The UE file is not optional paperwork. MDR Annex I §5 requires manufacturers to reduce risks related to use error. MDR Annex I §22 specifically addresses devices for lay users and demands that ergonomic features and the environment of use be considered. MDR Annex I §23 governs information supplied with the device and anchors IFU usability inside the same regime. EN 62366-1:2015+A1:2020 is the harmonised standard that gives manufacturers a presumption of conformity with these provisions. Its clause 5 sets out the usability engineering process, and every subclause generates an artefact that belongs in the file.

Felix has watched startups treat the UE file as a last-minute deliverable. That pattern ends one of two ways. Either the notified body rejects the submission and the team spends months reconstructing evidence that should have been captured during design, or the file passes on a technicality and the first summative-level problem surfaces after launch as a field safety notice. Neither outcome is survivable on a lean budget.

## What MDR and EN 62366-1 actually require (Surface)

MDR Annex I §5 states that manufacturers shall, in eliminating or reducing risks related to use error, reduce as far as possible the risks related to the ergonomic features of the device and the environment in which the device is intended to be used, as well as the technical knowledge, experience, education, training and, where applicable, the medical condition and physical condition of intended users. Annex I §22 extends these obligations for devices intended for lay users. Annex I §23 binds the same logic to labels and instructions for use.

EN 62366-1:2015+A1:2020 operationalises these obligations. Clause 5 defines the usability engineering process. Each subclause produces at least one record that belongs in the UE file.

- **Clause 5.1: Preparation of use specification.** Describes intended medical indication, patient populations, part of the body, user profile, use environment, and operating principle.
- **Clause 5.2: User interface characterisation and identification of hazard-related use scenarios.** Lists the frequently used functions and the functions related to safety. Identifies hazards and hazardous situations linked to use.
- **Clause 5.3: Hazard-related use scenarios selected for summative evaluation.** A defined subset of scenarios that will be tested to generate objective evidence of safety.
- **Clause 5.4: Establish user interface specification.** A written specification covering the UI, including labels, displays, alarms, controls, packaging and IFU.
- **Clause 5.5: Establish user interface evaluation plan.** The plan for how formative and summative evaluations will be conducted.
- **Clause 5.6: Perform user interface design, implementation and formative evaluation.** Documented iterative cycles of formative testing with design changes.
- **Clause 5.7: Perform summative evaluation of the usability of the user interface.** The decisive validation with recruited representative users in a real or simulated environment.
- **Clause 5.8: Usability engineering file (the compiled record).** The umbrella requirement that all of the above be compiled, maintained and traceable.
- **Clause 5.9: Evaluating user interface of unknown provenance.** Applies when legacy components are reused without a prior usability engineering process.

The use-related risk analysis referenced throughout clause 5 is the point where EN 62366-1 hands over to EN ISO 14971:2019+A11:2021. The two files must be internally consistent, and notified bodies cross-check them.

## A worked example: the left-handed display (Test)

One of Tibor's audit cases illustrates why the file structure matters. A startup developed a handheld device whose display was laid out by an engineering team dominated by left-handed developers. The design looked correct to everyone on the team. The use specification had been written without explicit decomposition of how right-handed users would hold the device, and the user interface specification described the display orientation as "optimised for handheld use" without defining which hand.

The formative evaluations were run internally, with engineers. No one flagged the orientation because the engineers held the device the same way the designers did. The summative evaluation, because the team recruited real representative users as EN 62366-1 clause 5.7 requires, exposed the problem immediately. Right-handed users received a display that was effectively upside down. The team shipped a software iteration letting the user flip orientation, documented the change through their risk management process, and updated the UE file. The fix was cheap because the failure surfaced in summative, not in the field.

What made the recovery possible was the file structure. Because each clause 5 artefact existed, the team could trace the gap to the use specification (hand dominance not decomposed), update it, regenerate the affected hazard-related use scenarios, revise the user interface specification, and re-run summative on the revised scenarios. Tibor has seen teams with no structured UE file fail to trace such an issue in under three months. The left-handed team closed it in weeks.

The bee-attracting mouthpiece case from Tibor's audit archive is the same lesson in a harsher form. A tongue-controlled wheelchair for quadriplegic patients had a mouthpiece colour chosen during indoor testing. The use specification did not decompose outdoor use. An auditor asked the obvious question. The chosen colour was exactly what attracts bees. A patient outdoors with the mouthpiece could be stung while unable to move. The team changed the colour and documented outdoor use scenarios. Without a granular use specification in the UE file, that hazard would not have surfaced until someone was hurt.

## The Subtract to Ship UE file checklist (Ship)

Felix's principle with the UE file is that the structure is non-negotiable but the depth is adjustable. A Class I self-certified device will have a shorter use specification than a Class IIb implantable, but both need every clause 5 artefact. Skipping artefacts is where startups get hurt. Keeping artefacts lean is where startups save time.

Use the following checklist. Every row must resolve to at least one signed, dated document in the UE file.

**Clause 5.1: Use specification.** Covers: intended medical indication, patient populations, intended part of the body or tissue interacted with, intended user profiles (including age, training, experience, physical and cognitive abilities), intended use environment, operating principle, and intended use of the device including critical tasks. Tibor's rule: decompose the use scenario into every real-world procedure including cleaning, transport, installation, normal operation, edge cases, and end of life. Granular decomposition is what makes hazards visible.

**Clause 5.2: User interface characterisation and hazard-related use scenarios identified.** Covers: frequently used functions, functions related to safety, identified hazards linked to use, identified hazardous situations, and a traceable list of hazard-related use scenarios. This list must be consistent with the risk management file under EN ISO 14971:2019+A11:2021.

**Clause 5.3: Hazard-related use scenarios selected for summative evaluation.** Covers: rationale for selection, the selected subset, and traceability back to clause 5.2.

**Clause 5.4: User interface specification.** Covers: specification of all UI elements including displays, controls, labels, alarms, packaging and the IFU. This document is where IEC 60601-1-8 alarm content belongs for devices with alarms, and where MDR Annex I §23 information supplied with the device is cross-referenced.

**Clause 5.5: User interface evaluation plan.** Covers: the plan for both formative and summative evaluations, including methods, environments, participant profiles, pass-fail criteria, data recording approach, and analysis plan.

**Clause 5.6: Formative evaluation records.** Covers: at least one iteration of formative evaluation, its findings, the design changes that resulted, and the rationale. Startups should capture every iteration, even small ones, because notified bodies look for evidence of iterative design.

**Clause 5.7: Summative evaluation report.** Covers: recruited representative users, real or simulated use environment, recorded observations, pass-fail outcomes against the user interface specification, and any residual use errors with justification and link to the risk management file.

**Clause 5.8: Compiled usability engineering file.** Covers: index, version control, traceability matrix, and cross-reference to the risk management file and to MDR Annex II technical documentation.

**Clause 5.9: User interface of unknown provenance (when applicable).** Covers: evaluation of legacy components reused without prior UE process, gap analysis and mitigation.

If a row resolves to nothing, the submission is not ready. If a row resolves to a document but the document is shorter than one page, it probably needs more detail.

## Reality Check

1. Does the use specification decompose every real-world procedure including cleaning, transport, installation, normal operation and edge cases, or only "intended use"?
2. Does the user profile capture age, training, experience, cognitive and physical abilities, including conditions like left or right hand dominance?
3. Is the list of hazard-related use scenarios traceable to the risk management file under EN ISO 14971:2019+A11:2021?
4. Does the user interface specification cover displays, controls, labels, alarms, packaging and the IFU, or only the digital UI?
5. Are there documented formative evaluation iterations with design changes, or was formative treated as a single internal review?
6. Was the summative evaluation run with recruited representative users in a real or simulated environment, with recorded observations, or was it run with engineers and friendly customers?
7. Is the UE file indexed and version-controlled as a single deliverable, or is it a loose collection of PDFs scattered across folders?
8. Has the compiled file been cross-referenced against MDR Annex II so that a notified body auditor can find each artefact without asking?

## Frequently Asked Questions

**Is a usability engineering file required for Class I devices?**
Yes. MDR Annex I §5 applies to all device classes. The depth of the file scales with risk and complexity, but every class needs the full set of clause 5 artefacts. Class I self-certified devices will typically have shorter documents, not fewer documents.

**Can a startup combine the use specification and the user interface specification into one document?**
EN 62366-1:2015+A1:2020 does not mandate physical separation, but combining them tends to blur the boundary between what the device is for (use specification) and what the UI must do (UI specification). Tibor's preference in audits is two distinct documents because it makes the traceability chain clearer.

**Where does the IFU sit inside the UE file?**
The IFU itself lives in the technical documentation under MDR Annex II. Inside the UE file, the IFU is referenced from the user interface specification and is tested as part of the summative evaluation. If users cannot complete critical tasks with the IFU alone, the IFU has failed its usability test.

**What is user interface of unknown provenance and does it apply to us?**
Clause 5.9 of EN 62366-1 covers user interfaces reused from legacy devices that were not developed under a formal usability engineering process. It applies when legacy components are integrated into a new device. If the startup is building a new UI from scratch, clause 5.9 does not apply.

**How detailed does the summative evaluation report need to be?**
The report must document recruited participant profiles, the use environment, the scenarios tested, the observations recorded, the pass-fail criteria from the user interface specification, and the resolution of any use errors found. Anything less and the notified body will request additional evidence.

**Can formative evaluation replace summative if the team runs many iterations?**
No. Formative and summative serve different purposes. Formative improves the design. Summative validates it. Clause 5.7 requires summative, and notified bodies will ask for it by name.

## Related reading

- [How to Write a Usability Engineering File](/blog/write-usability-engineering-file): the narrative-order companion to this checklist.
- [MDR Use Specification: Defining Users, Environments, and Profiles](/blog/mdr-use-specification-iec-62366): how to write the clause 5.1 artefact.
- [MDR Summative Usability Evaluation: The Final Validation Test](/blog/mdr-summative-usability-evaluation-iec-62366): the decisive clause 5.7 artefact.
- [Use-Related Risk Analysis: Identifying and Mitigating Use Errors](/blog/use-related-risk-analysis): the bridge to EN ISO 14971.
- [MDR Annex I Usability Requirements: What the Regulation Demands](/blog/mdr-annex-i-usability-requirements): the regulatory anchor.

## Sources

1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §5, §22 and §23. Annex II technical documentation.
2. EN 62366-1:2015+A1:2020, Medical devices – Part 1: Application of usability engineering to medical devices. Clauses 5.1–5.9.
3. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices.

---

*This post is part of the [Usability Under MDR](https://zechmeister-solutions.com/en/blog/category/usability) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*