User-centered design (UCD) is the broader design philosophy that sits around EN 62366-1:2015+A1:2020. Early user involvement, iterative design, and empirical measurement are UCD principles that make usability engineering work. Good UCD alone is not usability engineering under MDR. But good UCD dramatically accelerates the EN 62366-1 process because it produces design decisions that pass formative and summative evaluation the first time.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • User-centered design is a design philosophy with three core principles: early and continuous user involvement, iterative design, and empirical measurement of design decisions.
  • EN 62366-1:2015+A1:2020 is a regulated process for applying usability engineering to medical devices. It is more specific and more auditable than UCD.
  • UCD is not sufficient for MDR compliance on its own. A startup that runs excellent UCD but produces no use specification, no hazard-related use scenarios, no formative plan, and no summative report will still fail notified body review.
  • UCD makes EN 62366-1 faster and cheaper. Teams that practise UCD from day one run their summative evaluation with confidence, not anxiety.
  • The subtraction move: stop treating UCD and usability engineering as competing frameworks. UCD is the culture. EN 62366-1 is the audit trail.

Why this matters

Tibor sees two shapes of usability failure at startups. The first shape is the team that does no user work at all until a regulatory consultant tells them they have to run summative evaluation. They scramble, recruit the wrong participants, run a rushed session, and produce a usability file full of problems. The second shape is the opposite. A team with a product design background runs wonderful UCD from day one (interviews, prototypes, iterations, field observations) but produces nothing that fits into an EN 62366-1 file structure. Their UCD evidence is scattered across sketchbooks, design reviews, and Slack channels. When the notified body asks for the use specification, the formative evaluation records, and the summative report, the team cannot produce them even though they did the work.

Felix coaches both groups. The fix is not to replace one framework with the other. The fix is to understand that UCD and EN 62366-1 solve different problems. UCD produces good design. EN 62366-1 produces a defensible audit trail. A startup needs both.

What user-centered design is

User-centered design is a design philosophy with roots in human factors and human-computer interaction. The canonical reference is ISO 9241-210 (Human-centred design for interactive systems), a general ergonomics standard that is not medical-device-specific. Its three core principles:

1. Early and continuous user involvement. Users are involved from the earliest stages of concept definition, not only at the end for validation. User involvement is not a single event. It runs throughout the project.

2. Iterative design. Design decisions are made, tested, and revised in cycles. A first design is not a final design. The process tolerates and rewards revision.

3. Empirical measurement. Design decisions are evaluated against real user behaviour, not against the team's intuition. Observed behaviour is trusted more than reported preference.

These principles apply to consumer products, enterprise software, industrial equipment, and medical devices. They are general-purpose. When applied well, they produce products that users can actually use. When applied to medical devices specifically, they produce the raw material that EN 62366-1 then structures into a regulated audit trail.

What UCD is not

UCD is not a regulated process. ISO 9241-210 is not harmonised under MDR. A startup that cites ISO 9241-210 in its technical documentation without also citing EN 62366-1:2015+A1:2020 has not demonstrated MDR usability conformity.

UCD does not produce the specific documents EN 62366-1 requires: use specification, user interface specification, known and foreseeable hazards list, hazard-related use scenarios list, formative evaluation plan and report, summative evaluation plan and report, usability engineering file. A team can run brilliant UCD and still have none of these documents.

UCD does not enforce a link to risk management. EN 62366-1 is explicitly connected to EN ISO 14971:2019+A11:2021 through the use-related risk analysis and the hazard list. UCD has no such built-in connection. A UCD team can iterate a wonderful user interface while missing a safety-critical hazard that EN ISO 14971 would have caught.

UCD does not enforce the MDR "as far as possible" ratchet for risk reduction. UCD optimises for user satisfaction and task completion. MDR requires minimising risk regardless of how satisfied the user is.

What MDR actually says

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

MDR Annex I §22. Devices intended for use by lay persons shall perform appropriately taking into account the skills and the means available to those lay users and the reasonably foreseeable variation in technique and environment.

MDR Annex I Chapter I (General Safety and Performance Requirements). Risks related to use shall be reduced as far as possible.

EN 62366-1:2015+A1:2020. The harmonised usability engineering standard. Presumption of conformity with the MDR usability requirements is achieved through compliance with this standard.

The MDR does not name UCD. The MDR requires outcomes: use-related risks minimised as far as possible, design adapted to user characteristics, lay-user devices demonstrably usable by lay users. Any design process that delivers these outcomes is acceptable, but the audit trail must map to EN 62366-1.

A worked example

A startup develops a home-use monitoring device for patients with chronic conditions. The founding team has a strong product design background. From day one they run UCD: interviews with fifteen target patients in their homes, paper prototypes, three rounds of clickable prototypes, field observations of elderly users attempting to set up the device, a pilot deployment to five households for a month.

The founding team's UCD work is genuinely excellent. The resulting design is intuitive, well-tested, and reflects real user behaviour. Field observations uncovered insights the team never would have found in their own office: some users kept the device in the kitchen instead of the bedroom, some wore reading glasses only for close work, some had arthritis that made small buttons hard to press.

