A lean usability engineering program for a MedTech startup runs in five phases: plan, specify, analyse, iterate, validate. EN 62366-1:2015+A1:2020 defines the artefacts. MDR Annex I §5, §22 and §23 define why they matter. The Subtract to Ship angle is that none of the artefacts can be skipped, but each of them can be scoped to the minimum that survives an audit and a field reality test. This post is the closing checklist for the MedTech usability cluster.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Usability engineering is required for every MDR device under Annex I §5 regardless of class.
  • EN 62366-1:2015+A1:2020 is the harmonised standard and gives a presumption of conformity with Annex I §5, §22 and §23.
  • A startup can run the full process with a lean budget if it plans summative evaluation early and protects it from scope cuts.
  • What can be scoped down: formative iteration count, use environment simulation, participant count in formative, documentation page count.
  • What is non-negotiable: the use specification, the user interface specification, the summative evaluation with recruited representative users, the compiled usability engineering file.
  • The most common startup failure is testing with engineers or friendly customers and calling it summative. That failure always ends in change control costs after launch.

Why this cluster closes here (Hook)

This is the last post in the MedTech usability cluster on this blog. The cluster opened with what usability engineering is and why MDR Annex I §5 applies to every device class. It walked through the EN 62366-1:2015+A1:2020 process, the use specification, the user interface specification, use-related risk analysis, formative and summative evaluations, special topics like SaMD, home use, AI-powered devices, and the common audit findings notified bodies raise again and again. Post 499 gave the file-level checklist mapped to clauses 5.1 through 5.9. This post closes the loop with a program-level checklist a founder can hold up against the company calendar.

Felix has coached 44 startups. In usability engineering, the pattern that separates the teams that ship from the teams that grind is almost always how early they commit to summative evaluation. Teams that plan summative from the start compress the rest of the process around it. Teams that defer summative to "after MVP" end up rebuilding the use specification, re-running formatives, and missing launch windows. Tibor's side of the pattern is audit data: teams that defer summative are the same teams that get use-error findings in the notified body report.

The Subtract to Ship posture for usability engineering is clear. Every artefact defined by EN 62366-1 is load-bearing. None can be removed. But the weight of each artefact can be tuned. A two-page use specification can be enough for a simple Class I device if every required element is present. A fifty-page use specification for the same device is wasted cost.

What MDR actually requires of a startup (Surface)

MDR Annex I §5 requires manufacturers to reduce risks related to use error as far as possible, considering ergonomic features of the device, the environment of use, and the technical knowledge, experience, education, training and physical or medical condition of intended users. Annex I §22 adds lay-user requirements. Annex I §23 governs information supplied with the device and binds IFU usability to the same regime.

EN 62366-1:2015+A1:2020 is the harmonised standard that gives manufacturers a presumption of conformity with these Annex I provisions. Its clause 5 defines the process, from use specification through summative evaluation, and clause 5.8 requires that all of it be compiled into a usability engineering file. This is the evidence the notified body opens during the Annex IX or Annex XI audit.

EN 62366-1 is deliberately scalable. The standard does not prescribe a participant count for summative, a number of formative iterations, or a page count for any document. It prescribes that the activities happen, that they produce objective evidence, and that the evidence traces back to identified hazards. That scalability is what makes a lean program possible. It is also what makes shortcut thinking dangerous. Scaling means keeping all the activities and reducing their depth, not dropping activities.

A worked example: the five-phase program on a lean budget (Test)

Consider a Class IIa software-plus-hardware handheld device for home use by elderly patients. The startup has a seed round, a six-person team, and twelve months to CE. Here is what the five-phase usability program looks like under Subtract to Ship.

Phase 1: Plan (month 1). The team writes a one-page usability engineering plan pointing at EN 62366-1:2015+A1:2020 clause 5. It decides on two formative rounds and one summative. It books the summative venue and recruits the user panel with eleven months lead time. This single decision is what keeps the whole program lean. Tibor has seen startups that planned summative in month 10 get quotes of six figures because their deadline was tight; teams that booked the same venue in month 1 paid a fraction.

Phase 2: Specify (months 2–3). The team writes the use specification (clause 5.1) and the user interface specification (clause 5.4). The use specification decomposes every real-world procedure: unboxing, first-time setup via the companion app, daily operation, cleaning, battery replacement, error recovery, storage, and end of life. Each procedure generates a list of hazard-related use scenarios (clause 5.2). Because the device is for elderly home users, the user profile captures age, cognitive ability, visual acuity and motor control. The user interface specification covers display, controls, audible signals, the app screens, the packaging and the IFU.

Phase 3: Analyse (month 4). The team links every hazard-related use scenario to the risk management file under EN ISO 14971:2019+A11:2021. This is clause 5.2 meeting ISO 14971. The team also selects the subset of scenarios for summative evaluation (clause 5.3).

Phase 4: Iterate (months 5–9). The team runs two formative evaluations. Round one is five participants in a simulated environment. Round two is five more participants after design changes. Each round is documented (clause 5.6) with observations, design changes and rationale. The team resists the temptation to skip formative on the assumption that summative will catch the problem. Every problem caught in formative is cheaper than the same problem caught in summative.

Phase 5: Validate (months 10–11). Summative evaluation runs in a simulated home environment with recruited representative users matching the user profile. The team records observations, compares against the pass-fail criteria in the user interface specification, and documents residual use errors with justification and links to the risk management file (clause 5.7). The summative evaluation report becomes the central piece of evidence in the usability engineering file (clause 5.8).

Note what is not in this program. There is no third formative round. There is no exotic use-environment instrumentation. There is no fifty-page use specification. There is no duplicate risk analysis. Every cost cut is a depth cut, not an activity cut. And the most expensive activity, summative evaluation, was locked in at the start so it could not be squeezed at the end.

