Human factors and usability engineering for SaMD, wearables and health apps: FDA HF guidance, IEC 62366-1, formative vs. summative testing

The short answer

FDA expects you to find the user tasks where a use error could cause serious harm (critical tasks), reduce those risks mainly through design, and then show with human factors (HF) validation testing that representative users can do those tasks safely on the final design. Formative evaluations shape the design along the way; HF validation testing (often called summative testing) confirms it at the end. What you submit depends on your HF Submission Category under FDA's May 2026 final content guidance. IEC 62366-1, which FDA recognizes, describes the same usability engineering process.

This applies to software as a medical device (SaMD) and apps as much as to hardware. FDA's HF guidance names “Graphic user interfaces of device software systems” as part of the user interface, and calls out size and shape as “particularly a concern for hand-held and wearable devices.”

Sources: FDA guidance: Applying Human Factors and Usability Engineering to Medical Devices (Feb 2016, revised Aug 2026); FDA final guidance: Content of Human Factors Information in Medical Device Marketing Submissions (May 2026). This page is a summary, not regulatory advice for a specific device.

Two FDA guidances, both updated in 2026

Applying Human Factors and Usability Engineering to Medical Devices is the “how to do it” guidance. It was first issued on February 3, 2016, and FDA revised it on August 3, 2026, updating the definitions and the documentation section for consistency with the new content guidance.

Content of Human Factors Information in Medical Device Marketing Submissions is the “what to submit” guidance. FDA issued the draft on December 9, 2022 and the final version on May 29, 2026. It covers 510(k), De Novo, PMA and HDE submissions. For submissions received before August 1, 2026, FDA said it generally did not expect the newly recommended information, though it will review it if included.

Sources: FDA HF guidance; FDA HF content guidance; Federal Register notice, May 29, 2026.

Key terms

• Critical task: “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.”
• User interface: “all points of interaction between the product and the user(s)”, including displays, controls, packaging, labels and instructions for use. Labeling and training count.
• Use-related risk analysis (URRA): the task-by-task analysis of possible use errors, their harms and severity, and the risk controls for each.
• HFE vs. UE: FDA treats human factors engineering and usability engineering as interchangeable terms.

FDA puts severity ahead of probability. Because the probability of a use error is hard to estimate before a device is in use, “the severity of the potential harm is more meaningful” for deciding what needs attention.

Sources: FDA HF guidance, sections 2 and 3; FDA HF content guidance.

Formative vs. summative testing

FDA warns that “If no formative evaluation is conducted and design flaws are found in the human factors validation testing, then that test essentially becomes a formative evaluation.” Think-aloud is useful in formative work but “is not acceptable in human factors validation testing because it does not reflect actual use behavior.” FDA also notes that “summative testing can be defined differently and some definitions omit essential components of human factors validation testing,” so use FDA's definition when you plan the study.

FDA cites research in which 15 test users found at least 90% of usability problems. FDA describes validation as “primarily a qualitative rather than a quantitative exercise.” You do not pass by hitting a success rate. You pass by explaining every use error and showing that the remaining risk is acceptable. Saying you will fix problems “in subsequent versions of the device is not acceptable.”

Source: FDA HF guidance, sections 3, 6.4.3, 8 and Appendix A.

Which HF Submission Category are you in?

FDA's final content guidance uses four decision points. Is this a modification? Did the user interface, users, uses, use environments, training or labeling change? Does the URRA show critical tasks (or new or impacted ones for a modified device)? And, considering history of use, interface complexity and how well existing risk controls work, should validation data be submitted?

FDA's examples are useful for software. A change to a lesion-detection algorithm with no change to the interface, labeling or training lands in Category 1. Adding pediatric users to a cleared continuous glucose monitor lands in Category 3, because existing critical tasks now have a new user group. FDA says validation data are likely needed for complex interfaces and for device types with known use-error problems.

