From a Smooth Interaction to a Critical Task
This chapter turns the device-user system into a risk-prioritization question: which interactions deserve the strongest evidence because getting them wrong could compromise care or cause serious harm? The answer is not “the hardest steps” or “the steps users dislike.” A critical task is defined by what could happen if the task is performed incorrectly or not performed at all. That distinction lets human-factors work focus on consequences without treating every inconvenience as a safety crisis.
The FDA’s framework combines structured analysis with observation of real users. Teams first identify how a use-related hazard could arise, trace it through a task and a possible error to a clinical consequence, and then test whether their analysis matches what people actually do. The list of important tasks is allowed to change as evidence improves. That is a strength, not a planning failure: use errors are often easiest to recognize after a user encounters the conditions that produced them.
Critical means consequence, not difficulty
A use-related hazard is a condition in which the interaction among a user, a device, and a use environment could produce harm. It may arise because the device requires a physical, perceptual, or cognitive ability the user does not reliably have. It may conflict with an expectation about how a control or sequence should work. The environment may make an important cue difficult to see or hear. Or the manufacturer may not have considered a reasonably foreseeable way in which people will use the device.
A hazard becomes useful for analysis when it is connected to a task. A task is one or more user interactions performed to achieve a desired result. The task might involve setting up a device, entering information, interpreting a display, responding to an alarm, connecting a component, or deciding what to do after the device provides feedback. The label is not the important part. The important part is the chain: what the user is trying to accomplish, what the interface requires, what can go wrong, and what follows.
The FDA defines a critical task as a task that, if performed incorrectly or not at all, would or could cause serious harm to the patient or user. “Could” matters. The task does not need to fail every time, or even often, to deserve attention. If an omitted confirmation could result in incorrect therapy, or if a misread display could delay a necessary response, the possible consequence makes the task critical even when most users usually succeed.
This definition also prevents a different mistake: equating difficulty with criticality. A long sequence may be frustrating but carry little safety consequence. A single, familiar-looking action may be easy for most users yet determine whether a therapy starts, whether an alarm condition is addressed, or whether a component is connected correctly. A critical task can therefore be smooth, fast, and popular. Its safety importance comes from the harm pathway, not from the amount of effort it requires.
The same reasoning applies to rare scenarios. Some tasks occur only when a particular condition appears, when a device must be set up in an unusual way, or when a user faces a problem rather than routine operation. Low frequency can make such situations harder to notice, but it does not make them irrelevant. If the consequence of an error could be serious, an analysis that covers only the ordinary workflow may leave a material gap.
The chain from hazard to harm can be made explicit:
The diagram is a reasoning model, not a claim that every task follows one identical path. An error may be recovered before harm occurs. A close call may reveal the same weakness without producing a clinical consequence. A knowledge problem may involve misunderstanding a warning rather than an observable physical action. The point is to keep the possible consequence attached to the interaction instead of treating “usability” as a single undifferentiated quality.
Task analysis makes this chain inspectable. It breaks a device-use process into discrete sequences and examines the interface components involved in each one. For every interaction, an analyst can ask what the user must perceive, how they must interpret it, what physical action is required, what could be done incorrectly, what circumstances could trigger the error, and what harm might follow. The analysis should also consider the effect of an early error on later operations. A mistaken entry may not become visible until the device acts on it; a missed signal may change what the user believes is happening next.
This approach exposes different failure modes that a general question such as “Was the device easy?” cannot separate. Information may be difficult or impossible to notice. Information that is noticed may be difficult to interpret or may be interpreted incorrectly. A cognitive step may be confusing or inconsistent with past experience. A physical action may be incorrect, mistimed, or impossible. The user may complete the visible sequence while producing a result different from the one they intended.
Task analysis also creates a disciplined way to decide what deserves further evidence. The effort required, the frequency of a task, the capabilities of the user population, the environment, and the effect on later operations all matter. But frequency is only one input. A rare task with a severe consequence may receive more attention than a frequent task with a minor inconvenience. The analysis should be driven by risk, not by the easiest metric to collect.
The list of critical tasks is consequently not fixed at the first meeting. As the team understands the user interface better, it may identify additional tasks, different use scenarios, or errors that were not visible in the initial model. Formative evaluation may show that a task thought to be straightforward depends on an unrecognized interpretation. Validation may reveal a close call or a new error path. The final list should structure the validation test, but the test should still be able to detect problems that were not predicted in advance.
Analysis can map risk; users reveal what the map missed
Structured analysis is necessary because it gives a team a way to reason before a final device exists and before every possible condition can be observed. The FDA discusses several complementary approaches. They differ in where they begin and what kind of blind spot they are likely to expose.
Failure mode effects analysis, or FMEA, starts from user interactions and considers how a task could fail, what the failure would cause, and what harm might result. It is a bottom-up approach: the team examines actions and possible failure modes, then works toward consequences. It is most useful when people with different perspectives contribute. Someone who uses the device, a clinical expert, a designer, and a human-factors specialist may notice different ways a sequence could go wrong. A multidisciplinary discussion can therefore widen the set of scenarios considered.
Fault-tree analysis takes a top-down route. It begins with a hazardous outcome or use-related fault and works backward through the conditions that could produce it. This reverses the direction of FMEA. Instead of asking how each interaction might fail, the team asks what combinations of failures or user actions could lead to the defined hazard. A task analysis is important here because a fault tree that omits a part of the user-device interaction can give a false sense of completeness.
Neither approach is automatically superior. FMEA can miss a pathway that no one imagines while walking forward through tasks. A fault tree can omit a branch if the team’s account of user behavior is incomplete. Both depend on the quality of the scenarios, the knowledge of the participants, and the extent to which the user-device relationship has been understood. The FDA’s point is not to discard analytical methods. It is to use them to inform simulated-use testing rather than treating them as a substitute for it.
Other analytical approaches examine the interface from different angles. A heuristic evaluation compares the design with relevant principles of interface design. An expert review relies more heavily on the experience and judgment of clinical or human-factors experts. Multiple experts may identify more potential problems than one person working alone, but expertise still does not give anyone direct access to how every intended user will behave in a realistic setting.
Empirical methods add that missing perspective. Contextual inquiry observes representative users interacting with a current or similar device in an actual use environment. Interviews can reveal users’ experiences, problems, and beliefs about how a new design should work. Formative evaluation observes interaction with a device, mock-up, or prototype while design choices are still open. Simulated-use testing lets participants perform actual tasks under realistic but controlled conditions. These methods are not interchangeable, but they all add information that cannot be obtained solely by inspecting the interface or discussing it around a table.
The quality of empirical evidence depends on who participates and how the interaction is observed. Participants should represent the intended users, and facilitators should avoid steering their behavior or responses. A participant who is unusually capable, unusually careful, or already familiar with a prototype may make a design appear more robust than it is. A participant who is guided through every step may demonstrate the facilitator’s support rather than the interface’s ability to support independent use.
Formative evaluation is especially important because it allows the team to learn while change is still practical. It can reveal an unanticipated use error, expose a new critical task, show whether a risk control works, or indicate that labeling and training need attention. The team can then modify the design and evaluate the modification again. The purpose is not to produce a final frequency estimate. It is to improve understanding of how the interface affects behavior and to reduce the chance that final validation becomes the first serious discovery of a design flaw.
That distinction protects against a common overclaim. An analytical finding is not evidence that users will make the predicted error, and the absence of an observed error in a small formative session is not evidence that no such error exists. The methods answer different questions. Analysis identifies plausible pathways and organizes coverage. Empirical work shows what selected users did in selected conditions. The evidence becomes stronger when the two forms challenge and refine each other.
The evolving task list is the link between them. Analysis may identify a task because its potential harm is obvious. Observation may add a task because users interact with the interface in an unexpected way. A user may reveal that a supposedly secondary step is where they lose the meaning of the sequence. A new use scenario may appear when the device is used in a condition that the team had treated as peripheral. The task list should absorb those findings rather than protect the original model from revision.
This is also why a smooth interaction is not enough. A user can complete a task in a demonstration while relying on an assumption that will fail under another condition. An expert can approve a sequence that seems logical but conflicts with a user’s learned expectation. A checklist can contain all the right steps yet fail to show which one carries the serious consequence. Critical-task analysis makes those differences visible and points to the next decision: whether the hazard should be removed through design, reduced through a protective measure, or addressed with information and training for the risk that remains.