IEC 62366-1 Usability Engineering

IEC 62366-1 applies usability engineering to safety

IEC 62366-1 specifies a process for analysing, specifying, developing and evaluating the usability of a medical device as it relates to safety. Its purpose is to assess and reduce risks associated with correct use and use error during normal use.

The standard can help identify abnormal use, but its process is not intended to assess or control risks arising from intentional abnormal use. The practical boundary matters: a foreseeable mistake, misunderstanding or omission is not made “abnormal” merely because the design team considers it unreasonable.

Use MTL-116 — Usability and Human Factors for the broader engineering discipline. This topic focuses on the structure and evidence expected by IEC 62366-1.

Use the terminology precisely

A use error is not automatically a user failure. It can reveal an ambiguous control, poor feedback, an unrealistic workflow, a misleading display, an indistinguishable connector or a demand that exceeds foreseeable human capability.

The activities form one connected process

These activities are iterative rather than a simple waterfall. New formative findings can change the risk analysis, specification and evaluation plan. Risk-management findings can require new scenarios or interface controls. The records must remain mutually consistent.

Begin with a decision-useful use specification

The use specification provides the context against which interaction is designed and evaluated. It should be specific enough to reveal meaningful differences between users, tasks and environments.

• State the intended medical indication and purpose.
• Describe intended patient populations and relevant physical or cognitive characteristics.
• Define each intended user group separately, including knowledge, experience, capabilities and limitations.
• Describe professional, home, emergency, transport or other intended use environments.
• Identify environmental factors such as lighting, noise, interruptions, PPE, space, mobility and competing tasks.
• Explain the operating principle and the workflows in which the device participates.
• Identify training, qualification, language, accessibility and support assumptions.
• Record reasonably foreseeable users, uses and environments outside the preferred workflow.

Keep the use specification aligned with MTL-102 — Intended Purpose, Users and Use Environments. A generic label such as “health-care professional” rarely defines a sufficiently coherent user group.

The user interface is the complete interaction

The interface is not limited to a screen. It includes everything the user perceives, understands, handles, connects, configures, reads, maintains or relies upon while using the device.

Interface problems often occur between disciplines. A software message may describe a mechanical state incorrectly, a connector may fit the wrong port, or packaging may disrupt the order of preparation. The complete interaction needs one accountable view.

Integrate use-related risk with ISO 14971

Usability engineering supplies use-specific analysis and evidence to the overall risk-management process. Identify user-interface characteristics related to safety, known or foreseeable hazards and hazardous situations, and the tasks and use errors that can contribute to harm.

• Review complaints, incident databases, recalls and known problems with similar devices.
• Break workflows into perceptual, cognitive and physical tasks.
• Consider preparation, checking, programming, connection, operation, interpretation, cleaning, maintenance and disposal.
• Identify action errors, omissions, timing errors, sequence errors, selection errors and misinterpretations.
• Describe the sequence from interface condition through use error and hazardous situation to possible harm.
• Include correct use that can still expose a person to risk.
• Consider shortcuts and adaptations users may reasonably make under workload or environmental constraint.
• Trace interface risk controls to requirements and evaluation evidence.

Apply MTL-105 — Medical-device Risk Management for the product risk process and MTL-302 — ISO 14971 Risk Management for the standards framework.

Select hazard-related use scenarios deliberately

A hazard-related use scenario describes a sequence of tasks and interactions that could lead to a hazardous situation or harm. The manufacturer identifies these scenarios and selects those to be included in summative evaluation, based on the severity of possible harm and the rationale permitted by the standard.

FDA’s “critical task” concept is closely related but not identical: it focuses on a user task that, if performed incorrectly or not performed, would or could cause serious harm. A market strategy may therefore require both an IEC scenario-selection rationale and an FDA critical-task analysis.

Do not reduce a scenario to a test instruction such as “set the dose”. Preserve the clinical context and consequences that make the interaction safety-relevant.

Make the user-interface specification testable

The user-interface specification translates user, task, environment and risk information into design requirements. It should cover physical and digital interaction, performance, information, training and the controls necessary for safe use.

• Define the intended sequence, states, choices and feedback for each safety-related task.
• Specify control-display relationships, units, ranges, defaults and confirmation behaviour.
• Define connector, consumable, accessory and assembly compatibility.
• Set requirements for visibility, legibility, audibility, tactile feedback and accessibility.
• Specify alarms, warnings, status, error prevention and recovery.
• Define behaviour under interruption, timeout, power loss, communication loss and incomplete setup.
• Identify information and training genuinely required for safe use.
• Assign objective acceptance criteria and trace each risk control.

Use MTL-103 — User Needs and Design Inputs to distinguish stakeholder needs from approved design inputs and keep them verifiable.

Plan formative and summative evaluation as one strategy

The user-interface evaluation plan should define how development will learn from representative users and how the final interface will be evaluated. It can evolve as risks and the design become clearer, but changes need rationale and control.

Separate exploratory formative work from the controlled summative evaluation. A study cannot credibly serve both purposes when the interface is changed in response to observations during the same supposed final evaluation.

Use formative evaluation to improve the design

Formative evaluation occurs during development to reveal strengths, weaknesses, misunderstandings and failure mechanisms. It should begin early and recur as important workflows and risk controls mature.

• Evaluate sketches, mock-ups, physical models, simulations and functional prototypes at the fidelity needed for the question.
• Include representative users; expert review alone cannot reproduce real knowledge, habits or workload.
• Observe behaviour rather than relying only on preferences and opinions.
• Probe the user’s understanding after a task without teaching the intended answer.
• Capture use errors, close calls, repeated attempts, delays, confusion and unexpected strategies.
• Analyse root causes in the interface, task, information, training and environment.
• Record resulting design decisions, rejected alternatives and updates to risk controls.
• Repeat evaluation where a change creates a new interaction or uncertainty.

