How to read a human factors validation report

A human factors validation report is supposed to answer one question: can the people who will actually use this device use it safely, without excessive training, under conditions like the ones they’ll actually face? Reading one well means checking whether the test really answered that question — not just whether it happened.

What the report has to connect

Start with the use-related risk analysis, because everything downstream depends on it: it identifies the ways the device could foreseeably be used incorrectly and what harm could follow, and from that analysis comes the critical tasks list — the specific steps that, done wrong, could hurt someone. The validation test itself has to exercise exactly those tasks, with participants who actually represent the intended users, not whoever was easiest to recruit — if the device is meant for lay caregivers, testing it on experienced clinical staff doesn’t validate anything about the population that will actually use it. The conditions matter too: real labeling as it will ship, no extra coaching beyond what a real user would get, an environment that resembles actual use rather than a quiet conference room. What comes out the other side is a record, participant by participant, of what happened — every use error, every close call, every task that took longer or went differently than expected — each one followed by a root cause analysis that says whether the problem was the design, the labeling, or something about how a specific participant approached the task. FDA’s own human factors guidance lays out this structure in detail, and it’s worth reading directly rather than relying on a summary of it. The validation itself sits inside the broader design validation record — now organized, under the QMSR, around ISO 13485:2016’s clause 7.3 rather than the old Part 820 subpart letters — alongside the rest of the design history file.

What a thin report looks like

A few patterns show up reliably in reports that don’t hold up under a close read. The critical tasks list is missing something an outsider would flag immediately — a step that’s obviously risky but wasn’t formally called critical, which usually means it also wasn’t tested rigorously. The participant sample skews toward people who are easier to recruit than the real intended users — internal staff, experienced clinicians standing in for lay users, a sample too small or too homogeneous to say anything about the range of people who’ll actually use the device. And the root cause analysis, when a use error does show up, waves it away as simple user error without asking the harder question of why the design allowed that error to happen in the first place. Put together, these read less like a rigorous test and more like a document written to reach a predetermined conclusion — which is exactly the impression a careful reviewer will form too.

None of this changes once the device clears validation and moves toward submission. What changes is that the report stops being a working document for the design team and becomes evidence a reviewer will read cold — which is exactly why it has to stand on its own.