Human Factors Validation Testing: The Proven Procedure Fix

Human factors validation testing is the study you run at the end of device development to prove that real users can operate your device without committing use errors that would cause serious harm — and as of 2026, the record it produces belongs to your quality management system before it belongs to any submission. That relocation is the story. On May 29, 2026 the FDA finalized its companion guidance on what human factors information goes into a marketing submission. On August 3, 2026 it revised the underlying process guidance to match. Between those two dates, the filing burden got lighter for some devices and the records burden got heavier for every device. Most device procedures have no text for the second half of that trade.

This guide is written for quality and regulatory managers who now have to decide what their procedures should say. It walks the three dates that changed the picture, explains what human factors validation testing actually requires, maps the requirement onto four ISO 13485 procedures clause by clause, and names the specific sentences most procedures are missing. MSI's wider treatment of the clause architecture these procedures sit inside is in the guide to ISO 13485 design and development.

The Regulatory Shift

Why Human Factors Validation Testing Changed in 2026

Finalized. Revised. Relocated.

Three dates moved human factors validation testing from a submission question to a quality system question. None of them created a new requirement. Together they moved an existing one to a place most organizations were not looking.

That last item is the one worth pausing on, because it is easy to read as housekeeping. It is not. FDA signaled the plan back in the December 2022 draft notice: on finalization it intended to revise the process guidance by replacing the Documentation section and the report appendix, and to supersede the definitions. The report outline that told you how to write up human factors validation testing left the document that explains how to run it and moved into the document that explains what to file. Read the two guidances side by side and the division of labor is now explicit: one is method, one is submission content. Neither one is your procedure. See the 2022 draft notice and the 2026 final notice for FDA's own statement of the sequence.

The eSTAR consequence

The framework did not stay on paper. FDA's electronic Submission Template and Resource program is the interactive template through which 510(k) and De Novo submissions are assembled, and the revised non-IVD and IVD templates prompt submitters to identify their Human Factors Submission Category and supply content accordingly. A category assignment is now a field someone has to fill in. Behind that field sits a use-related risk analysis and a critical task list that either exist in your quality system or do not. Organizations that treated human factors validation testing as something the consultant handled at the end of the project now have a structured prompt asking them to classify their own device.

The final guidance added a decision point that helps submitters determine whether data from human factors validation testing should be submitted in a marketing submission at all. For some modified devices, the answer is now no. And in the same breath, FDA footnoted the QMSR — its requirements to verify and validate the device design — with the recommendation that human factors information be maintained by the manufacturer regardless of whether it is submitted. Practitioners read that pairing the way MSI reads it: relief at the submission gate, exposure at the inspection. MSI's full treatment of what the QMSR changed is in the analysis of the FDA QMSR rule and ISO 13485 alignment.

The Method

What Human Factors Validation Testing Actually Requires

Users. Tasks. Conditions.

The FDA guidance is unusually specific about design. Human factors validation testing is conducted to demonstrate that the device can be used by its intended users without serious use errors or problems, for the intended uses and under expected use conditions. human factors validation testing has to be comprehensive in scope, sensitive enough to capture use errors caused by the design of the user interface, and performed so the results generalize to actual use. Those are three separate obligations and procedures routinely address only the first.

Critical tasks are the spine

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 includes compromised medical care. Everything in human factors validation testing hangs off that list. The critical task list comes out of preliminary analyses: task analysis, heuristic evaluation, expert review, contextual inquiry, interviews, and formative evaluation, informed by known use-related problems drawn from sources such as the MAUDE adverse event database and the MedSun safety network.

The guidance is explicit that the critical task list is dynamic. It changes as the design evolves, and additional critical tasks are likely to be identified as user interactions become better understood. A procedure that treats the critical task list as a one-time deliverable produced at design input and never revisited has already broken the chain that human factors validation testing depends on. This is the same structural problem MSI documents in medical device threat modeling, where a rationale artifact gets produced once and never re-enters the design record.

Participants, and the number fifteen

Manufacturers running human factors validation testing make their own determination of sample size, but the guidance states that in general the minimum should be 15 participants — and if the device has more than one distinct population of users, at least 15 from each. FDA views user populations as distinct when their characteristics would likely affect their interactions with the device or when the tasks they perform differ. Pediatric and adult users are distinct. Professional healthcare providers and lay users are distinct. Installers, providers with unique specialties, and maintenance personnel can each be distinct.

The number is not arbitrary and it is not statistical. It traces to Faulkner (2003), which found that a sample of 15 detected a minimum of 90 percent and an average of 97 percent of known problems, with detection improving asymptotically beyond that — an average of fewer than two additional percentage points at 30 participants. The earlier work it responded to is Virzi (1992). FDA is clear that human factors validation testing is primarily qualitative rather than quantitative: the purpose is not to quantify how often a use error occurs but to identify the part of the user interface involved and investigate why.

