What Is IEC 62366-1 and What Does It Require for Usability?

Medical devices fail users in small, everyday moments. Some might have a confusing button or alarm, while others might have a label that’s easy to misread. Such moments are critical in healthcare, where user error can mean the difference between successful treatment and serious harm. IEC 62366-1 is aimed at catching these issues before a device ever lands in the hands of a patient or clinician.

Key Takeaways

• IEC 62366-1 sets the requirements for usability engineering in medical devices, while IEC 62366-2 offers non-binding guidance on how to apply them.
• Before they even begin designing any device, manufacturers must define intended users, use environments, and the user interface.
• The risk management process requires the identification and documentation of use-related hazards, critical tasks, and risk controls.
• Formative testing happens during design, while summative validation confirms the final product is safe for real users.
• The FDA recognizes IEC 62366-1 as a consensus standard, meaning a documented usability engineering process can support your submission.
• Working with IEC 62366-1 compliance consultants can help you build a Usability Engineering File that holds up to regulatory review.

What IEC 62366-1 Covers and How It Differs From IEC 62366-2

IEC 62366-1 is the standard that lays out requirements for applying usability engineering to medical devices. This standard provides manufacturers with a structured, repeatable process for analyzing, specifying, developing, and evaluating how users interact with a device’s interface. Think of it as the rulebook: if you want to demonstrate a defensible usability engineering process, this is the document that spells out what you must do.

On the other hand, IEC 62366-2 is a technical report rather than a set of requirements. It provides background context and practical guidance on how to carry out the process described in part one. Many teams treat IEC 62366-2 as a companion resource. It’s essentially a how-to guide that accompanies the requirements set forth in part one.

Here’s the distinction in short: IEC 62366-1 tells you what you must do; IEC 62366-2 helps explain how to do it. Both parts work together, but only IEC 62366-1 is the standard your usability engineering file must conform to.

The FDA lists IEC 62366-1, including the consolidated version with Amendment 1, as a recognized consensus standard. This means that following it correctly and documenting your process can support a declaration of conformity in your premarket submission. That said, you’ll still need to provide the underlying evidence and documentation. Many manufacturers choose to work with IEC 62366-1 compliance consultants specifically to build submission-ready documentation that meets FDA expectations the first time.

How Manufacturers Define Intended Users, Use Environments, and the User Interface

Every usability engineering process under IEC 62366-1 starts with a use specification. Before a single design decision gets made, manufacturers must clearly define three things:

Intended users. Who will actually operate this device? A surgeon and a patient using it at home bring very different skill levels, training, and expectations to the same interface.

Use environments. Where will the device get used? An operating room, a home bathroom, and a moving ambulance each introduce their own lighting, noise, and stress conditions that affect how someone interacts with a product.

User interface. This includes far more than screens and buttons. It encompasses labeling, packaging, and instructions for use, since all of these shape how a user understands and operates the device.

Getting this foundation right sets the direction for everything that follows. Skip or rush this step, and later risk analysis and testing will rest on shaky assumptions. This is often where IEC 62366-1 compliance consultants add the most early value, since a poorly scoped use specification can quietly derail months of downstream work.

How Use-Related Hazards and Critical Tasks Must Be Identified and Controlled

Once the use specification is in place, manufacturers must identify use-related hazards. Essentially, they must consider how a user could interact with the device incorrectly and what harm might result from that. This work connects directly to your broader risk management process under ISO 14971, so severity and probability assumptions should reference that existing analysis rather than starting from zero.

From there, manufacturers identify and categorize critical tasks. These are the specific actions that could cause serious harm if performed incorrectly or skipped entirely. Not every task carries equal weight, and part of this process involves documenting the rationale for why certain tasks earn the “critical” label.

Once hazards and critical tasks are mapped, risk control measures come next. These might include:

• Design changes that make an error physically difficult to make
• Interface changes such as clearer labeling or improved alarm design
• Training programs for intended users
• Warnings or instructions built directly into the labeling

A simple traceability matrix linking each hazard or use error to its control measure and the evidence confirming it works makes this entire process far easier for regulatory reviewers to follow. IEC 62366-1 compliance consultants frequently build this matrix as a core deliverable since it becomes the backbone of your usability engineering file.

What Formative Testing, Summative Validation, and Usability Documentation Are Needed

IEC 62366-1 requires two distinct forms of usability testing, each serving a different purpose.

Formative evaluations happen while the device is still in design and development. These sessions explore various design options, catch safety concerns early, and inform iterative changes to the interface. You’ll likely run several formative evaluations across a development cycle as the design matures.

Summative evaluations happen later, during design validation. This testing is more rigorous by design: the goal is to demonstrate that the final user interface is safe. Testing must involve representative end users engaging with the actual final design under realistic conditions.

If summative testing surfaces unacceptable use-related risks or introduces new risks that weren’t previously identified, manufacturers must return to the risk control step and address the gap before moving forward.

All of this work needs documentation in a Usability Engineering File, which typically includes:

• The use specification (intended users, environments, and interface definition)
• Use-related risk analysis
• Critical task analysis with rationale
• Formative evaluation plans and reports
• The summative evaluation plan and report
• A traceability matrix connecting hazards to controls to evidence

A complete, well-organized file makes regulatory review smoother and gives your team a clear record to build on for future design changes.

Building Usability Compliance Into Your Product Roadmap

IEC 62366-1 asks manufacturers to think about the user at every stage of development, not as an afterthought bolted on before submission. Define your users and environment early, track hazards and critical tasks alongside your risk management work, run formative testing to catch problems while design changes are still cheap, and validate with summative testing before you finalize the product.

When this process is done well, it reduces use errors, strengthens your regulatory submission, and protects the people who will eventually rely on your device. If your team needs support building a usability engineering file that meets FDA and international expectations, working with experienced IEC 62366-1 compliance consultants can help you move through each step with a clear plan and fewer surprises. Schedule a consultation with MedLaunch to talk through where your device stands today and what the path to compliance looks like for your team.

Tags: IEC 62366-1, IEC 62366-2, medical device compliance