The user interface specification under EN 62366-1:2015+A1:2020 is a safety artifact, not a design document. It translates the use specification into concrete interface decisions that can be tested, audited, and traced back to hazard-related use scenarios under MDR Annex I §5 and §22. When the UI specification is written properly, it catches use hazards at the drawing board, not at summative evaluation.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • The user interface specification is a required deliverable under EN 62366-1:2015+A1:2020. It is the second step of the usability engineering process, sitting between the use specification and the formative evaluation.
  • It is not a visual mock-up or a wireframe. It is a structured description of every interaction, display, control, label, and feedback element that a user will encounter during a hazard-related task.
  • Under MDR Annex I §5 and §22, the manufacturer is required to design use-related risks out of the device as far as possible. The user interface specification is where that obligation becomes a design decision.
  • Every element of the user interface specification must trace back to a task from the use specification and forward to a control in the risk management file. Without that traceability, notified body auditors flag it as incomplete.
  • A good user interface specification catches the hazard before formative evaluation. A bad one leaves the catching to summative, where the cost of a finding is ten times higher.

Why this matters

Tibor has one story that makes the point permanently. A handheld medical device designed by an engineering team where most of the designers happened to be left-handed. The display was positioned and oriented so that a left-hand hold felt natural. Nobody on the team thought about it consciously. It simply fit the hands in the room. When the team ran summative evaluation with right-handed users, the display appeared upside down from the user's perspective. A software fix for display orientation went in as a late patch. The clinical risk was real: a misread value on a handheld device is a use error that can harm a patient.

The failure here was not at summative. Summative did its job, it found the problem. The failure was that the user interface specification never asked the question "which hand is this device held in, and what does the screen look like from the user's eye position for each grip?" That question belongs in the UI specification phase, months before prototypes exist. The left-handed display story is what happens when the UI specification is skipped or treated as a design document rather than a safety artifact.

Felix coaches startups who confuse the user interface specification with a Figma file. A Figma file answers how the screen looks. The user interface specification answers what the user has to know, do, see, hear, and decide at every step of a hazard-related task, and what happens when they deviate. These are very different documents. One is a picture. The other is evidence of safe design.

What MDR actually says

The MDR does not use the phrase "user interface specification". That phrase comes from EN 62366-1:2015+A1:2020, the harmonised usability engineering standard listed against MDR Annex I §5 and §22. The MDR supplies the obligation. EN 62366-1 supplies the method.

MDR Annex I §5. Devices shall be designed and manufactured in such a way that risks linked to ergonomic features of the device and the environment in which the device is intended to be used are reduced as far as possible, taking into account the technical knowledge, experience, education, training, and use environment, as well as the medical and physical conditions of intended users.

MDR Annex I §22. Devices intended for use by lay persons shall be designed and manufactured to perform appropriately for their intended purpose, taking into account the skills and means available to lay users and the influence resulting from variation that can be reasonably anticipated in the lay user's technique and environment.

EN 62366-1:2015+A1:2020, clause 3. Defines the use specification (the documented description of intended medical indication, intended user profile, intended use environment, and operating principle) and the user interface specification (the documented set of attributes of the user interface). Clause 5.4 of the standard requires the manufacturer to develop and document a user interface specification as part of the usability engineering process.

EN ISO 14971:2019+A11:2021. Every hazard-related use scenario is an input to the risk analysis. The user interface specification is where hazard-related attributes of the interface become explicit enough to analyse.

Plain-language translation: the MDR requires use-related risks to be designed out. EN 62366-1 says the way to do that is to write down, task by task, exactly what the interface must show, ask, and respond to. The user interface specification is the deliverable where that design happens on paper, before any code or hardware locks in a mistake.

A worked example

A Class IIa home-use device for patients with chronic respiratory conditions. The use specification lists intended users as adults aged 40 to 85, some with reduced grip strength, some with mild cognitive impairment, used at home under variable lighting, sometimes at night. Hazard-related tasks include device startup, dose adjustment, treatment delivery, cleaning, and low-battery response.

The team sits down to write the user interface specification. They take the dose adjustment task first, which is the highest-risk interaction because an incorrect dose has direct clinical consequences. For this single task, the user interface specification has to answer:

  1. What must the user see before making the dose adjustment (current dose, maximum allowable dose, last dose, visible units)?
  2. What control does the user operate (physical wheel, plus and minus buttons, touchscreen slider) and what are its tactile, visual, and auditory feedback properties?
  3. What happens when the user approaches the maximum allowable dose (colour change, haptic resistance, audible warning)?
  4. What confirmation is required before the dose is committed (explicit confirm press, timed confirmation, biometric)?
  5. How is the result displayed after commitment (numeric, graphical, spoken, persistent)?
  6. What feedback occurs under foreseeable deviations (low battery, obstructed display, glare, wrong orientation)?
  7. What recovery path exists if the user realises an error after confirmation?

The team writes each answer down against the hazard-related use scenarios from the use specification. The act of writing forces decisions. During item 1, the team realises the current dose and the last dose look almost identical on the mock-up and a tired night-time user could confuse them. That is the left-handed-display moment. It happens on paper. The fix is cheap: one becomes a filled bar, the other an outlined bar, with distinct colours that remain distinguishable under the lighting conditions listed in the use specification.