Two of those rows carry more weight than they look. Employees generally should not serve as participants in human factors validation testing, because of the bias they introduce — and for the results to demonstrate safe and effective use by users in the United States, the participants should reside in the United States, with exceptions considered case by case on a sound rationale. Training is the other constraint human factors validation testing places on study design. Whatever training actual users would receive is the training participants get, delivered in comparable content, format, and method — and because training decays, testing should not occur immediately after it.

Simulated use, actual use, and where the line sits

Most human factors validation testing is conducted under simulated use. Actual-use testing becomes necessary when simulated methods cannot adequately evaluate the interaction — a prosthetic limb, a hearing aid programming device, a home dialysis machine whose conference-room results would not generalize to a residence. Actual-use human factors validation testing follows the same general design rules, and where it is needed to determine safety and effectiveness it can trigger the investigational device exemption requirements at 21 CFR Part 812. FDA encourages submitting a draft human factors validation testing protocol in advance through the Q-Submission program before the study runs.

The Procedure Impact

Four ISO 13485 Procedures That Now Need New Text

Design. Risk. CAPA. Contract.

ISO 13485:2016 predates the current framework and contains no clause that says “human factors validation testing.” It does not need one. What it requires is that design inputs include applicable regulatory requirements and the applicable outputs of risk management, that design validation demonstrate the device meets user needs and intended use, that changes be evaluated for their effect, and that feedback and corrective action operate as a closed loop. The human factors validation testing obligation enters through those doors. The consequence is that it enters your procedures, not your submission checklist.

MSI's position on why this pattern recurs is set out in the pillar on the design and development procedure: most device organizations inherited their procedure from a quality base, and the requirements with no ISO 9001 counterpart are precisely the ones that get lost in adaptation. Human factors validation testing is a textbook instance. ISO 9001 has no medical device user, no critical task, and no serious harm threshold, so a procedure built by renumbering Clause 8.3 has nowhere to put any of it.

Procedure one — design and development, Clause 7.3

Three sub-clauses carry the load. Clause 7.3.3 requires design inputs to include functional, performance, usability and safety requirements according to intended use, applicable regulatory requirements, and applicable outputs of risk management. Usability is named in the standard's own text. A procedure that lists human factors validation testing inputs generically and never names usability requirements as a category has already lost the thread that human factors validation testing is supposed to close.

Clause 7.3.7 requires design validation to demonstrate that product meets requirements for the specified application or intended use. FDA states directly that human factors validation testing represents one portion of design validation. Your procedure should say so in those words, because the alternative — a human factors validation testing study filed in a parallel folder, referenced nowhere in the validation plan — is exactly the structure an investigator reads as a design validation record with a hole in it.

Clause 7.3.9 governs changes, and it is where human factors validation testing becomes an ongoing obligation rather than a milestone. When a marketed device is modified, the risk management process should cover all aspects that were modified and all elements affected by the modification, including the users' interactions affected directly or indirectly. Whether an additional round of human factors validation testing is required is a risk-based decision — and the procedure needs to name who makes it, against what criteria, and where the rationale is recorded.

Procedure two — risk management, Clause 7.1 and ISO 14971

Use-related risk analysis is the upstream half of human factors validation testing. Use-related risk analysis for human factors validation testing is the systematic use of available information to identify use-related hazards and estimate the use-related risk, and it is what makes a critical task list defensible rather than assembled. FDA's guidance notes that because probability is very difficult to determine for use errors — and many cannot be anticipated until use is simulated and observed — severity of potential harm is the more meaningful basis for deciding whether to design out or reduce the resulting harm.

That is a genuine departure from ordinary risk practice, and most risk procedures do not accommodate it. A register whose scoring model multiplies severity by probability will systematically under-rank use-related hazards, because the probability column for a use error nobody has observed yet is a guess. The procedure needs a severity-led route for use-related hazards. MSI's treatment of criteria-based routing generally is in the pillar on the risk management procedure template.

The second gap is the control hierarchy. ISO 14971 lists risk control options in order of preference: inherent safety by design, then protective measures in the device or the manufacturing process, then information for safety. FDA is direct that design modification is generally the most effective means of eliminating or reducing use-related hazards, and that labeling and training are the least preferred because they rely on the user to remember or refer back, labeling may be unavailable during use, and training decays. A procedure that permits a team to select any control without documenting why the two stronger tiers were rejected will produce exactly the finding pattern described later in this guide. Implementation guidance sits in ISO/TR 24971, and the usability engineering process standard is IEC 62366-1.

Procedure three — feedback and corrective action, Clauses 8.2.1 and 8.5.2