When the team hires Tibor's firm to prepare for notified body submission, the assessment is mixed. The design is strong. The audit trail is nonexistent. The home observations were recorded in a Notion workspace with no document control. The interview transcripts were stored in a former employee's Google Drive. The prototype iterations lived in a Figma file with comments but no formal review records. There is no use specification. There is no formative evaluation report in any auditable form. Summative evaluation has not been run because the team assumed their field deployment was equivalent.

The fix does not require redesigning the device. The design is good. The fix requires reconstructing the audit trail. The team writes a use specification now based on the interviews and observations. They extract hazard-related use scenarios from the field observation notes. They document the prototype iterations as formative evaluation records. They run a real summative evaluation (recruited representative users, simulated home environment, think-aloud protocol, recorded observations) to validate the final design. Four months of work to turn good UCD into a compliant usability engineering file.

The contrast to a team that had done no user work at all is instructive. The second team would have needed to redesign the device after summative exposed failures. The UCD team only needed to document what they already had. UCD saved them a redesign; it did not save them the documentation effort.

The Subtract to Ship playbook

Felix's advice for startups on how to get the benefit of both frameworks without duplicating work.

1. Start with UCD from day one, but document in EN 62366-1 shapes. The raw artefacts of UCD (interviews, observations, prototypes, iterations) can be captured from day one in documents structured as they would appear in an EN 62366-1 usability engineering file. Interview notes become inputs to the use specification. Field observations become hazard-related use scenario candidates. Prototype iterations become formative evaluation records. The work is the same. The document shapes are auditable.

2. Run an early lightweight hazard scan. UCD does not look for hazards; it looks for friction points. A medical device team running UCD should add one question to every user session: "What could go wrong here that would harm the user or a patient?" This scan is not a formal hazard analysis. It produces leads that the EN ISO 14971 hazard list then captures properly.

3. Don't confuse satisfaction with safety. A user can be highly satisfied with an interface that still has safety-critical use errors. UCD optimises for satisfaction. Usability engineering under EN 62366-1 and risk management under EN ISO 14971 optimise for safety. Keep the two scoreboards separate.

4. Run formal summative evaluation regardless of how much UCD you did. UCD field deployments are not summative evaluations. Summative evaluation requires recruited representative users, a defined protocol, documented observations, and a formal report. UCD produces insight. Summative produces evidence.

Subtract move. Stop treating UCD and usability engineering as competing frameworks. They are not alternatives. UCD is the culture that makes the engineering process produce good outcomes. EN 62366-1 is the auditable shape of that engineering process. The subtraction is the duplication of effort when teams think they must choose.

Reality Check

  1. Does the team practise early and continuous user involvement, or do users only appear at summative?
  2. Are UCD artefacts (interview notes, field observations, prototype iterations) captured in document shapes that will feed the EN 62366-1 usability engineering file, or are they scattered across tools?
  3. Does the team add a "what could go wrong" question to user sessions, or does UCD optimise only for usability satisfaction?
  4. When the team claims "we did summative", does the evidence meet EN 62366-1 criteria (recruited users, defined protocol, simulated or real environment, documented findings, formal report)?
  5. Is there a use specification that reflects the granularity of the UCD fieldwork, or does the use specification reduce weeks of observations to three paragraphs?
  6. Does the team distinguish between user satisfaction (UCD scoreboard) and use-related risk (EN 62366-1 + EN ISO 14971 scoreboard)?
  7. Can the team trace every design decision back to a user observation, a prototype test, and an EN 62366-1 document entry?

Frequently Asked Questions

Can we cite ISO 9241-210 instead of EN 62366-1 in our technical file? No. ISO 9241-210 is not harmonised under MDR. EN 62366-1:2015+A1:2020 is the harmonised usability engineering standard for medical devices. Cite EN 62366-1.

Does strong UCD mean we can skip formative evaluation? No. Formative evaluation is a required step in EN 62366-1. Continuous user involvement during UCD does not substitute for documented formative evaluation.

Does strong UCD mean we can skip summative evaluation? Absolutely not. Summative evaluation is the validation step. It requires recruited representative users, a defined protocol, simulated or real use conditions, and a formal report. No amount of UCD fieldwork replaces it.

Where does UCD fit in the Subtract to Ship approach? UCD is upstream. It produces the design quality that makes the regulatory usability engineering process run smoothly. Teams that practise UCD from day one run their summative with confidence.

Is UCD a requirement under MDR? No. MDR requires outcomes, not methods. UCD is a design philosophy that helps deliver those outcomes. EN 62366-1 is the process that proves they were delivered.

What about UCD for software-only medical devices? Same principle. Software-only medical devices are subject to EN 62366-1 exactly as physical devices are. UCD practices translate directly to software but the audit trail must still conform to EN 62366-1.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I, Chapter I, General Safety and Performance Requirements, §5, §22.
  2. EN 62366-1:2015+A1:2020. Medical devices, Part 1: Application of usability engineering to medical devices.
  3. EN ISO 14971:2019+A11:2021. Medical devices, Application of risk management to medical devices.