Usability Engineering for Medical Devices: IEC 62366-1 and Human Factors Guide

Many serious device incidents are not caused by a faulty device but by a device that was easy to use wrongly: a confusing display, a connector that fits the wrong port, an instruction nobody reads. Usability engineering, also called human factors engineering, is the discipline that finds and removes those problems before patients are harmed. This guide explains IEC 62366-1, the FDA human factors expectations, and how to build a usability file that satisfies both.

Why usability engineering is a regulatory requirement

Usability is not optional design polish. Under the EU MDR, Annex I (the General Safety and Performance Requirements) requires manufacturers to reduce use-related risk as far as possible, taking into account the knowledge, training and environment of the intended user, and it has specific requirements for devices used by lay persons. In the United States, FDA expects human factors information in most premarket submissions for devices where use error could cause harm, and the design validation requirement includes confirming that the device meets user needs under actual or simulated use conditions. The international standard that sets out the process is IEC 62366-1 (with amendment 1), and ISO 14971 expects use-related hazards to be part of your risk management.

Key terms

• Use error: a user action, or lack of action, that leads to a result different from what the manufacturer intended or the user expected. It is not “user fault”; it is a design signal.
• Use specification: who the intended users are, what they will use the device for, and where and under what conditions.
• Hazard-related use scenario: a sequence of user actions that could lead to a hazardous situation.
• Critical task: a task that, if performed incorrectly or not performed, could cause serious harm. FDA places particular weight on these.
• Formative evaluation: testing during development to find and fix problems.
• Summative evaluation: the final validation test that shows the finished user interface can be used safely. FDA calls it human factors validation testing.

The usability engineering process step by step

1. Prepare the use specification

Describe intended users (for example nurses, surgeons, lay patients, carers), their training and abilities, the intended medical indication, the use environment (noisy ICU, home, ambulance) and the operating principle. Different user groups usually need separate analysis.

2. Identify user interface characteristics related to safety and known use problems

List every point where the user interacts with the device: controls, displays, alarms, packaging, labels, instructions for use, connectors and software screens. Review complaints and incident reports for the same or similar devices, and published literature, for known use problems.

3. Identify hazards, hazardous situations and hazard-related use scenarios

Perform a use-related risk analysis that asks, for each task, how it could go wrong and what harm could follow. Link every item to your ISO 14971 risk file so there is one risk system, not two.

4. Select scenarios for summative evaluation and write the user interface specification

Choose the hazard-related use scenarios that need final validation, usually those with serious potential harm. The user interface specification records requirements such as display size, alarm behaviour or connector design, and these become design inputs under design controls.

5. Design, then run formative evaluations

Test early and often. Paper mock-ups, prototypes and walkthroughs with real users cost little and reveal problems cheaply. Record what you learned and what you changed. Auditors like to see that formative findings actually shaped the design.

6. Run the summative evaluation (human factors validation)

Test the final or production-equivalent device with representative users, in realistic conditions, without coaching during the task. FDA’s guidance recommends at least 15 participants from each distinct user group in a human factors validation test. Analyse every use error, close call and difficulty, find the root cause and decide whether a further design change is needed. Where residual risk remains, the conclusion must explain why it is acceptable.

What goes in the usability file

Document	What it shows
Use specification	Users, uses, environments
Use-related risk analysis	Tasks, failure modes, harms, controls
User interface specification	Requirements that become design inputs
Formative evaluation reports	Findings and design changes over time
Summative evaluation protocol and report	Final proof that critical tasks can be done safely
Instructions for use and labelling	The residual-risk information supplied to users

Risk controls: the hierarchy matters

ISO 14971 expects risk control in a set order: inherently safe design first, protective measures second, and information for safety last. For use errors this means a connector that physically cannot be attached wrongly beats a warning label every time. A warning or an instruction is the weakest control, and summative results often show why. When a use-related hazard is “controlled” only by a sentence in the manual, expect questions from auditors and reviewers.

Common mistakes

• Doing usability testing once, at the end. A failed summative test late in development is expensive. Test formatively from the first prototype.
• Treating use error as user fault. “Operator error” is not a root cause. Ask why the design made the error likely.
• Using the wrong participants. Testing engineers instead of real nurses or patients produces misleading results.
• Coaching participants. Training in the test must match the training users will really receive.
• Keeping usability separate from risk management. Use-related risks belong in the same risk management file.
• Forgetting post-market data. Complaints about difficult use should feed back into the usability file; see post-market surveillance.

Software and connected devices

For software, the user interface is the device. Alarm fatigue, unclear units, ambiguous colour coding and confusing workflows have all led to harm. Where software is a medical device, align usability with your lifecycle process (see software validation and our SaMD training) and consider cybersecurity-related usability such as login and update flows (medical device cybersecurity).

How this fits with submissions

For the United States, human factors information is part of many 510(k), De Novo and PMA submissions (see US FDA regulations and the 510(k) submission process). For the EU, the usability engineering file supports compliance with the relevant GSPRs inside the technical documentation. Interviewers often ask about it; our product development engineer interview guide includes a usability case study.

Frequently asked questions

Is IEC 62366-1 mandatory?

The standard is voluntary, but it is recognised as a way to demonstrate compliance with EU requirements and FDA recognises it for submissions. Following a recognised process makes compliance far easier to show.

How many participants do I need for a summative test?

FDA’s guidance recommends at least 15 participants per distinct user group. The right number also depends on the risk and the variety of users, so justify your plan in the protocol.

What is the difference between verification and summative evaluation?

Verification checks that design outputs meet design inputs. Summative evaluation checks, with real users, that the device can be used safely and effectively. Both sit within design controls.

Do instructions for use count as a risk control?

Yes, but as the weakest form, information for safety. You must still show through testing that users read and understand the information that matters.

Talk to the AptSkill team

Want practical training on usability, design controls or risk management for your team? Send us a message.