Usability Engineering for Medical Devices to IEC 62366-1: The Practical Guide from Design Practice

Usability engineering to IEC 62366-1 is the process that systematically secures exactly that. Treat it as a compliance add-on and you create loops in approval. Integrate it into the design process from the start and you reach the market faster, more safely and with the better product. This practical guide shows how, from the perspective of more than 300 series products realised, many of them in medical technology.

IEC 62366-1 requires a documented usability engineering process for every medical device with a user interface: from the use specification to summative evaluation.

Usability engineering is not a downstream verification step but an integral part of good product design. Integrated early, it saves correction loops in approval and lowers the risk of expensive design changes shortly before market launch.

FDA guidance recommends at least 15 participants per user group for summative validation; formative tests work with five to eight participants per iteration.

The usability engineering file is not bureaucracy but the logbook of user-centred development. Pragmatically structured, it grows alongside development.

This practical guide is the first article in our knowledge hub on Medical Usability and Regulation. The follow-up articles on formative and summative evaluation and on human factors go deeper into the individual steps.

IEC 62366-1 in its current edition 62366-1:2015 including amendment A1:2020 describes how manufacturers systematically develop, evaluate and document the usability of a medical device. At its core lies one question: can the intended users operate the product safely and effectively in the intended environment, even under stress, time pressure and in the routine of clinical practice?

The standard applies to virtually all medical devices with a user interface, from the handheld instrument to the complex system. It is the recognised state of the art for usability engineering and the authoritative reference that notified bodies also follow. An important note for practice: unlike, say, ISO 14971 or ISO 13485, EN 62366-1 is currently not consistently listed in the EU Official Journal as a standard harmonised under the MDR. Its application therefore does not automatically establish full presumption of conformity; it remains, however, the expected state of the art, compliance with which manufacturers should demonstrate. In addition, the MDR and IVDR set requirements for usability in places that go beyond the standard. Working through the standard alone does not yet fully cover the regulatory requirements, all the more reason to understand usability not as a checklist but as a development principle.

In practice this means: development leads and product managers do not need a standards expert working in isolation, but a process in which design, engineering and regulatory affairs speak the same language. How a well-considered human-machine interface becomes a competitive advantage we have already described in the article Medical Design under the MDR.

The standard does not prescribe a rigid sequence, but a clear logic. Four work steps carry the process:

Create the use specification

It starts with the question: who uses the product, for what, where and under what conditions? The use specification describes the intended medical purpose, the user groups with their characteristics (qualification, physical prerequisites, level of experience), the use environment and the essential operating scenarios. It is the foundation for everything that follows and, in practice, the document that most often arrives too late or too superficially. Our recommendation from design practice: the use specification is not created at the desk but from observation. Methods for this are described in our article on design research and user research.

Identify hazard-related use scenarios

The use specification yields the scenarios in which operating errors can lead to harm. This is where usability engineering interlocks with risk management to ISO 14971: which use errors are conceivable? Which of them have safety-relevant consequences? These hazard-related use scenarios later become the mandatory content of the summative evaluation.

Derive the user interface specification

Only now does design begin, and against clear requirements. The user interface specification translates the findings into concrete specifications for hardware and software: arrangement and distinguishability of controls, legibility of displays, system feedback, protection against misuse. Good medical design does not answer these questions after the fact but makes them part of the design brief.

Plan the evaluation

The evaluation plan defines what is tested when and with whom: formative tests accompanying development, the summative evaluation as the final proof. Setting up the planning early avoids the classic mistake of putting real users in front of the product for the first time at the end of development.

Formative evaluations accompany development. They are small, fast and allowed to fail, which is exactly their purpose: finding weaknesses while changes are still cheap. The summative evaluation comes at the end. With the finished design, it demonstrates that the hazard-related use scenarios are safely managed, and it forms part of the approval documentation.

In practice, the quality of the formative work decides the outcome of the summative: those who have tested iteratively with users rarely face surprises in the validation test. Which form of test is right when, and how the two differ methodologically, we explore in a dedicated article in our knowledge hub on Medical Usability and Regulation, to which this practical guide also belongs.

The FDA's human factors guidance recommends at least 15 participants per distinct user group for validation. IEC 62366-1 itself prescribes no minimum sample size; the 15 are an FDA recommendation that in practice is also accepted by European notified bodies as orientation. If a product serves, say, surgeons and OR nurses with different tasks, that is two groups, so at least 30 participants.

The framing matters: the 15 are not statistical proof of significance but an empirical value above which recurring operating problems reliably surface. And they apply to the summative evaluation. Formative tests work with far fewer participants, five to eight users per iteration usually uncover the serious problems. Those who have the budget for a large final validation but skimp on formative tests are optimising in the wrong place.

The usability engineering file bundles the evidence of the entire process. It is not a standalone document written at the end but a structured collection that grows during development. Pragmatically organised, it contains:

The use specification with user groups, use environment and operating scenarios. The identified hazard-related use scenarios with reference to the risk file. The user interface specification and the evaluation plan. The results of all formative evaluations together with the design changes derived from them. The report of the summative evaluation with assessment of the residual risks.

Those looking for templates should treat them as a scaffold, not a form: the content arises from real user research and documented design decisions. A file that only fills in fields stands out to notified bodies, and does not help the product.

In our development process, usability engineering and design are not separate disciplines. The use specification feeds the design brief, formative tests evaluate real design states, and every design decision with a safety dimension is documented so that it flows directly into the usability engineering file. This shortens approval because no evidence has to be reconstructed, it is already there.

Two examples from practice: for the C3 insufflator for Wisap, the operating guidance was developed in close coordination with clinical users through formative usability tests; the result actively reduces operating errors and holds up in clinical practice. For the ExacTrac Dynamic patient positioning system for Brainlab, the system design translated highly complex technology into a design language aligned with the workflows of medical-technical staff.

This interlocking is the core of our approach to medical design: usability is a design task, not a verification task. How we develop medical devices from strategy to series maturity is shown on our overview page medical technology design.

Stefan Eckstein is founder and managing director of Eckstein Design. He led the development of the VDID Codex, the professional code of German industrial designers, and has been developing medical devices from strategy to series maturity with his team for over 20 years.

This practical guide opens a series of articles in which we break down the usability of medical devices step by step: from IEC 62366-1 through formative and summative evaluation to human factors. The series is aimed at development leads and product managers who want to use usability engineering not just to pass but as a design advantage.