On a medical device, bad UX is a safety failure. A use error is not a clumsy user; it is a design decision that reached a patient. Someone read the screen the way it was built to be read, did what it implied, and the outcome went wrong.
Regulators stopped calling that the user's fault long ago. In the UK, the MHRA treats human factors and usability as a safety requirement, and BS EN 62366-1 sets out the engineering process behind it. The FDA holds the same line for the US market. If you build a regulated device, usability is not a finishing pass. It is a control you have to evidence.
What the regulators actually ask
Strip away the language and the MHRA and FDA ask for the same thing: show that you found the ways your device could be used wrong, designed those risks down, and proved it with real users before launch. The MHRA's 2025 update presses harder on this, tying the work to risk management and to what you learn once the device is in real-world use.
That last part has teeth. For validation testing, the FDA expects at least 15 participants from each distinct group of users. A device used by both nurses and patients needs 15 of each, doing real tasks on the device as it ships.
Formative early, summative late
Human factors work splits into two jobs.
- Formative testing runs while the design is soft. You watch people use early versions, find where they stumble, and fix it while fixing is cheap.
- Summative testing is the exam at the end. You prove, on the finished device, that the dangerous use errors are gone.
The trap is to leave it all to one summative study near submission. By then the design is set and a failed test is the most expensive kind there is. In the US, use error already accounts for 28.1% of the device problems reported to the FDA; the teams who stay out of that statistic start formative work early.
Put the designer in the room
Design can't sit apart from clinical and regulatory work. The hazards your safety team logs are use errors waiting to happen; the mitigations they write are design problems to solve. Decide them together and you remove the use error before it exists, which is the cheapest place to remove it.
Building a device that has to satisfy users, clinicians and regulators at once? That is the work I do embedded in product teams.