Source: FDA HF content guidance, section IV and Appendix A (FDA's hypothetical examples, not rulings on real devices).

What goes in an HF/UE report

For a Category 3 submission, FDA's outline has eight sections. Categories 1 and 2 use the first one or first four.

1. Conclusion and high-level summary, including any use-related residual risk and why more risk control isn't possible or practical.
2. Intended users, uses, use environments and training, including meaningful differences between user groups.
3. Device user interface: images, description, labeling, and the operational sequence. For modified devices, a comparison with the existing device.
4. Known use problems with earlier versions and similar devices, and fixes made in response.
5. Preliminary analyses and formative evaluations: methods, key results, design changes, and what informed the validation protocol.
6. URRA: for each task, possible use errors, hazardous situation, harm, severity, whether it is critical, risk controls, and how each control was validated. For modified devices, a comparative URRA.
7. Critical tasks: how you identified them, the list, severity categories, and use scenarios.
8. HF validation testing: why you chose simulated use, actual use or a clinical study; environment; number and type of participants; training; tasks and scenarios; definitions of success; data methods; results including use errors, close calls and difficulties; interview feedback; analysis of all use errors; design changes; benefit-risk; residual risk; and the full protocol, scripts and forms appended.

Keep this information even when you don't submit it. Under the Quality Management System Regulation, design validation is required for class II and III devices and for class I devices “automated with computer software”, and FDA recommends HF information be maintained “regardless of whether it is submitted”.

Sources: FDA HF content guidance, section V and Appendix C; 21 CFR 820.10 (QMSR).

Use errors to look for in wearables and apps

The rows below are our own illustrations of the kinds of use errors a URRA for a wearable or companion app might list. They are not taken from FDA documents or from any specific device. Whether a task is critical depends on the harm it could cause for your device and users.

FDA's HF guidance asks you to think about use environments such as homes, community settings and “moving vehicles”, and about user characteristics including sensory abilities and health literacy. Wearables and apps often hit all of these at once.

Source for environments and user characteristics: FDA HF guidance, section 5. Table rows are illustrative.

Where IEC 62366-1 fits

IEC 62366-1:2015+AMD1:2020, “Medical devices – Part 1: Application of usability engineering to medical devices”, sets out a process for a manufacturer to analyze, specify, develop and evaluate the usability of a medical device as it relates to safety. Per the IEC catalog, it covers risks from correct use and use errors (normal use). It can identify risks from abnormal use but does not assess or mitigate them. It is closely tied to ISO 14971 risk management. The consolidated edition 1.1 was published on June 17, 2020.

FDA recognizes the complete standard (recognition number 5-129), including the identical ANSI/AAMI adoption. Following IEC 62366-1 and following FDA's guidances overlap heavily, but FDA's documents add US specifics, such as the 15-participant minimum and US-resident participants.

Sources: IEC 62366-1:2015+AMD1:2020 (IEC catalog page); FDA recognized consensus standard 5-129; FDA HF guidance.

Practical checklist

• Write down your intended users, uses and use environments first. Treat lay users, clinicians and caregivers as separate user groups if their abilities differ.
• Build the URRA early and keep it current. Rank tasks by severity of harm, not likelihood.
• Run formative rounds on prototypes, and fix problems in the design before you rely on labeling or training.
• Freeze the user interface, labeling and training before HF validation testing.
• Consider sending a draft validation protocol to FDA through a Pre-Submission, as FDA encourages.
• Test every critical task with at least 15 representative users per user group, under realistic conditions.
• Analyze every use error and close call for root cause, and document residual risk.
• Work out your HF Submission Category for each submission, including software updates.

Sources: FDA HF guidance; FDA HF content guidance. The checklist is our practice summary.

Related resources

• SaMD regulatory consulting
• Healthcare mobile app development
• Wearables and neurology
• Is my app a medical device?
• Sensor accuracy validation
• FDA cybersecurity (section 524B)