The Device Is a System: Users, Environments, and Interfaces
This chapter examines the medical-device system made by users, use environments, and the user interface. The practical question is how a small mismatch among those three parts can become a use-related hazard. Seeing that relationship helps distinguish a device that looks intuitive in isolation from one that supports safe action in the conditions where people will actually depend on it.
The FDA’s human-factors guidance does not treat a medical device as an object that a user approaches with a fixed level of ability. It treats use as an interaction. A person brings particular capabilities and expectations; the environment changes what they can perceive and do; the interface supplies information, controls, feedback, and constraints. Safety emerges from how those parts fit together.
The user is a capability profile in a setting
Calling someone an “intended user” is only the beginning of the analysis. A medical device may be operated by a clinician, a patient, a family caregiver, an installer, a maintenance worker, or someone who cleans and reprocesses it. Those roles matter because they involve different tasks and different knowledge. But role alone is not enough. The same person may have different capabilities in different circumstances, and people within one role will not have identical vision, dexterity, experience, language skills, or health status.
The FDA lists characteristics that can affect interaction: physical size, strength, stamina, dexterity, sensory ability, cognition and memory, literacy and language, general health, education and health literacy, experience with similar devices, knowledge of the particular device, ability to learn, and willingness to learn. This is not an invitation to assemble an exhaustive demographic profile for its own sake. Each characteristic matters only insofar as it changes what the user must perceive, understand, or physically do.
Imagine a task that requires a small control to be located, a displayed value to be read, and a setting to be confirmed. The relevant questions are not simply whether the intended user is a nurse or a patient. Can the user see the control under likely lighting? Can they distinguish the value from a nearby value? Do they know that confirmation is required? Can they operate the control with the strength and dexterity available at that moment? Do they recognize what the device will do next?
These questions also resist the tendency to blame the user when an interaction fails. A use error is not automatically evidence that someone was careless or insufficiently trained. It may show that the design depended on a capability, expectation, or memory that the real user did not reliably have. Treating the person as part of the system makes the design responsibility clearer: the interface must accommodate relevant variation or the device’s instructions must clearly state what capabilities are necessary for safe use.
Experience can cut in both directions. Familiarity with similar devices may help a user work quickly, but it can also create an expectation that a new device will behave the same way. A learned convention can become a source of error when a control reverses the direction, changes the sequence, or uses a symbol differently. A novice may hesitate, while an experienced user may move confidently through a familiar-looking sequence without noticing that an important assumption no longer holds.
The safety implications depend on the task. A mismatch that adds a few seconds to a noncritical setup step may be an inconvenience. The same kind of mismatch during a task that determines whether therapy is delivered, an alarm is recognized, or a setting is applied may have a different consequence. That is why user characteristics should be connected to the actual interaction rather than treated as a generic list of who might use the device.
The environment supplies the next part of the explanation. Medical devices may be used in hospitals, homes, emergency transport, public spaces, or other settings where conditions vary. Lighting may make a display or control hard to see. Noise may mask feedback or make several alarms difficult to distinguish. Clutter, nearby equipment, and other people may create distraction or make it hard to maneuver. A moving vehicle can add vibration that affects both reading and fine motor actions.
These conditions do not need to be extreme to matter. A user who can read a display in a quiet room may have less attention available when an alarm is sounding, a patient needs help, or another task interrupts the sequence. A family caregiver may need to act in a home where the device is stored with similar-looking supplies. A device used in intensive care may encounter several alarms and competing demands at once. The point is not that every test must reproduce every possible event. It is that the conditions most likely to affect safe interaction must be understood as part of the use context.
Environment can also change the meaning of an interface cue. An audible signal that is obvious in isolation may be lost in background noise. A warning that is visible on a bench may be overlooked when the user is moving. A control that is easy to reach may be difficult to operate while wearing gloves or while maintaining another part of a setup. The same design choice can therefore produce different risk pathways depending on who is using it and where.
The FDA’s model does not claim that one of these parts always dominates. It provides a way to ask which interaction is failing. If the user cannot perceive the information, the problem differs from one in which the information is visible but its meaning is unclear. If the meaning is clear but the control requires an impossible movement, the design challenge differs again. If all of those elements work in a quiet room but not during a realistic emergency workflow, the environment has exposed a boundary of the evidence.
The same device can also pass through several user situations in one episode of care. One person may unpack and assemble it, another may program it, and another may clean or maintain it. A patient or family member may later encounter the device without the professional context that shaped the original setup. Each handoff changes what the user is expected to know and which parts of the interface they must rely on. Packaging and instructions may matter before the device is turned on; a control and its feedback may matter during operation; access to components and the force required to replace them may matter during maintenance. A device that feels simple during one stage can still create risk at another.
This is why a broad statement about “the user experience” can hide important differences. A professional may recognize a symbol because it resembles a familiar clinical convention, while a lay caregiver may read the same symbol literally. A maintenance worker may need to distinguish components that an operator never touches. A patient using a device at home may have to interpret an alarm without the immediate support available in a clinical setting. These are not separate product impressions. They are different interactions with the same user interface, and each can create a different path to harm.
The environment also changes the amount of attention available for interpretation. In a quiet demonstration, a participant may notice a prompt, read a label, and consider the next action without interruption. In practice, a device may be one element of a crowded workflow. A user may have to respond to another person, monitor a patient, distinguish several alarms, or work while moving. The relevant issue is not whether the device can be used under ideal conditions. It is whether the conditions that can reasonably affect a critical interaction have been recognized and represented when the design is assessed.
A system map therefore does two kinds of work. It identifies where a hazard can arise, and it prevents an overly quick explanation of why it arose. If a person misses an alarm, the cause might involve audibility, competing noise, the meaning of the signal, the person’s role, or the timing of the task. If a setting is entered incorrectly, the cause might involve the display, the sequence, an expectation from another device, or an interruption. The model does not decide which cause is true in advance. It tells the investigation what relationships to examine.
That distinction matters for evidence. The three-part model is a conceptual guide, not a measurement that assigns a fixed percentage of risk to the user, the environment, or the interface. For a particular device, a credible conclusion still requires evidence about the specific users, conditions, tasks, and responses involved. The model is valuable because it keeps those questions connected; it is not valuable as a label that makes testing unnecessary.
A user interface is a loop, not a control panel
The phrase “user interface” often brings a screen to mind, but the FDA uses it more broadly. The interface includes the device’s physical form, components and accessories, controls, displays, alarms, visual, auditory, and tactile feedback, software logic, connections to the patient, packaging, labels, instructions, and training. It also includes the order and timing in which information appears and the way the device responds to an action.
That breadth matters because users do not interact with isolated features. They move through a loop. They perceive information from the device and the surroundings, interpret it, decide what to do, act on a control or component, and then use the device’s response to decide what comes next. A design problem can enter at any point in that loop. Information can be absent or hard to detect. A signal can be interpreted incorrectly. A sequence can conflict with what the user expects. A physical action can be mistimed or impossible. The device can provide feedback that is technically present but not meaningful to the user.
The loop shows why an interface cannot be judged only by appearance. A display may contain all the necessary information and still fail if the user cannot tell which value is current. A control may be clearly labeled and still fail if the next state is not apparent. An alarm may be audible and still fail if its meaning is ambiguous. A connector may fit physically and still create risk if the user cannot tell that it is secure or can attach it to the wrong port.
Expectation is one important mechanism. People bring models of how controls, labels, alarms, and sequences usually work. The FDA gives the example of a user who expects a knob to increase or decrease a flow in a familiar direction. When a new electronically driven control reverses that convention, the potential for use error increases. The issue is not that the user has a bad intuition in the abstract. The issue is that the interface has created a conflict between the action the user expects and the action the device requires.
The same mechanism appears in software-driven devices. Menus, prompts, icons, navigation, and confirmation steps determine what information the user sees and when. If the logic is inconsistent with the user’s expectations or hides an important state change, a user can complete the visible sequence while misunderstanding the device’s actual state. A polished visual design does not remove the need to examine those transitions.
Feedback is especially important because it closes the loop. Without useful feedback, users may not know whether an input was accepted, whether a setting was retained, or whether the device has entered a different mode. With poorly timed or ambiguous feedback, users may infer the wrong state and proceed. A confirmation step can help, but it can also become a routine gesture that users perform without understanding what they are confirming. The relevant evidence must show what users perceive and understand, not merely that a screen contains a confirmation button.
Labels, instructions, and training also operate inside the loop. They can supply information that is not obvious from the physical device, explain a hazard, or prepare a user for an unusual condition. But they depend on the user finding the information, reading it, understanding it, and remembering it at the moment of action. A label that is unavailable during use or a training message that decays from memory cannot be assumed to control a hazard as reliably as a design that prevents the dangerous action.
This does not mean that every difficulty is a serious safety problem. A user may pause because a control is unfamiliar and then complete the task correctly. A longer sequence may be acceptable if the task is not time-critical and the user can reliably understand each state. Human-factors analysis asks what the difficulty means in context: whether it is likely, whether it affects a critical task, whether it can lead to harm, and whether the interface or another control can reduce that pathway.
The central lesson is therefore relational. “Poor usability” is too vague to explain a risk. A useful description identifies the person or user group, the environmental condition, the interface element or logic, the action or omission, and the possible consequence. For example, the important claim is not simply that a display is confusing. It is that, under a specified condition, a user may fail to perceive or interpret information needed for a task, take a different action than intended, and thereby create a pathway to compromised care. That description can be analyzed and tested.
Once the hazard is described that way, the next issue is priority. Some interactions are inconvenient; others could cause serious harm if performed incorrectly or omitted. The following discussion turns this system map into critical tasks and asks which interactions deserve the strongest evidence.