The Subtract to Ship playbook (Ship)

Here is the phase-by-phase checklist. Treat it as the program-level companion to post 499's file-level checklist.

Phase 1: Plan. - [ ] Write a one-page usability engineering plan pointing at EN 62366-1:2015+A1:2020 clause 5. - [ ] Decide formative iteration count (two is a reasonable floor for most devices). - [ ] Decide summative environment (real clinical, simulated clinical, or simulated home). - [ ] Book summative venue and panel recruiter with at least nine months lead time. - [ ] Identify the usability engineering file owner on the team. One person is accountable.

Non-negotiables in Phase 1: writing the plan, booking summative early, assigning ownership. Skippable in Phase 1: elaborate process documentation that duplicates EN 62366-1 clause 5 text; pick the standard and point at it.

Phase 2: Specify. - [ ] Write the use specification (clause 5.1). Decompose every real-world procedure. Capture intended user profile including age, training, cognitive and physical ability. - [ ] Identify frequently used and safety-related functions (clause 5.2). - [ ] Write the user interface specification (clause 5.4). Cover all UI elements including display, controls, alarms, packaging, labels, IFU. - [ ] Write the user interface evaluation plan (clause 5.5).

Non-negotiables in Phase 2: the use specification with granular procedure decomposition, the user interface specification covering every UI element. Skippable in Phase 2: length. A two-page use specification with every required element is stronger than a twenty-page one with gaps.

Phase 3: Analyse. - [ ] List hazard-related use scenarios (clause 5.2) with traceability to the risk management file. - [ ] Select subset for summative (clause 5.3) with documented rationale. - [ ] Confirm consistency with EN ISO 14971:2019+A11:2021 risk management file.

Non-negotiables in Phase 3: traceability to ISO 14971 and a documented summative subset. Skippable in Phase 3: parallel hazard lists that duplicate the risk management file. One source of truth for hazards, cross-referenced into the UE file.

Phase 4: Iterate. - [ ] Run formative round 1 with representative users in a simulated environment. - [ ] Document observations, design changes and rationale. - [ ] Run formative round 2 with revised design. - [ ] Document again.

Non-negotiables in Phase 4: at least one formative iteration with representative users and documented design changes. Skippable in Phase 4: elaborate formative protocols. Formative is for learning, not for audit evidence. Keep it light, document the learning.

Phase 5: Validate. - [ ] Recruit representative users matching the user profile in the use specification. - [ ] Run summative in a real or simulated use environment matching the intended environment. - [ ] Record observations against pass-fail criteria in the user interface specification. - [ ] Document residual use errors with justification and link to the risk management file. - [ ] Compile the usability engineering file (clause 5.8) with index, version control and traceability matrix.

Non-negotiables in Phase 5: recruited representative users, real or simulated environment matching intended use, recorded observations, written summative evaluation report. Skippable in Phase 5: nothing. Summative is the hard gate. Attempts to save money here are the single most common startup usability failure in Tibor's audit history.

Felix's closing note on the program: the one optimisation that pays for itself is using recruited summative participants for dual purpose. Done ethically, the same participants who validate the device can become early customer signals. Teams who plan summative as both usability validation and market contact get more value from the same budget.

Reality Check

  1. Is summative evaluation booked, or is it still a calendar placeholder?
  2. Does the use specification decompose every real-world procedure, not just the happy path?
  3. Is the user profile specific enough that a recruiter could find matching participants?
  4. Does the user interface specification cover packaging, labels, and the IFU, or only the digital UI?
  5. Are hazard-related use scenarios traceable to the risk management file under EN ISO 14971:2019+A11:2021, or is there a parallel list?
  6. Will the summative evaluation use recruited representative users in an environment that matches the intended use, or is the team planning to test with friendly customers in the office?
  7. Is the usability engineering file owned by one person with authority to compile it, or is it distributed across the team?
  8. Has anyone walked the compiled file against EN 62366-1 clause 5.1 through 5.9 to check for missing artefacts?

Frequently Asked Questions

How much should a startup budget for usability engineering? The dominant cost is the summative evaluation. For software-only or handheld devices, a simulated environment with eight to fifteen recruited participants is achievable on a tight budget if booked early. For devices that require real clinical or hospital conditions, there is no shortcut and the cost is higher. Tibor's rule: book the summative venue before negotiating the budget, not after.

Can a startup run summative with its own employees? No. EN 62366-1:2015+A1:2020 clause 5.7 requires representative users. Employees are too familiar with the device, too skilled, and do not represent the intended user population. Notified bodies will recognise employee testing immediately and reject it.

How many formative iterations are enough? EN 62366-1 does not mandate a number. Two is a reasonable floor for most devices. The point of formative is to learn, so the right number is the number that exposes and resolves the design problems before summative. If summative reveals many use errors, the team did too few formatives.

Is usability engineering required for Class I self-certified devices? Yes. MDR Annex I §5 applies to every class. The usability engineering file for a Class I device may be shorter, but every EN 62366-1 clause 5 artefact still has to exist.

What happens if the summative evaluation fails? Failure in summative is a design problem, not a paperwork problem. The team must revise the design, re-run the affected formatives or scenarios, and run summative again. This is expensive, which is why formative iterations matter. A summative failure caught before submission is far cheaper than a field failure after launch.

Does usability engineering apply to apps? Yes. Connected device app usability sits inside the same EN 62366-1 process as the hardware. Teams that exempt "just an app" from usability engineering end up with use-error findings, because a user who cannot configure the app safely creates the same clinical risk as a physical misuse.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §5, §22 and §23.
  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.