A usability engineering file has no required shape

Ask a design-controls team where the design history file's table of contents comes from and most can point to a clause. Ask where the usability engineering file's table of contents comes from, and the answer is usually a template someone built once, copied forward, and never checked against the standard itself. That's not a gap in the team's diligence. IEC 62366-1, the standard that governs applying usability engineering to medical devices, defines a detailed process from first use assumption to final validation test — and never once tells a manufacturer how to file the paperwork that process produces.

The process is specific; the file it produces isn't

IEC 62366-1:2015, amended by AMD1:2020, runs a manufacturer through a defined sequence: establish a use specification covering intended users, use environments, and the user interface; identify the hazards and hazardous situations that can arise from use, including use error; identify and categorize the hazard-related use scenarios that follow from those hazards; specify the user interface itself against that analysis; run formative evaluation, iteratively, to catch use problems while the design can still change cheaply; and close with summative evaluation — validation testing under conditions that represent actual use, aimed at the hazard-related use scenarios the earlier steps identified as carrying unacceptable risk. Each of those outputs has to exist and has to be documented. What the standard doesn't specify is the container: a required index, a mandated section order, a fixed list of what the compiled file has to hold beyond the individual records the process already generated.

What that gap means in practice

Two teams can both run the process completely, correctly, end to end, and still produce usability engineering files that look nothing alike — one organized around the process's own chronology, another around device subsystems, a third around risk categories borrowed from its ISO 14971 file. None of the three is wrong under the standard's own text, because the standard was written to specify what has to be analyzed and evaluated, not how the resulting evidence has to be bound together and presented to a reviewer. A notified body auditor or an FDA reviewer opening an unfamiliar file for the first time is navigating a structure the manufacturer invented, not one IEC 62366-1 handed them — which raises the cost of a badly organized file well past what a missing index usually costs elsewhere in a technical dossier.

Use error is a hazard, not an excuse

The standard's use of “use error” is easy to misread as blame directed at the user, and reading it that way undersells what the clause actually asks a manufacturer to do with it. A use error — a user action or lack of action that differs from what the manufacturer intended or the user expected — is treated as a hazard to be designed against, the same way a component failure is, not a training gap to note and move past. A risk management file and the usability engineering file aren't two separate accounts of the same device; the hazard-related use scenarios the usability process identifies are meant to land in the hazard analysis ISO 14971 already requires, not sit in a parallel document a risk reviewer never opens.

Formative work explains the design; summative work has to stand alone

Formative evaluation is where a design earns the right to move forward — early, iterative, and forgiving of a rough prototype, because its job is to surface problems while a fix still just means a revision, not a re-test. Summative evaluation carries a different burden entirely: it's the evidence a reviewer actually weighs, run under a predefined protocol against the hazard-related use scenarios the earlier analysis flagged, on a device representative of what will actually ship. A file that leans on strong formative results to carry a thin or informally run summative test has confused two kinds of evidence the standard treats as sequential, not interchangeable — one earns design changes, the other has to earn the claim that the device is safe to use as labeled.

Where the FDA report and the file underneath it split

FDA's 2026 human factors guidance governs a different, narrower question than IEC 62366-1 does — what has to appear, and in what order, in the report a sponsor hands FDA describing summative and formative work already done. The usability engineering file is the underlying record that report draws from, not a document the categorization framework replaces. A team that builds its human factors report to the 2026 outline and stops there, without a usability engineering file the report can be checked against, has produced a summary with nothing behind it to summarize.

Where this meets the rest of the file

A usability engineering file built to hold the full IEC 62366-1 chain — use specification through summative evaluation, hazard-related use scenarios traced into the risk file, and a structure a reviewer can actually navigate on first read — is previewed in the launch catalog. If your program organizes a usability engineering file differently, the shelf takes that correction directly.