Clinical Workflow
Design for
Medical Devices

A clinical workflow includes the actions, decisions and information exchanges involved in delivering care. Device use may be only one part of it. Preparation, other equipment, documentation and handoffs all influence what someone needs from the product.

Consider a clinician preparing a device. The setup instructions may be clear, but the information needed to choose a setting might be in another application. A colleague may have completed some of the preparation, or an interruption may occur before the final confirmation.

A workflow map shows these connections: who is involved, where information comes from and how responsibility changes. Task analysis adds detail about individual actions while keeping the surrounding work in view.

Interviews help explain what people expect and what they find difficult. Observation reveals details they may no longer think to mention, such as a routine double check or a handwritten note kept beside the device.

I look for needs expressed in both spoken and unspoken ways. A pause can suggest uncertainty, but it can also reflect deliberate caution, an interruption or something unrelated to the design. Understanding the reason matters.

Questions such as “What were you checking there?” or “What did you expect to happen?” help connect the action to the person’s reasoning. Support records and earlier usability findings can help us see whether the same concern has appeared elsewhere.

When access to clinicians is limited, clinical specialists, trainers and service teams can help identify questions to investigate. Their familiarity with the product may also mean they overlook difficulties that other users encounter. We distinguish their input from direct user observations and record the assumptions that still need checking.

Imagine a clinician returning to a device after an interruption. The device is waiting for confirmation, but they cannot tell whether the latest settings were saved or whether a colleague changed them. They repeat part of the setup to feel sure.

Making the confirmation button more prominent would not answer their question. They need to know what has already happened and what still needs attention.

A prototype could make the difference between saved settings and proposed changes clear, along with the action still required. Engineering would help establish what the device can reliably show, while the human factors team would assess the implications for use-related risk.

We would then test whether intended users understand the information and can resume appropriately. Until we evaluate it, the change is a proposed solution.

At Areteworks, we use Anxiety Maps when moments of hesitation or uncertainty need closer attention. We record what the person was doing, the surrounding conditions, what they said or did, and the question we need to investigate.

In the interrupted setup example, the map might connect repeated checking with uncertainty about saved settings. That gives us a specific issue to explore and keeps the original observation connected to the design decision.

An Anxiety Map is a research and design aid. It does not diagnose someone’s emotional state or establish a safety risk on its own. We check our interpretations with users and consider the findings alongside task analysis and usability evidence, involving the human factors team where relevant.

A recommendation to “make the status clearer” leaves too much for the development team to work out. Which status matters? When does the user need it, and what should it help them do?

Depending on the project, the work may produce workflow specifications, annotated design concepts, interactive prototypes or evaluation scenarios. These should connect the observed problem to the proposed behavior, including what happens when someone goes back, stops or resumes.

Product, engineering, clinical and human factors colleagues help determine what is practical. Sometimes the difficulty lies outside the device, such as information that is unavailable at the point of use. Recognizing that dependency helps the team decide what the product can reasonably support.

Formative usability testing helps us investigate difficulties and refine a developing design. FDA guidance describes formative evaluation as a way to inform design decisions and identify use problems before human factors validation. [1]

The scenarios should reflect the intended users and conditions that matter to the product. In the interrupted setup example, I would want to understand how someone decides where to resume, what they believe the device has saved, and whether they repeat or skip an action. Recording only whether they finish would miss much of that.

An early prototype may be enough to explore a sequence. As the design develops, the prototype needs to represent the product’s behavior closely enough to answer the study’s questions. Findings guide the next changes and further evaluation.

Human factors validation evaluates the final design with representative intended users under realistic use conditions, covering all identified critical tasks. Workflow research and formative studies help prepare for it; they do not replace it. [1]