Formative usability testing that informs medical UI design
A clinician can recognize every control on a medical device and still hesitate at the moment that matters. The screen may look familiar, but leave an important question unanswered: has the setting been applied, is the device ready, or is another step required?
Formative usability testing helps a team examine those questions while the interface can still change. A useful study produces more than a list of preferences. It connects an observed difficulty to the design decision that should be reconsidered.
Start with a decision the team needs to make
Before building a test prototype, identify the uncertainty. Perhaps the team is choosing between two setup sequences. Perhaps users can complete a task, but the design offers weak feedback after confirmation. A focused question makes it easier to select the right tasks and decide what the prototype must support.
The prototype does not need to contain the entire product. It does need enough behavior to examine the question honestly. If the concern is recovery after an interruption, a sequence of static success screens will leave the most important interaction untested.
Define the task in terms of the user’s goal. Asking someone to prepare a device for its next use reveals different behavior from asking them to press a named button. The latter can unintentionally teach the interface being evaluated.
Recruit for the work and the use context
Age alone is a poor basis for deciding who will find an interface easy. Relevant differences may include clinical role, experience with a particular device, frequency of use, vision, dexterity, language and familiarity with the workflow.
Consider who sets up the device, who operates it, who reviews its output and who handles a problem. These may be different people. A confident operator’s performance does not tell the team whether an occasional user can recover from an unfamiliar state.
The setting matters too. Where relevant to the research question, examine interruptions, viewing distance, lighting, gloves and competing demands. Document the conditions represented in the study and the conditions that remain untested.
Turn observations into a design hypothesis
Consider an illustrative setup task. A participant selects a configuration, presses Continue, then returns to the previous screen to check whether the selection was retained. The task was completed, but the return visit deserves attention.
Record what happened before explaining it. The participant’s backtracking is an observation; “the saved state was unclear” is a hypothesis. A follow-up question may reveal a different cause, such as an unfamiliar label or concern about applying the setting to the wrong device.
If the evidence supports a feedback problem, a revision might make the selected configuration and its saved status visible at the next step. The next evaluation should examine whether people understand that state without prompting. Adding a confirmation message is not, by itself, evidence that the problem is resolved.
Keep a traceable record of what changed
For each important finding, keep the task, observed behavior, participant explanation, design hypothesis and proposed revision together. Record the version tested and what the next round needs to establish. This prevents a striking quotation or one confident participant from carrying more weight than the evidence supports.
Study depth should match the question and the product’s risks. A focused evaluation may be enough to compare an early navigation concept; a mature workflow may require a more realistic simulation and a broader set of users. Formative work informs design decisions. It does not automatically establish that a finished product has met its validation requirements.
The useful endpoint is a clearer decision: what the team learned, what it changed, and what it still needs to test.