Explainer · Human factors · 16 min read
Human Factors Engineering, Demystified
Human factors engineering has a reputation: observation rooms, dozens of participants and a report nobody wants to write. Most of it is simpler than that. At its core it's a disciplined way to answer three questions about your device, and to prove the answer to the last one.
- 1Who will use it, for what, and where?
- 2What could go wrong when they use it?
- 3Can they do the tasks that matter, safely?
The example device in this post, the Nivra, is fictional. The regulations, standards and guidance cited are real.
What it actually is
Human factors engineering (HFE) is the study of how people interact with a device, applied to its design so that mistakes that could hurt someone become unlikely. IEC 62366-1, which most EU manufacturers follow, calls the same work usability engineering. FDA treats the two terms as interchangeable and often writes them together as HFE/UE.[1] Outside regulation, "human factors" is the broader field and "usability" describes a product. In device work, though, they mean the same process.
The part people miss is that it's about safety, not taste. IEC 62366-1 describes a process for usability as it relates to safety.[2] Whether users like the color scheme isn't the question. A device that feels a little clunky but is always used correctly is fine. A sleek one that invites a dangerous slip is not.
That makes HFE a branch of risk management. ISO 14971 asks you to consider risks from both intended use and reasonably foreseeable misuse.[3] HFE is how you find and control the ones that come through the user interface. That covers far more than screens and buttons: alarms, labels, packaging, instructions and training all count as part of it.[1]
Six fears, and what's actually true
Most of the dread around human factors comes from a few beliefs that are half true at best.
“It's a big lab study at the end of the project.”
Most of the work is analysis and small, informal tests while the design can still change. The one formal study, validation testing, comes at the end, and it should confirm what you already expect. If it surprises you, the earlier work was too thin.
“We'll need 15 participants for everything.”
FDA's general minimum of 15 applies to human factors validation testing, for each distinct user group.[1] FDA expects early, formative studies to vary in formality and size.[1] A handful of people per round is often enough to surface the problems that matter.
“Every task has to be tested.”
Validation centers on critical tasks, the ones where a mistake could cause serious harm. IEC 62366-1 has you choose which hazard-related use scenarios go into the summative evaluation.[1][2] Charging a battery or changing the display language rarely needs a formal study.
“If testing finds a problem, we'll add a warning to the instructions.”
FDA and the EU MDR both put warnings and training last. Design the problem out first, add protective measures second, and use information only for what's left.[4][1] FDA also won't accept “we updated the instructions” as a fix without test data showing the new instructions work.[1]
“This only applies to complex or home-use devices.”
Any device with a user interface needs it, but the effort scales. IEC 62366-1 lets you tailor the work to factors such as the size and complexity of the interface, how severe the possible harm is, how complex the use specification is, and how much of an existing, already-evaluated interface you've changed.[2]
“Every FDA submission needs a full validation report.”
Since FDA's final guidance of May 2026, submissions fall into three categories, and only the third includes validation test results. Plenty of modifications need only a short justification.[5]
The whole process on one page
Fictional example Meet the Nivra, a made-up device we invented for this post. It isn't a real product, and the studies and results below are illustrations, not data.
The Nivra is a handheld spirometer that adults with asthma, and parents of children with asthma, use at home with a phone app. You take a deep breath and blow out hard. The Nivra measures how much air you push out and how fast, and the app shows the result against green, yellow and red zones that your clinician sets in a web portal. A red result means: follow your asthma action plan now.
Here is the work in the order it happens. The steps follow IEC 62366-1,[2] and each one shows what the Nivra team did and how big the step really was.
- 1Describe users, uses and environments
- 2Learn from known problems
- 3Find what could go wrong
- 4Design, try it early, repeat↻ loop until it works
- 5Prove the critical tasks
- 6Write it up, keep it current
Step 1 · Use specification
Describe the users, uses and environments
Write down who will use the device, for what, where, and with what training. Every later decision depends on this page.
Nivra Fictional example
Three user groups who read and act on results: adults with asthma; parents who coach a child through the test and read the result; and clinicians who set the zones in the portal. Children aged about five and up do the blow themselves but don't read results, so they are in the use specification and in early testing too. The device is used at home, at any hour, sometimes while the person already feels breathless. The portal is used in clinics.
The groups matter later. FDA treats user groups as distinct when their characteristics would likely change how they interact with the device, for example because they do different tasks or have different knowledge or experience. Each distinct group needs its own participants in validation.[1]
How big: one working session and a document of a page or two.
Step 2 · Known use problems
Learn from what's already gone wrong
Before analyzing your own design, find out where people have struggled with similar devices: adverse event reports, recalls, your own complaint files and published studies.
Nivra Fictional example
The team searched FDA's MAUDE adverse event database for similar home breathing meters,[6] reviewed complaints on the company's older peak flow meter, and read published studies. Two themes kept coming up: blows that weren't hard or fast enough, and people misreading which zone they were in.
How big: desk research, measured in days.
Step 3 · Task analysis and use-related risk analysis
Break the use into tasks and ask what could go wrong
List every task, then for each one ask what a user could do wrong, what would happen, and how bad it would be. This use-related risk analysis (URRA) is where critical tasks come from. Our risk management guide walks through one in detail.
Nivra Fictional example
The team listed 23 tasks, from unboxing and pairing the app to cleaning the mouthpiece. Only two turned out to be critical:
- Recognize a red-zone result and follow the action plan (adults and parents). Missing it could delay treatment of an asthma attack. FDA counts compromised medical care as harm.[1]
- Enter each patient's zone limits correctly (clinicians). A wrong limit could show a dangerous result as green.
Blowing technique mattered too. But the app checks every blow and asks for a repeat when one doesn't look right, so the team rated what was left of that risk as low and checked the coaching in early testing instead.
| Task | Possible use error | Possible harm | Critical? | Main risk controls |
|---|---|---|---|---|
| Read the result and act on it | Misses a red-zone result or thinks it's fine | Delayed treatment of an asthma attack | Yes | Full-screen red alert with plain wording, action plan steps on the same screen, vibration |
| Set zone limits (clinician) | Enters the wrong value or unit | A dangerous result shown as green | Yes | Unit shown on the field, range check, confirmation screen |
| Clean the mouthpiece | Skips cleaning | Minor: hygiene, possible reading drift | No | Reminder in the app, cleaning steps in the quick-start guide |
The URRA is a risk analysis, so it lives in your ISO 14971 risk management file. IEC 62366-1 lets usability records form part of other files, including the risk management file.[2][3] Your usability engineering file can point to the URRA instead of keeping a second copy that drifts out of date. The usability process can identify abnormal use, meaning a conscious, intentional act or omission that goes against normal use and is beyond what the manufacturer can reasonably control through the user interface, but it doesn't assess or control it. That stays with risk management.[2]
How big: the biggest analysis step, but it's a table your team fills in, not a lab.
Step 4 · Formative evaluation
Design, try it early, repeat
Put rough versions in front of real users while changes are still cheap. These formative studies are informal by design: their job is to find problems, not to prove anything.
Nivra Fictional example
Round one used six adults with asthma, a meeting room and a clickable prototype of the app. Four of the six read the red screen's headline, “Low,” as good news. The team changed it to “Red zone: follow your action plan now,” put the plan's first steps on the same screen, and added a vibration.
Round two added parents and clinicians. Two clinicians typed a percentage of personal best into a zone-limit field that expected FEV1 in liters, because nothing on the screen said which it wanted. The portal now accepts either, labels the unit clearly and rejects values outside a sensible range.
Round two also tested the quick-start guide on its own. Where warnings or instructions are part of a risk control, IEC 62366-1 expects you to show that users notice them, understand them and can act on them correctly.[2]
How big: small and fast. This is where most of the value is.
Step 5 · Human factors validation (summative evaluation)
Prove the critical tasks
Show, with representative users, the final design and realistic conditions, that people can do the critical tasks safely. It isn't a clinical trial: validation testing is usually simulated use, with no patient being treated.[1]
Nivra Fictional example
The team tested production-equivalent devices, the final app, and the final labeling. The room was set up like a living room, with a phone buzzing with notifications, because FDA expects simulated conditions realistic enough to apply to real use.[1] The quick-start guide sat on the table, available as it would be at home, but nobody was told to read it.[1] Training matched real life: adults and parents got only the quick-start guide, as they would at home. Clinicians took the same short online module they would really get, a few days before their session rather than right before, because training fades.[1]
There were 15 adults, 15 parents and 15 clinicians, one group of 15 for each distinct user group.[1] Scenarios put people in realistic situations, including a red-zone result. Moderators watched rather than coached. Afterwards they asked open, neutral questions about anything they couldn't observe, such as what the participant would do next. Moderators didn't ask participants to think aloud, which FDA doesn't accept in validation testing. Every use error, close call and difficulty observed in the test got a root-cause analysis.[1]
The result: no use errors on the red-zone task. One clinician typed a limit into the wrong field and caught it at the confirmation screen. That counts as a close call, and the confirmation screen worked as intended. The team analyzed it, judged the remaining risk acceptable, and recorded it in the risk file.
If validation finds a serious problem, fix the design and test the changed parts of the interface again. Depending on how big the change is, FDA may expect the validation to be repeated. Promising to fix it in a later version isn't acceptable in a submission.[1]
How big: the one formal study. It needs a protocol and a plan, but nothing about it is mysterious.
Step 6 · Usability engineering file and report
Write it up, and keep it current
IEC 62366-1's usability engineering file collects everything above. It doesn't have to be a separate binder: its records can sit in your design and development file and your risk management file, as long as each piece can be found and the links between them are clear.[2] FDA's HFE/UE report concludes whether the user interface is adequately designed for the intended users, uses and environments, so the device can be used without serious use errors or problems.[5]
Nivra Fictional example
After launch, complaints that mention a use problem feed back into the URRA. So do proposed design changes, through the usability check in our design change checklist. Our post-market surveillance guide covers the complaint side.
How big: mostly assembly, if steps 1 to 5 were documented as you went.
What FDA actually asks you to submit
Two FDA documents matter, and they do different jobs. Applying Human Factors and Usability Engineering to Medical Devices explains how to do the work, including critical tasks and the 15-participant minimum. FDA reissued it on 3 August 2026.[1] Content of Human Factors Information in Medical Device Marketing Submissions, final since 29 May 2026, recommends how much of that work goes into a 510(k), De Novo, PMA or HDE.[5]
The second one is the reassuring one. It sorts submissions into three categories:[5]
Category 1
A modification that doesn't change the user interface, users, uses, use environments, training or labeling.
You submit: a conclusion, a short summary, and your justification that human factors aren't affected.
Category 2
A new device with no critical tasks, or a modification that changes the user interface, users, uses, environments, training or labeling without adding or affecting critical tasks. Also used when critical tasks exist but you can justify not submitting validation data.
You submit: a rationale based on your URRA, plus descriptions of users, uses, environments, training and the user interface, and a summary of known use problems. The URRA itself stays on file.
Category 3
Critical tasks are present, new or affected, and validation data should be submitted.
You submit: a complete HFE/UE report, including the URRA, the critical tasks and validation testing of the final design.
Which category is your submission likely in?
Answer FDA's four decision points. This is a starting point only. FDA makes the call during review.
Is it a modification to a device that's already authorized?
Does the modification change the user interface, intended users, intended uses, use environments, training or labeling?
Based on your URRA, does the device have critical tasks?
Based on your URRA, does the change add critical tasks or affect existing ones?
Considering the user interface's history of use with these users and environments, how complex it is, and whether existing risk controls are adequate, should validation data be submitted?
For the Nivra, the launch submission was Category 3: a new device, with critical tasks and a brand-new interface. A year later, a firmware update that improved the flow measurement without changing any screen, alarm, label or blow-check prompt would be Category 1, if it needs a submission at all. FDA's 510(k) change guidance answers that question, not this one. A redesigned trends chart that doesn't touch the zone display would likely be Category 2.
FDA's submission-content guidance doesn't address combination products; it's written for devices reviewed by CDRH.[5] If you're unsure which category applies, a Pre-Submission lets you ask FDA before you file.[9]
What the EU asks for
The EU MDR doesn't treat human factors as a separate discipline, but Annex I requires the work.[4]
- Section 5: reduce use-error risks from the device's ergonomics and its use environment, considering users' technical knowledge, experience, education and training and their medical and physical condition.
- Section 4: eliminate or reduce risk through design first, then protective measures, and only then information for safety and, where appropriate, training.
- Section 22, for lay users: safe and accurate use at every stage, fewer errors in handling the device and reading results, and, where appropriate, a way to check the device works and a warning when a result isn't valid.
- Section 23.1: labels and instructions suited to the intended user's knowledge and training, with instructions for use the user can readily understand.
For IVDs, Annex I of the IVDR has matching requirements in Sections 4 and 5, and Section 19 covers self-tests and near-patient tests.[10]
There are no submission categories in the EU. The usability evidence sits in the technical documentation, and where a notified body is involved, it reviews that evidence against Annex I. Most manufacturers follow IEC 62366-1 to show they meet these requirements. FDA also lists it among the human factors standards it recognizes.[11] For the Nivra, one usability engineering file supports both the FDA submission and the EU technical documentation.
The vocabulary, translated
Half the intimidation is jargon. Here's what the terms mean in plain English.
- Human factors engineering / usability engineering
- The same work under two names. FDA writes HFE/UE.
- Use specification
- A short description of who uses the device, for what, where, and with what training. (Step 1.)
- User interface
- Everything the user sees, touches or reads, including labeling, packaging and training, not just the screen.[5]
- Use error
- Something the user does or doesn't do that the manufacturer didn't expect, with an unexpected result, not caused only by a device failure, that could cause harm. A design signal, not a blame label.
- Critical task
- FDA's term for a task that, done wrongly or skipped, could cause serious harm.[1]
- Hazard-related use scenario
- IEC 62366-1's term for a way of using the device that could put someone in a hazardous situation or lead to harm.[2]
- URRA
- Use-related risk analysis: the task-by-task table of what could go wrong and how bad it would be. (Step 3.)
- Formative evaluation
- Early, informal testing to find problems while the design can still change. (Step 4.)
- Summative evaluation / human factors validation
- The formal test of the final design, which shows the critical tasks can be done safely. (Step 5.)
- Distinct user group
- Users whose characteristics, such as tasks, knowledge or experience, would likely change how they interact with the device. Each group needs its own participants in validation.[1]
- Abnormal use
- A conscious, intentional act or omission that goes against normal use and is beyond what the manufacturer can reasonably control through the user interface. The usability process can identify it but doesn't assess or control it; risk management does.[2]
- Close call
- A participant has difficulty, or makes a use error that could cause harm, but catches it and recovers before any harm occurs.[1]
- Knowledge task
- Something you can't watch, such as understanding a warning, so you check it by asking open, neutral questions.[1]
- UOUP
- User interface of unknown provenance: an existing interface, or part of one, for which adequate usability engineering records aren't available. IEC 62366-1 Annex C sets out how to evaluate it.[2]
Where to start
- Write the use specification. One page is enough to begin, and it will settle arguments later.
- List the tasks and mark the critical ones with your risk management team, in the same risk file.
- Put a rough prototype in front of a few real users before the design freezes. Paper or a clickable mock-up is fine.
- Plan validation early: your distinct user groups, production-equivalent units, realistic training and the use environment you'll simulate.
- Work out your FDA category early, and ask FDA through a Pre-Submission if you're unsure.
Standards worth having to hand: IEC 62366-1 for the process, and IEC TR 62366-2 for practical guidance on applying it.[12] ANSI/AAMI HE75 for user interface design guidance. For electrical equipment, IEC 60601-1-6 (usability), IEC 60601-1-8 (alarms) and IEC 60601-1-11 (home use). FDA lists HE75 and the IEC 60601-1 collateral standards on its human factors premarket page.[11]
Related reading: use-related risk analysis and critical tasks and the design change checklist.
References
- U.S. FDA, Applying Human Factors and Usability Engineering to Medical Devices, guidance for industry and FDA staff, issued 3 August 2026 (originally issued 3 February 2016), sections 3 (definitions), 6.4.3 (formative evaluation), 7 (risk control) and 8 (human factors validation testing, including 8.1.1 participants, 8.1.3 labeling, 8.1.4 training and 8.1.6–8.1.7 analysis and residual risk). www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices
- IEC 62366-1:2015+AMD1:2020, Medical devices — Part 1: Application of usability engineering to medical devices (consolidated version), including clauses 1 (scope), 3 (terms and definitions), 4.1.2–4.1.3 (risk control and information for safety), 4.2 (usability engineering file), 4.3 (tailoring of the usability engineering effort), 5.1–5.9 (usability engineering process) and Annex C (user interface of unknown provenance). webstore.iec.ch/publication/67220
- ISO 14971:2019, Medical devices — Application of risk management to medical devices. www.iso.org/standard/72704.html
- Regulation (EU) 2017/745 on medical devices (EU MDR), Annex I, Sections 4, 5, 22 and 23.1. eur-lex.europa.eu/eli/reg/2017/745/oj
- U.S. FDA, Content of Human Factors Information in Medical Device Marketing Submissions, final guidance for industry and FDA staff, 29 May 2026 (HF Submission Categories 1–3, Decision Points A–D and the HFE/UE report sections). www.fda.gov/regulatory-information/search-fda-guidance-documents/content-human-factors-information-medical-device-marketing-submissions
- U.S. FDA, MAUDE — Manufacturer and User Facility Device Experience database. www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm
- 21 CFR Part 820, Quality Management System Regulation, § 820.10(c), design and development (incorporating ISO 13485:2016 clause 7.3 by reference), effective 2 February 2026. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
- ISO 13485:2016, Medical devices — Quality management systems — Requirements for regulatory purposes, clauses 7.3.3 (design and development inputs) and 7.3.7 (design and development validation). www.iso.org/standard/59752.html
- U.S. FDA, Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program, guidance for industry and FDA staff. www.fda.gov/regulatory-information/search-fda-guidance-documents/requests-feedback-and-meetings-medical-device-submissions-q-submission-program
- Regulation (EU) 2017/746 on in vitro diagnostic medical devices (IVDR), Annex I, Sections 4, 5 and 19. eur-lex.europa.eu/eli/reg/2017/746/oj
- U.S. FDA, Human Factors: Premarket Information — Device Design and Documentation Processes (standards table listing ANSI/AAMI/IEC 62366, ANSI/AAMI HE75, ISO 14971, IEC 60601-1-6, IEC 60601-1-8 and IEC 60601-1-11). www.fda.gov/medical-devices/human-factors-and-medical-devices/premarket-information-device-design-and-documentation-processes
- IEC TR 62366-2:2016, Medical devices — Part 2: Guidance on the application of usability engineering to medical devices. webstore.iec.ch/publication/24664
The Nivra, its users, studies and results are fictional and do not describe any real product or company. The regulatory requirements cited are paraphrased; check the current text of each standard, regulation and guidance before relying on it.