That fix would have cost nothing if it landed in the user interface specification. It would have cost tens of thousands of euros if it had been caught at summative evaluation with a recruited panel and a change control cycle. It would have cost an order of magnitude more if it had been caught by a vigilance report after market release.

The Subtract to Ship playbook

Felix's Subtract to Ship approach treats the user interface specification as a forcing function for safe design. The playbook is narrow by design.

  1. Start from the use specification, never from the prototype. Open EN 62366-1:2015+A1:2020 clause 5.1 and write the use specification first. Intended medical indication, intended user profile, intended use environment, intended operating principle. No mock-ups yet. If the team cannot write the use specification without looking at a prototype, the prototype is leading the regulation, which is backwards.

  2. Decompose tasks to hazard-relevant granularity. Tibor's rule: do not write "user operates the device". Write the exact subtasks: unboxing, initial charge, first startup, daily use, dose adjustment, cleaning, transport, low battery, error recovery, end of life. Each one is a row in the use specification that the user interface specification then refines.

  3. For each hazardous task, write the user interface specification in structured form. Seven questions per task: what the user sees, what the user does, what the device does in response, what foreseeable deviations exist, what feedback indicates error, what recovery path exists, what environmental factors affect each step.

  4. Cross-reference both files. Every hazard-related use scenario in the user interface specification must link to a hazard identified in the EN ISO 14971:2019+A11:2021 risk management file. Every use-related hazard in the risk management file must trace to an interface decision in the user interface specification. Auditors check this loop.

  5. Review the user interface specification before prototyping, not after. This is the step most startups skip. The document is only useful as a hazard-catching device if it exists before the hardware and software are frozen. The moment you freeze the design, the user interface specification becomes documentation of what already exists rather than a tool to decide what should exist.

  6. Use formative evaluation to test the user interface specification, not the prototype. Formative is a cheap iteration, run with five to eight participants on paper prototypes or early mock-ups. The question is not "does the device work" but "does the user interface specification correctly predict what users will do". Where the document and the users disagree, the document gets updated.

  7. Lock the user interface specification before summative. Summative is formal. It uses recruited representative users, simulated or real use environments, and documented outcomes. By the time summative runs, the user interface specification is the reference truth, and summative either validates it or triggers a change control cycle.

This playbook is not an extra layer of work. It replaces the hidden work that happens when use errors surface during summative or after release. A properly written user interface specification saves its own cost several times over.

Reality Check

  1. Can the team produce the user interface specification as a standalone document, separate from any Figma file or engineering drawing?
  2. For each hazardous task in the use specification, does the user interface specification answer all seven structured questions (what the user sees, does, gets back, deviation cases, feedback, recovery, environment)?
  3. Is every hazard-related use scenario in the user interface specification linked to a hazard in the EN ISO 14971:2019+A11:2021 risk management file?
  4. Was the user interface specification written before the prototype was frozen, or after?
  5. Does the user interface specification account for the full range of users from the use specification, including the edge cases (lay users, low vision, reduced grip, night use, outdoor use)?
  6. When the user interface specification was reviewed, did at least one reviewer have no prior exposure to the device design?
  7. If a notified body auditor asked "show me how this button decision connects to a documented hazard", could the team answer within five minutes?
  8. Has the user interface specification been updated after every design change, or is it frozen at the version that was written before development?

Frequently Asked Questions

Is the user interface specification the same as a wireframe or Figma file? No. A wireframe shows what a screen looks like. The user interface specification documents what the user must know, do, and receive at each step of a hazardous task, including foreseeable deviations and recovery paths. A wireframe is a visual artifact, the user interface specification is a safety artifact. The two can reference each other but are not interchangeable.

Does EN 62366-1:2015+A1:2020 require a separate user interface specification document? Clause 5.4 of the standard requires the user interface specification to be developed and documented. Most manufacturers write it as a dedicated chapter inside the usability engineering file rather than as a standalone file. Either form is acceptable as long as the content is complete and traceable.

Who should write the user interface specification for a startup? The cross-functional team that owns usability: clinical lead, design lead, risk management lead, and a representative user if available. Tibor's rule is that the document cannot be written by a single engineer alone because the hazards that matter are exactly the ones a single perspective misses.

When does the user interface specification become part of the technical documentation? It is part of the usability engineering file, which in turn is part of the technical documentation under MDR Annex II. Notified body reviewers under MDR Annex IX will look at it during conformity assessment. It must be complete, current, and consistent with the risk management file.

How often does the user interface specification need to be updated? Every design change that affects any interface element triggers a review. If the review shows a change to hazard-related attributes, the user interface specification is updated and the change is propagated to the risk management file. Change control is the glue.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Chapter I (GSPR 1-9), Annex I §5, Annex I §22.
  2. EN 62366-1:2015+A1:2020, Medical devices – Application of usability engineering to medical devices. Clauses 3, 5.1, 5.4, 5.7.
  3. EN ISO 14971:2019+A11:2021, Medical devices – Application of risk management to medical devices.
  4. EN ISO 13485:2016+A11:2021, Medical devices – Quality management systems – Requirements for regulatory purposes.