Usability and Human Factors

Usability is a safety and performance discipline

Medical-device usability engineering applies knowledge about people, their capabilities, limitations and working conditions to the design of the user interface. Its safety purpose is to reduce the probability and consequences of use errors that could cause harm. It also supports accurate, timely and efficient performance of the device’s intended functions.

Human factors is the wider discipline; usability engineering is the structured application of that discipline to the device. User experience can address satisfaction, preference and commercial appeal, but a pleasant-looking interface is not evidence that critical tasks can be completed safely.

Define the use specification before designing the interface

The use specification describes who uses the device, what they do, for whom, why and where. It is the foundation for user-interface requirements, use-related risk analysis, participant selection and realistic evaluation scenarios.

• Define each distinct user group, including patients, carers, clinicians, technicians, installers, cleaners and service personnel where applicable.
• Describe relevant experience, qualifications, language, literacy, sensory and physical capabilities.
• Identify patient populations and characteristics that change the interaction or consequences of error.
• Describe professional, laboratory, home, transport and emergency environments as applicable.
• Define operating principles, intended medical purpose, user goals and expected workflows.
• Identify frequency, duration, urgency, workload, distractions, protective clothing and environmental constraints.
• State what training, documentation, accessories, other equipment and organisational support are expected.
• Include reasonably foreseeable use beyond the ideal workflow, including interruptions, recovery and unusual but credible conditions.

Use MTL-102 — Intended Purpose, Users and Use Environments to establish this context. The use specification should remain consistent with product claims, risk management, system requirements and the populations represented in validation.

Treat every point of interaction as the user interface

The user interface is not limited to a screen. It includes every means by which the user receives information from the device, acts upon it, prepares it, connects it, maintains it or recovers from a problem.

Interfaces between disciplines often create use problems: a connector that fits the wrong port, a mechanical latch whose state is not sensed, software that reports completion before a physical process finishes, or labelling that uses different terminology from the display. Use MTL-112 — Systems Engineering, Architecture and Interfaces to maintain a coherent system boundary and interface model.

Analyse real tasks and workflows

Task analysis breaks user goals into the decisions, perceptions and actions needed to achieve them. It should describe the work as people actually perform it, including preparation, transitions, interruptions, recovery, cleaning and shutdown—not only the device’s intended button sequence.

Observe representative users when possible. Interviews reveal beliefs and remembered practice; observation reveals workarounds, interruptions, shared responsibilities and environmental constraints that users may not think to describe. Translate the findings into measurable user-interface and system requirements using MTL-103 — User Needs and Design Inputs.

Build use-related risk into the product risk process

Use-related risk analysis examines how interface characteristics and use conditions could lead to use errors, hazardous situations and harm. It is part of the overall risk-management process—not a separate usability risk score that ends with ease of use.

• Identify hazards and foreseeable sequences of events involving user interaction.
• Describe potential use errors without assuming a single cause.
• Connect each use error to the hazardous situation and possible harm.
• Consider perception, cognition, decision-making, memory, physical action and communication.
• Include slips, lapses, mistakes, mode confusion, incorrect assumptions and intentional workarounds.
• Identify risk controls already implemented in the user interface and their possible limitations.
• Determine which tasks are critical because an incorrect or omitted action could cause serious harm.
• Define hazard-related use scenarios that can be represented realistically in evaluation and validation.
• Keep the analysis aligned with design changes, formative findings and post-market information.

Severity comes from the potential harm, not from how difficult the task appears. A simple confirmation, connector or unit selection can be critical when an error could lead to an incorrect treatment. See MTL-105 — Medical-device Risk Management for the wider risk process.

Control risk through the interface design

Prefer risk controls that make the correct action natural, prevent dangerous actions or make an unsafe state visible. Information for safety and training are important, but they are generally less reliable than well-designed inherent or protective interface features.

Design controls should address the root cause. Adding a warning to compensate for ambiguous modes or indistinguishable connectors is weak when the interface can be redesigned. Conversely, do not remove essential information merely because “good design should need no instructions”; users may need preparation, compatibility, maintenance or emergency information that cannot reside on the device.

Physical and digital elements must be designed together. See MTL-115 — Mechanical Design and Materials and MTL-114 — Electrical and Electronic Design for the engineering disciplines that realise many interface controls.

Use formative evaluation to improve the design

Formative evaluation is iterative learning conducted during development. Its purpose is to discover problems, understand why they occur and guide design changes. It can range from expert review and walkthroughs to representative-user sessions with increasingly realistic prototypes.

• Start early enough that findings can change architecture and workflow, not merely wording.
• Choose methods and participants that address the current design questions.
• Use realistic tasks, data, accessories, environments, interruptions and time pressure where relevant.
• Observe behaviour and reasoning rather than asking only whether users like the design.
• Avoid coaching participants through the very interaction being evaluated.
• Capture use errors, close calls, hesitations, confusion, workarounds and unexpected strategies.
• Investigate causes in the interface, task, information, environment and user expectations.
• Record design changes and determine whether they introduce new tasks or risks.
• Repeat evaluation until safety-significant uncertainties are resolved sufficiently for validation.

Formative work does not need to imitate a formal validation study every time. Small, focused studies can answer specific questions quickly. However, convenient colleagues are not substitutes for intended users when experience, capability or context materially affects the result.

Validate the final user interface

Usability validation—often called human-factors validation or summative evaluation—provides evidence that the final user interface can be used safely and effectively by the intended users, for the intended uses and in representative use environments. It is not simply a larger formative study or a general satisfaction survey.

The validation protocol should predefine user groups, sample rationale, scenarios, critical tasks, configurations, training, data collection and analysis. The report should present actual observations and explain why remaining findings do or do not indicate unacceptable use-related risk.

Validation of the user interface contributes to design validation but does not replace clinical, performance or system validation. Use MTL-106 — Verification and Validation to distinguish these evidence questions.

Investigate findings rather than counting errors

A simple pass/fail table can hide important safety information. Every use error, close call and serious difficulty should be investigated to understand its probable causes and potential consequences.

• Reconstruct what the participant perceived, understood, expected and attempted.
• Review interface cues, terminology, feedback, layout, modes, timing and workflow assumptions.
• Consider whether the scenario, prototype, training or study method influenced behaviour.
• Determine whether other users could make the same error and whether the outcome could be more severe.
• Revisit the use-related risk analysis and affected risk controls.
• Change the design when further risk reduction is practicable and justified.
• Assess whether a change requires additional formative work or repeat validation.
• Document the evidence and reasoning behind residual-risk conclusions.

“Only one participant made the error” is not a root-cause analysis. Validation studies are not normally powered to estimate rare-event probabilities. A credible interface-related failure with serious potential harm demands engineering judgement and risk analysis even when its observed frequency is low.

Usability work across the lifecycle

Maintain a connected usability-engineering file

The usability-engineering file may be a collection of controlled records rather than one document. It should make the reasoning traceable from use context and known problems through risks, design decisions, evaluations and final conclusions.

Maintain bidirectional links to the product risk-management file and design inputs. When the interface changes, assess which tasks, risk controls, formative conclusions and validation results are affected. See MTL-104 — Design Controls and Technical Documentation for organising this connected evidence.

Common misconceptions