Usability engineering file template for IEC 62366-1
Gideon Awolesi ·
A usability engineering file is where you keep the evidence that your device can be used safely. IEC 62366-1 doesn't prescribe a format, so a lot of teams start from a blank document a few weeks before submission and try to reconstruct months of design decisions. This template follows the clauses of the standard in order, says what goes in each section, and points to the design work each one should come from, so you can fill it in while you design.
01How to use this template
Keep one section for each step of the process in clause 5 of IEC 62366-1. The file doesn't have to be one document. It can point to your risk management file, your design files, and your test reports, as long as someone reviewing it can follow the trail from a hazard to the evidence that it's controlled.
It's important that you fill each section in while the work happens. A reason written down at the moment you make a design decision is far more useful to a notified body than one reconstructed later.
02The template, clause by clause
| Clause | Section of your file | What goes in it | Where it comes from |
|---|---|---|---|
| 5.1 | Use specification | Intended medical indication, patient population, intended users, use environment, and operating principle | Discovery research and the intended use statement |
| 5.2 | User interface characteristics related to safety | The parts of the interface that could affect safety, and the use errors that could happen with them | Task analysis and early design reviews |
| 5.3 | Known or foreseeable hazards and hazardous situations | Hazards related to use, including ones from similar devices on the market | Risk management file (ISO 14971) and post-market data |
| 5.4 | Hazard-related use scenarios | Each scenario where a use error could lead to a hazardous situation, with its severity | Workshops with clinical, risk, and engineering teams |
| 5.5 | Scenarios selected for summative evaluation | Which scenarios you'll test, and why | The risk analysis |
| 5.6 | User interface specification | The requirements the interface has to meet, including the accompanying documentation and training | Your design files and component specifications |
| 5.7 | User interface evaluation plan | How you'll run formative and summative evaluation, with participants, tasks, and acceptance criteria | Your research plan |
| 5.8 | Design, implementation, and formative evaluation | Each formative round, what you found, and what you changed | Prototype tests and design iterations |
| 5.9 | Summative evaluation | The protocol, the results, and an analysis of every use error and close call | The validation study |
03Keep the trail from hazard to evidence
The question a reviewer keeps asking is "how do you know this risk is controlled?" Your file answers it when every hazard-related use scenario points to the part of the interface that addresses it, the requirement in the user interface specification, and the evaluation that tested it.
A simple traceability table does this well. Give each scenario an ID and use it everywhere: in the risk file, in the design file annotations, and in the test protocol.
04Keep the specification in step with the design
The user interface specification is a design artefact. If it lives in a separate document that nobody updates, it stops describing the product you're shipping. Reference the design files and components directly, and update the specification in the same review where a design change is approved.
05When you change a device that's already validated
For a new feature or parameter, you don't need to rewrite the file. Add the new hazard-related use scenarios, mark which tasks are new and which were already validated, and plan the evaluation around the new risk. In a medical device project we worked on for Philips, we turned the clinical and engineering requirements for a new parameter into 14+ use scenarios, five safety decisions, and uFMEA inputs before any screen was final.
The FDA's guidance on human factors content in submissions, final since 29 May 2026, also sorts changes into three categories, and only the third needs a full human factors report with validation testing.
06Get the file checked before you submit
Our Usability Review checks your usability engineering file against IEC 62366-1 and the FDA human-factors guidance, clause by clause, in four weeks from €6,000, and gives you a ranked list of what to fix. Design and conformity decisions, and the submission itself, stay with you as the manufacturer.