Sample size should follow the purpose and diversity of the evaluation. Formative studies often use small, focused groups iteratively; they are valuable because they inform change, not because they produce a pass percentage.

Summative evaluation examines the final safety-related interface

Summative evaluation provides objective evidence that the final or production-equivalent user interface can be used safely by intended users in intended use environments for the selected hazard-related use scenarios.

The protocol should be approved before execution and define participants, training decay where relevant, device configuration, scenarios, environment, data collection and analysis. The interface should be sufficiently final that observations represent the product to be released; later safety-relevant changes require impact assessment.

A summative study does not prove that no future user will make an error. It tests the risk-control argument under controlled, representative conditions and must be interpreted with the complete use-related risk evidence.

Recruit representative users—not convenient substitutes

Participants should represent each distinct intended user group involved in safety-related tasks. Differences in professional role, experience, age, capability, language, training and familiarity can change how an interface is understood and operated.

• Define inclusion and exclusion criteria before recruitment.
• Recruit people with the knowledge and experience expected in actual use.
• Represent relevant physical, sensory, cognitive and language characteristics.
• Avoid product-team members or people already trained through development studies.
• Separate user groups when their tasks, capabilities or risk profiles differ materially.
• Justify sample sizes and distribution against the selected scenarios and market expectations.
• Record prior experience with the product and similar technologies.
• Manage recruitment and consent without disclosing answers or expected behaviour.

One generic “nurse” group may not represent theatre nurses, community nurses and specialist diabetes educators. User-group definitions should reflect the work, not merely job titles.

Recreate the conditions that shape performance

Simulation should preserve the aspects of the intended environment that can affect safety-related behaviour. A quiet meeting room, unlimited time and a perfectly prepared device can hide problems that emerge in practice.

Simulation need not reproduce every detail. It must reproduce or conservatively address the conditions that could materially influence the selected safety-related interactions.

Analyse use errors, close calls and difficulties

Count data alone cannot explain whether a residual risk is acceptable. For every significant observation, determine what happened, why it happened, whether the interface or scenario contributed, and whether other users could experience the same problem.

• Separate observed behaviour from the moderator’s interpretation.
• Use post-task interviews to explore understanding without replacing behavioural evidence.
• Consider perception, cognition, expectation, control, feedback, workload and transfer from familiar devices.
• Evaluate close calls and repeated recovery attempts, not only completed errors.
• Identify whether the study design introduced or concealed the problem.
• Assess whether the finding affects other tasks, user groups, variants or environments.
• Determine whether design change is practicable before accepting residual risk.
• Update risk analysis, requirements and traceability with the conclusion.

There is no universal numerical pass rate in IEC 62366-1. The conclusion is risk-based and must address the possible harm, observed cause, effectiveness of controls and remaining uncertainty.

Do not use labelling or training to rescue avoidable design problems

Instructions, warnings and training can be necessary risk controls, but they depend on attention, comprehension, memory and availability at the moment of use. Apply the ISO 14971 control hierarchy: first consider inherent safety through design, then protective measures, then information for safety.

When information or training is relied upon, evaluate the actual material, delivery, retention interval and access conditions. A warning tested by asking participants to read it directly does not show that users will notice and act upon it in the real workflow.

Ensure that packaging, device labels, on-screen language, instructions and training use consistent concepts. Changes to any of these can alter the evaluated interface and require usability impact assessment.

Existing interfaces still need a defensible assessment

IEC 62366-1 includes an approach for a user interface of unknown provenance—an interface or part for which adequate records of the standard’s development process are unavailable. This is relevant to legacy products, acquired technology and components integrated without complete usability records.

• Define exactly which interface elements lack adequate provenance.
• Review available complaints, incidents, field experience and comparable-product information.
• Establish the use specification and analyse safety-related interface characteristics.
• Identify hazards, hazardous situations and use-related sequences.
• Evaluate whether existing risk controls and evidence are sufficient.
• Address gaps and new risks introduced by modification or integration.
• Document the rationale rather than claiming retrospective compliance without evidence.

The legacy route is not an exemption from safe design. A significant change to the interface, intended use, user population or environment can require new development and evaluation activities.

Usability engineering across the lifecycle

The usability engineering file is a connected body of evidence

The usability engineering file can consist of references to controlled records held elsewhere. Its value lies in showing how product definition, risk analysis, design, evaluation and conclusions connect—not in duplicating every document into one folder.

Organise the evidence through MTL-104 — Design Controls and Technical Documentation. The records should identify the evaluated interface version and its relationship to the released configuration.

Common misconceptions

Practical implementation checklist

• Does the use specification distinguish meaningful user groups and environments?
• Does the interface boundary include physical, digital, informational and connected elements?
• Have known use problems and foreseeable use errors been investigated?
• Are hazard-related use scenarios traceable to hazardous situations and possible harm?
• Is the selection of scenarios for summative evaluation justified?
• Have FDA critical tasks been analysed separately where the US market is intended?
• Are user-interface risk controls expressed as testable design inputs?
• Does the evaluation plan connect formative learning with final summative evidence?
• Are participants and simulated conditions genuinely representative?
• Does the final study avoid coaching and use production-equivalent materials?
• Are use errors, close calls and difficulties analysed for root cause and risk?
• Are labelling and training relied upon only where appropriate and evaluated realistically?
• Is the evaluated configuration traceable to the released product?
• Are interface changes and post-market signals fed back into the usability engineering file?