Human Factors in Medical Device Design: Why the Work Pays Off Early

A nurse programs an infusion rate wrong. A patient at home misreads a display and skips a dose. A technician assembles two components in the order that feels natural instead of the order the instructions specify.

None of those are device failures in the engineering sense. Everything worked as designed. And FDA’s position is that the design is exactly where to look. The agency locates use-related hazards in “aspects of the user interface design that cause the user to fail to adequately or correctly perceive, read, interpret, understand or act on information from the device.” The user did what the design invited them to do.

Human factors and usability engineering is the discipline that catches those invitations before a device ships. It is design work, done early, by people who watch users rather than ask them. This article covers what that work involves, what it costs to skip, and how the regulatory framework has shifted to reward teams that do it up front.

---

Key Takeaways

• Use error is a design finding, not a user finding. FDA attributes use-related hazards to the user interface design rather than to the person operating the device.
• The human factors process runs across the whole program: a use-related risk analysis early, formative evaluation throughout design, and validation testing at the end. Only the last one is a test in the conventional sense.
• NASA’s analysis of error cost escalation puts a requirements error found at integration and test at 21 to 78 times the cost of finding it at requirements. Summative usability testing is a device program’s integration and test.
• FDA recommends a minimum of 15 participants for validation testing, per distinct user group, and states the number could be higher for specific device types. It is a practical floor rather than a statistical target.
• FDA revised both of its human factors guidances in 2026, and the new framework lets manufacturers justify their way out of submitting validation data using evidence that only exists when early design work was done.
• Under the Quality Management System Regulation, FDA’s guidance is explicit that “human factors validation testing represents one portion of design validation.” Usability lives inside design controls, not beside them.

---

The Design Problem Hiding Inside a “User Error”

The instinct when a device is misused is to fix the training or sharpen the instructions. That instinct is usually wrong, and the definitions FDA uses make clear why.

A use error is “user action or lack of action that was different from that expected by the manufacturer and caused a result that (1) was different from the result expected by the user and (2) was not caused solely by device failure and (3) did or could result in harm.” Notice what is absent: any notion of the user being careless. A use error is a mismatch between what the design communicated and what the user understood.

A critical task is “a user task which, if performed incorrectly or not performed at all, would or could cause serious harm to the patient or user, where harm is defined to include compromised medical care.” That last clause is the one teams under-apply. Harm is not limited to physical injury. A delayed diagnosis, a missed therapy, and a misread result all qualify, which means the list of critical tasks on most devices is longer than the first draft suggests.

Solid industry-wide numbers on use error are harder to find than the circulating percentages imply, and worth being careful with. FDA publishes no prevalence statistic, and MAUDE’s product problem taxonomy does not support a clean query for it. The best available peer-reviewed figure comes from Knisely and colleagues, who found that use error constituted 28.1% of adverse event reports labeled with device problem codes across MAUDE data from 2010 through 2018. The authors note directly that “publicly available statistics are sparse.”

Clinical practice points the same direction. ECRI’s Top 10 Health Technology Hazards for 2026 lists “Technology Designs or Configurations That Prompt Unsafe Clinical Workflows” at number nine, describing the mechanism plainly: “When devices or device configurations fail to support appropriate processes, device users may be forced to adapt workflow to the technology.”

---

What the Work Actually Involves

Human factors engineering is frequently mistaken for a test you run near the end. The test is one piece, and it is the last piece.

Use-related risk analysis comes first. FDA defines it as “systematic use of available information to identify use-related hazards and to estimate the use-related risk.” This is analysis, not testing, and it happens while the interface is still a set of decisions. It produces the list of critical tasks that everything downstream depends on.

Formative evaluation runs throughout design. FDA describes it as “user interface evaluation conducted with the intent to explore user interface design strengths, weaknesses, and unanticipated use errors.” Formative work is deliberately informal and iterative, and FDA sets no sample size for it, noting only that it “can be conducted with varying degrees of formality and sample sizes, depending on how much information is needed to inform device design.” A paper prototype in front of five nurses counts. So does watching two technicians attempt an assembly.

Human factors validation testing comes at the end, “conducted at the end of the device development process to assess user interactions with a device user interface to identify use errors that would or could result in serious harm.” This is the summative study, run on a representative device with representative users in a realistic environment.

The sequence matters more than any individual activity. A program that runs only the validation study is using an expensive, late-stage test to discover problems that formative work would have surfaced months earlier for a fraction of the cost.

---

The Cost of Finding It Late

NASA’s study of error cost escalation across project life cycles quantifies what “late” costs on complex hardware programs. Setting the cost of fixing a requirements error during the requirements phase at 1 unit, the cost rises to 3 to 8 units at design, 7 to 16 units at manufacturing and build, and 21 to 78 units at integration and test.

