How to write hazard-related use scenarios from a user flow
Gideon Awolesi ·
A hazard-related use scenario describes a situation where a use error could lead to harm. IEC 62366-1 asks you to identify them, and the FDA's guidance builds its whole risk analysis around the critical tasks behind them. A lot of teams write them from the risk file inward, as a list of hazards with a user attached. We write them from the user flow outward, because that's how the people using the device actually experience it. Here's how.
01Start from the flow, not the hazard list
Take the user flow your designers already have, from the moment someone picks up the device or opens the software to the moment they're done. If you don't have one, draw it with the people who know the device best, before you write anything else.
It's important that the flow describes what the user does, sees, decides, and checks, not what the software does internally. The scenario has to be something a person could act out in a test.
02Break the flow into tasks
Split the flow into tasks small enough that each one has a clear start and end, like "select the patient type" or "confirm the alarm limit". For each task, write down what the user has to perceive, what they have to understand, and what they have to do. A use error can happen at any of those three points.
03Find the use errors at each step
For every task, ask what could go wrong at each of the three points:
- Perception: the user doesn't see the information, or sees it too late.
- Understanding: they see it, but misread it, or confuse it with something else.
- Action: they understand it, but do the wrong thing, or do it the wrong way.
Use what you already know: complaints and support tickets about similar devices, findings from earlier formative tests, and the conditions people work in, like interruptions, time pressure, or gloves.
04Trace each use error to a hazard
For each use error, follow it forward: what hazardous situation does it lead to, and what harm could follow? This is where you bring in the risk team, because they'll know the hazards from the risk file under ISO 14971. If a use error can't lead to harm, it's still a usability problem worth fixing, but it isn't a hazard-related use scenario.
05Write the scenario so it can be tested
Each scenario should name the user, the environment, the task, the use error, the hazardous situation, and the potential harm. Write it in plain language, so a clinical reviewer and a test moderator read it the same way.
Give each scenario an ID, and use it everywhere: in the risk file, in the design file annotations, and in the test protocol. That's what lets a reviewer follow a scenario from the hazard to the evidence that it's controlled.
06Select the scenarios for summative evaluation
IEC 62366-1 asks you to select which hazard-related use scenarios go into the summative evaluation, and to say why. Usually that's the ones with the most severe potential harm, along with anything new or changed. When you add a feature to a device that's already validated, keep the scenarios for the new behaviour separate from the ones already covered, so the testing focuses on where the new risk is.
If you'd like us to check your scenarios before a submission, our Usability Review checks your usability engineering file clause by clause against IEC 62366-1 and the FDA's guidance, in four weeks from €6,000.