Human factors validation testing does not end at design transfer. Clause 8.2.1 requires feedback from production and post-production activities to be gathered and used as an input to risk management and to product realization. A complaint that describes a user doing something the design did not anticipate is use-related feedback, and it is evidence that the critical task list was incomplete. The procedure needs an explicit route from that complaint back to the use-related risk analysis, not merely into the CAPA queue.

When a manufacturer modifies a marketed device in response to use-related problems — possibly as a corrective action or a recall — the guidance recommends a specific technique for the follow-up study. Evaluate the modified interface with the usual methods, but also solicit participants' direct comparison of the modification to the previous design: is the new design better, how effective will it be at preventing the use error, could the change cause any other difficulty, and is the modification sufficient. Building that into the procedure turns post-market human factors validation testing from an improvised exercise into a defined method. MSI's fuller treatment of the loop is in the guides to CAPA under ISO 13485 and writing a corrective action procedure.

Procedure four — customer-related processes, Clause 7.2

This is the one nobody expects. Clause 7.2.1 d) requires the organization to determine any user training needed to ensure specified performance and safe use of the medical device, and 7.2.2 d) requires confirming at requirements review that the training is available or planned. There is no ISO 9001 equivalent, so it is absent from most procedures adapted from a quality base — and it is the clause that carries the residual risk left standing after human factors validation testing has been completed and accepted. MSI's sales and contract review procedure template carries the device path explicitly for this reason.

The MSI Framework

The Use-Error Evidence Chain: Five Links That Have to Hold

User. Task. Control. Proof. Decision.

MSI built this after 200+ audits attended across regulated industries, because the failures cluster in a predictable place. Organizations rarely lack a human factors validation testing report. What they lack is a traceable path from the user population definition to the acceptance decision, which is the path an investigator walks. The chain is deliberately short. Five links is enough to find the break, and few enough that a design team will actually check it.

Link four is where most organizations are strongest and link three is where most are weakest. Link five is where the chain leaves the design team entirely. Residual risk acceptance is a leadership decision, and under ISO 13485 Clause 5.6 it belongs in the management review record alongside the other required inputs — which, since February 2026, is an inspectable record. MSI's clause-by-clause treatment is in the ISO 13485 management review playbook, and the measurement layer that turns these links into reportable numbers is covered in design control metrics and project management quality measurement.

The Categories

What Decision Point D Did and Did Not Change

Filed. Kept. Different.

The final guidance sorts submissions into three Human Factors Submission Categories using a risk-based flowchart, with the category driving how much human factors content the file carries — from a brief rationale at one end to full validation evidence at the other. The logic turns on whether the device is new or modified, whether the change affects use-related hazards, and whether critical tasks are added or affected. FDA's own summary of the framework and where it fits is on the human factors premarket information page, and the agency ran a town hall on the final guidance in July 2026.

Read only the submission half and the change looks like relief. Read both halves and it looks like a transfer. A lighter submission means a reviewer is less likely to examine your human factors validation testing — the practical effect being that fewer external eyes see your human factors validation testing before clearance — and an investigator is the one who examines it after. The people who see the evidence changed. The evidence did not.

There is a second-order effect worth planning for. Under the previous arrangement, the submission deadline functioned as an involuntary quality gate: the human factors validation testing package had to be assembled, and assembling it forced the underlying records into order. Remove the deadline for a subset of devices and that forcing function disappears. Nothing about the obligation weakened, but the schedule that used to enforce it did. Procedures now have to do the work the calendar was doing. MSI's broader view of how the QMSR reshaped inspection exposure is in the analysis of the FDA Voluntary Improvement Program, and organizations assessing where they currently stand often start with an ISO 13485 gap analysis.

The Rejected Answers

Two Responses FDA Will Not Accept After a Failed Study

Labeling. Training. Neither.

These are the two answers quality teams reach for when human factors validation testing goes badly under schedule pressure, and the guidance forecloses both. Stating in a submission that you mitigated the risk by revising the instructions for use or another element of labeling is not acceptable unless you provide additional test data showing the modified elements were effective. Stating that you intend to mitigate by providing additional training is not acceptable unless you provide data demonstrating it would be effective. A third variant fails the same way: identifying a design flaw that could cause harm and stating you plan to address it in a subsequent version.

The procedural consequence is precise. Your design and development procedure needs a defined path for what happens when human factors validation testing fails, and that path cannot terminate in a document revision. It has to route to design modification, then to re-evaluation, then — where the modified elements affect only some aspects of use — to focused re-testing of those aspects. Write the re-testing trigger into the procedure and the team stops negotiating it project by project.

What the guidance does accept

It is practically impossible to make a device error-proof, and some residual risk always remains. Residual risk after human factors validation testing is acceptable when the remaining risks have been thoroughly analyzed, further reduction of the errors' likelihood is shown not to be possible or practical, and the benefits of device use outweigh the residual risk. The guidance also recognizes test artifacts — use errors caused by conditions inconsistent with actual use, which may legitimately be designated as such. But it warns that an analysis containing many artifact explanations may indicate the test conditions affected participant behavior too significantly, and that re-testing under more realistic conditions may be necessary. Artifact is an available finding, not an available strategy.