Summative human factors validation is a device program’s integration and test. A use-related design flaw found there sits in that 21-to-78 band, and it arrives after design freeze, after tooling, with a submission timeline attached. The same flaw found during formative evaluation sits in the 3-to-8 band, at a point where the interface can still change without re-verification cascading through the design history.

That is the entire economic argument for human factors work, and it holds independent of any regulatory requirement.

---

About the 15-Participant Number

The most-repeated figure in medical device human factors deserves a careful reading, because it is widely misapplied.

FDA’s guidance states that “in general, the minimum number of participants should be 15,” and immediately adds that “the recommended minimum number of participants could be higher for specific device types.” The reasoning appears in the appendix: a sample of 15 “constitutes a practical minimum number of participants for human factors validation testing. This sample size theoretically provides the best possibility of detecting user interface design flaws while limiting the amount of resources needed.”

Two clarifications keep programs out of trouble. The number applies per distinct user group rather than per study, so a device used by both clinicians and patients carries two groups and 30 participants. And FDA presents it as a resource-constrained floor, not a statistically derived sample size, which means a complex interface or a device type with known use-error history warrants more than the minimum.

---

What the 2026 Regulatory Changes Reward

FDA moved on human factors twice this year, and both moves favor teams that front-load the work.

In May 2026 the agency finalized its guidance on the content of human factors information in medical device marketing submissions, four years after the draft. On August 3, 2026, FDA reissued Applying Human Factors and Usability Engineering to Medical Devices, the first substantive revision since 2016, updating definitions and revising the documentation section for consistency with the May guidance.

The submissions guidance routes a device to a submission category through a sequence of decision points. The first three cover whether the device is a modification, whether the user interface or its users and environments changed, and whether critical tasks are new or affected. A fourth decision point is the addition, and it is the one that matters for planning. It asks whether validation data should be submitted given the user interface history of use, the complexity of the interface, and the adequacy of existing risk control measures.

That fourth question did not appear in the 2022 draft. Its arrival means a manufacturer can, in some cases, offer a justification in place of new validation data. FDA also encourages leveraging prior submission content and existing human factors results rather than duplicating work.

Here is the part worth planning around: every argument that fourth decision point accepts is evidence produced earlier in the program. A documented use-related risk analysis, formative testing records showing where the interface was simplified, and a traceable link from use-related hazards into risk controls are what make a justification credible. A program that ran no formative work arrives with nothing to argue and lands in the most demanding submission category by default.

---

Where Usability Sits in Your Design Process

The Quality Management System Regulation became effective February 2, 2026, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. The August 2026 human factors guidance was updated in part to align with it.

The relationship FDA describes settles a question many teams get wrong: “Human factors validation testing represents one portion of design validation.” Usability is not a parallel workstream running beside design controls, and it is not a consultant’s report filed separately. The evidence belongs in the design and development file alongside everything else.

The standards reinforce the same structure. FDA recognizes IEC 62366-1 Edition 1.1 in full under recognition number 5-129. The standard specifies a process to “analyse, specify, develop and evaluate the usability of a medical device as it relates to safety,” and it links directly to ISO 14971, currently in its third edition. Use-related hazards feed the same risk file as every other hazard, which is the practical reason human factors and risk management work best when the same team sees both.

---

What Is Coming for Connected and AI-Enabled Devices

Two developments are worth watching. FDA’s draft guidance on AI-enabled device software functions, issued January 7, 2025 and still in draft, carries substantial human factors content. It states that manufacturers “should demonstrate users’ ability to interact with and understand the device as intended in addition to ensuring the device itself meets relevant performance specifications,” drawing a clear line between performance validation and human factors validation.

Separately, IEC has a technical specification in committee draft, IEC/CD TS 62366-3, covering usability engineering for medical devices using artificial intelligence and machine learning, with a stage date of August 2026. Guidance for AI-enabled interfaces is being written now, which makes this a good moment for teams building those products to establish the underlying practice.

---

Where DISHER Engineering Can Help

Human factors work delivers most of its value at the front of a program, when the interface is still a set of decisions. That is the same point where human-centered design does its best work, and the two disciplines use most of the same methods.

Our Innovation & Design practice covers user research, journey mapping, and product requirements, the inputs a use-related risk analysis depends on. Conceptual design work brings user testing and prototyping into the stage where changes are still cheap. From there, Product Development carries the design into a documented, buildable form with the usability evidence attached rather than reconstructed.

We jump in where you need us. That might be a use-related risk analysis on a device already in development, formative testing on an interface that has never been put in front of a real user, or a design team that needs the human factors thinking embedded rather than delivered as a report.

Start the conversation here.