I’ve reviewed more than my share of usability files during Technical File audits and NB interviews. To be fair, failures rarely come from a single missing test or a badly designed UI widget. They’re almost always systemic: gaps in context-of-use thinking, weak traceability to risk controls, and an over-reliance on training or the Instructions for Use (IFU) as a “fix”. In practice this means the usability file looks tidy on paper but fails to convince a notified body (or worse, fails in the field).
The standards you really need in your corner
- ISO 62366-1:2015 — the usability-engineering process and the usability file (formative + summative work).
- ISO 14971:2019 — risk management, including use-related hazards; the two must be linked.
- For software devices, IEC 62304 plays into usability expectations for software lifecycle and risk controls.
Notified bodies expect to see usability engineering as part of your overall risk management and Technical Documentation (Annex I/Annex II territory). When those links are thin, they ask for more evidence — and they will.
The common failure modes I keep seeing
- Context of use is shallow or generic. “Clinician” or “patient” is not a use description. No environment, no user characteristics, no stressors.
- Use-related hazards defined late — after design choices have been made.
- Formative testing is present, but there’s no clear, pre-defined pass/fail criteria for the summative (validation) study.
- Traceability gaps: you cannot point from a specific use error to the risk control, verification evidence, and IFU wording in a single trace matrix.
- Over-reliance on training/IFU as the only mitigation for a design problem (not acceptable without strong justification and evidence).
- Summative studies use expert or overly trained participants rather than representative end users.
- Post-market surveillance and PMCF ignore use-related trends — usability complaints are siloed as “customer feedback” and never looped back to CAPA-driven risk assessment.
- Change control misses “minor” UI tweaks; no re-assessment of use-related risks after release.
What notified bodies actually ask for (from my experience)
- A complete usability (usability-engineering) file mapped to ISO 62366-1, with a clear trail from use-related hazards to mitigations and verification/validation evidence.
- A documented justification when you rely on training or IFU rather than a design fix, and evidence that those mitigations are effective in real use.
- Representative summative validation with predefined acceptance criteria — not exploratory sessions labelled as “validation”.
- Evidence that usability issues feed into post-market surveillance, and where appropriate, into CAPA. Traceability is non-negotiable.
Practical fixes I apply (and recommend)
- Start with a robust context-of-use matrix. For each user group list:
- physical/mental capabilities
- likely distractions and environmental stressors (lighting, PPE, noise)
- frequency and criticality of tasks
- Create a use-related risk register that mirrors ISO 14971 structure. For each use error include:
- direct link to the hazard
- proposed risk control (prefer design over IFU/training)
- verification method and evidence location (document IDs)
- Define summative study acceptance criteria up-front. Your notified body will ask “how did you decide it’s safe?” — answer that before the test.
- Use representative users for validation. If you expect occasional users in the field, include them, not only your power users.
- Treat usability findings like CAPAs: assign owners, set timelines, and close the loop with verification evidence. This is CAPA-driven risk assessment in practice.
- Keep a living traceability matrix. Make the matrix the single source where user task — risk — mitigation — verification — post-market data are linked. This is where a connected workflow helps; native workflow integration between change control, risk, and usability documents reduces human error.
- If you rely on training or IFU, collect real-world effectiveness evidence (observations, PMCF entries) and be prepared to show it during an audit.
Examples of small decisions that cause big problems
- Changing a button label late in development without re-running a quick formative test — a subtle text change can change user expectation and lead to use error.
- Moving an alarm tone to be quieter to reduce annoyance, but without checking detectability for the intended use environment.
- Translating an IFU but not verifying that critical warnings remain prominent in other languages.
These are small design or process choices that become audit findings because the risk analysis and verification steps were skipped.
Final practical checklist before you lock the usability file
- Context of use: fully described and referenced.
- Use-related hazards: identified and risk-evaluated per ISO 14971.
- Design controls: prioritised over IFU/training; justified if otherwise.
- Formative + summative tests: documented, with predefined acceptance criteria.
- Traceability matrix: complete and reviewable.
- Post-market link: PSUR/PMCF data feeding back to usability and CAPA register.
I’ve found that if you can point an auditor to a single traceable chain from a use task to your summative results and post-market monitoring, the conversation becomes factual rather than speculative.
What’s one small change your team made to a usability process that stopped recurring use-errors — and how did you prove it worked to your notified body?
Top comments (0)