Failure Patterns

Six Human Factors Validation Testing Failures MSI Sees

Repeated. Predictable. Preventable.

MSI client experience suggests these six account for most of the trouble organizations encounter with human factors validation testing. None of them is exotic. All six are procedure-shaped, which is the point of this guide.

The common thread across these human factors validation testing failures is that each is invisible while the system is running and obvious the moment someone traces a single hazard end to end. That is why MSI teaches the evidence chain as a tracing exercise rather than a checklist. Internal audit is the natural place to run it, and MSI's guidance on scoping is in internal audit planning. Building the auditor capability to do it is covered in the ISO 13485 2-Day Internal Auditor Training.

The Sequence

How to Revise Your Procedures Without Rework

Read. Map. Revise. Verify.

Order matters here for the same reason it matters across a procedure set generally, a subject MSI treats in the guide to ISO procedure order. Revising the design procedure alone creates references to a risk process that does not yet produce what the design procedure now expects. Revising all four together costs less than revising them sequentially and discovering the seams.

• Pass one — read the pair. The process guidance tells you how to run human factors validation testing and the wider human factors programme; the submissions guidance tells you what to file and, by implication, what to keep. Read them together and the division of labor is legible. Both are indexed in FDA's device guidance document library.
• Pass two — map to clauses. Every obligation lands somewhere in ISO 13485. Build the map before writing any text, so the procedure inherits the standard's structure rather than the guidance's.
• Pass three — revise the four together. Design and development, risk management, feedback and corrective action, and customer-related processes. Changing one without the others is how organizations generate the seams they later find at audit.
• Pass four — trace one hazard. Pick a real use-related hazard from a real device and walk it through the revised text along all five links of the evidence chain. If it reaches residual risk acceptance without a gap, the revision holds.

Two supporting standards are worth having open during pass two. IEC 62366-1 is the usability engineering process standard the FDA definitions align with, and IEC 62304 governs software lifecycle records where the user interface is software-driven — which, increasingly, it is. FDA maintains the current recognition status of consensus standards in its Recognized Consensus Standards Database, and checking the supplementary information sheet is the step teams skip.

Organizations that want the underlying discipline taught rather than delivered generally start with the Design and Development Training Video Series or, for a new device quality system, ISO 13485 Launch Mastery. Ongoing maintenance of the system once it is certified is what SureResults exists for, and organizations automating the document control layer around it will find MSI's view in ISO compliance automation.

The Bottom Line

Why Human Factors Validation Testing Is a Procedure Problem

Evidence. Ownership. Durability.

Nothing in 2026 made human factors validation testing harder to run. The human factors validation testing methods are the same methods, the fifteen-participant floor is the same floor, and the definition of a critical task did not move. What moved is who holds the obligation and where the evidence has to live. It used to live in a submission that a reviewer would open on a known date. It now lives in a quality management system that an investigator may open on an unknown one.

Quality systems hold things through procedures. That is the whole mechanism. A guidance document tells you what good practice looks like; a procedure is what makes your organization do it when the person who read the guidance has moved on. Organizations that respond to the 2026 changes by updating a submission checklist will have addressed the half of the change that got easier. Organizations that respond by revising four procedures will have addressed the half that got harder.

The organizations MSI sees handle this well share three habits. They treat the critical task list that drives human factors validation testing as a living controlled record rather than a design-phase deliverable. They require a written reason whenever a use-related hazard is controlled by information rather than by design. And they route residual risk acceptance to top management with a name attached, because an acceptance decision without an owner is not a decision. Those three habits are cheap to write into procedures and expensive to reconstruct at an inspection. Related MSI analysis on adjacent device topics is in medical device cybersecurity, digital health FDA compliance, remote patient monitoring compliance and ISO for additive manufacturing. Organizations running the risk file that feeds all of it may also want the ISO 13485 Risk Management Procedure Template, and those building the people side should see the human resource management procedure pillar.

Questions

Human Factors Validation Testing: Questions and Answers

Asked. Answered. Sourced.

What is human factors validation testing?

How many participants does human factors validation testing require?

Did the 2026 FDA guidance changes eliminate human factors validation testing for some devices?

Which ISO 13485 clauses does human factors validation testing map to?

Can we fix a failed human factors validation test by revising the instructions for use?

Does a modified device need new human factors validation testing?

Can employees participate in human factors validation testing?

Where should human factors validation testing records be kept?

This article summarizes publicly available FDA guidance and ISO standards for general educational purposes. Guidance documents represent FDA's current thinking and are not binding on FDA or the public. Confirm the current position of any requirement against the primary source before acting on it.