Use-related risk analysis is often treated as a paperwork exercise: a spreadsheet filled in once, filed alongside the design history file, and rarely revisited. That approach almost never survives contact with a thorough regulatory review — because a use-related risk analysis isn't a snapshot, it's a thread that has to stay connected as the design changes.
Start from critical tasks, not from failure modes
Traditional FMEA thinking starts from components and failure modes. Use-related risk analysis has to start somewhere different: the critical tasks a user must perform correctly for the device to be safe and effective. A critical task is any step where a use error could cause serious harm — programming a dose, confirming an alarm, correctly assembling a delivery set.
- Identify critical tasks from the use specification and task analysis, not from engineering assumptions.
- For each critical task, ask what use errors are plausible, given realistic users and use environments.
- Estimate severity of harm if the use error occurs and isn't caught — not just likelihood.
Every use error needs a design answer, not just a warning
Regulators are consistently skeptical of risk mitigations that rely solely on labeling or training. A well-formed use-related risk analysis prioritizes mitigations in this order: eliminate the possibility of the use error through design, reduce its likelihood through design, and only then rely on warnings, labeling, or training as a last layer.
If the only mitigation you can point to for a serious use error is "it's in the instructions for use," the risk analysis isn't finished yet.
Keep the thread alive through testing
The real test of a risk analysis is whether it can answer, for any critical task: what could go wrong, what we did about it, and what evidence closes the loop. That evidence usually comes from formative testing (does the mitigation actually reduce the use error in practice?) and summative testing (does the final design perform safely under simulated use?). When a formative round surfaces an unanticipated use error, the risk analysis has to update — not get a footnote at the end of the report.
Why this breaks down in practice
In our experience, risk analyses drift out of sync with the design for one of two reasons: they live in a static document nobody updates after the first draft, or they're owned by quality/risk teams working from a different source of truth than the human factors team running the studies. Both are structural problems, not effort problems — which is exactly why we built HF Workspace to keep the use specification, task analysis, risk analysis, and test evidence in one connected record rather than four disconnected documents.
