Usability & context of use
What this system is trying to produce, for whom, and how anyone would know it worked. Every other page describes attributes; this page describes the outcome those attributes are supposed to contribute to.
ISO 9241-11 is a definitions and concepts standard. It contains no requirements and its scope states that it does not describe processes or methods — you cannot conform to it and this system does not claim to. It is used here for one reason: it is where the vocabulary in your IEC 62366-1 usability engineering file is defined, so structuring the design system the same way lets the two documents reference each other instead of talking past each other.
Dashed pills throughout this system mark a framework or vocabulary reference. Solid pills mark a standard a product can actually be assessed against.
Usability is an outcome, not a property
ISO 9241-11 defines usability as the extent to which a system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. The consequence is easy to state and easy to forget:
Usability is a property of a use, not of a component. A 44 px button is not usable. A clinician acquiring a lead-off-free ECG on a 15-inch cart display while gloved, and correctly identifying an anterior STEMI within four minutes, is a usable outcome — to which that button contributed.
This matters for how you read every other page in this system. A component page can only supply attributes believed to contribute to usability in an intended context. Whether they actually do is settled by observing use, not by reading documentation. The same is true of the Clinical safety notes sections: each one is a design rationale, not a hazard-analysis output, and it only holds inside the context of use described below.
Human-centred quality
Usability is one of four outcomes of use. Together they are called human-centred quality, and this system organises itself around all four rather than treating safety as the only one that matters in a medical device.
| Outcome | Question it answers | Where it lives here |
|---|---|---|
| Usability | Did specified users achieve their goals, at what cost, and how did it feel? | This page, plus Outcomes of use on each component |
| Accessibility | Does it work for the widest range of user needs and capabilities? | Accessibility on every page |
| User experience | What did users perceive and feel, before, during and after? | Satisfaction below; Confidence disclosure |
| Avoidance of harm from use | What could go wrong, and what stops it? | Clinical safety notes on every page |
Specified
Users, goals and context are written down, not assumed. Guidance that does not say who it is for is guidance nobody can check.
Whole
Effectiveness, efficiency and satisfaction are all reported. A system optimised for one while silently degrading another has not improved.
Observed
Claims about usability are settled by watching real users in a real context, never by the confidence of the documentation.
Specified users
Users are not only the people who operate the software. ISO includes people who use its output without producing it, and people who support or maintain it. Omitting those two groups is the most common way a clinical design system ends up unusable for half the people it affects.
Users, goals and context are properties of a device, not of a design system — so this page demonstrates the method on a single application, AcuteLine, rather than attempting a table that covers all of them. The other reference applications carry their own profiles on Reference applications, and they differ sharply: a screening operator who cannot grade the image, or a patient dosing at home with nobody to ask, is not a variant of the users below. Do not inherit this profile for your own device. Repeat the method.
| Group | Relationship | Characteristics that influence usability |
|---|---|---|
| ED registrar / consultant | Operates — primary | Frequently interrupted; gloved; standing; variable experience with the tool; shift fatigue; reads at 50–70 cm on a workstation or 1 m on a cart |
| ED nurse | Operates — acquisition | Acquires the ECG, manages electrodes; may never open the review screen; time-poor at triage |
| Cardiology on-call | Operates — escalation recipient | Arrives without prior context; may be off-site on a small screen; needs the whole picture in one view |
| Cath lab team | Uses the output | Never touches the software; receives a decision and a time. Their usability depends on what the notification contains |
| Clinical systems administrator | Supports | Configures alarm thresholds, escalation chains, filters. Errors here affect every clinician silently |
| Biomedical engineer | Maintains | Selects and calibrates displays, sets the deployment scale factor. Works from Scaling & displays |
| Quality / audit reviewer | Uses the output | Reads the audit trail months later with no memory of the shift. Their usability depends on the record |
Within every group above, assume the full range: colour vision deficiency, presbyopia, tremor, hearing loss, non-native language, first shift with the tool, and twelfth hour of a night shift. Accessibility in ISO's sense is broader than WCAG conformance — WCAG is the testable floor, not the definition.
Specified goals
A goal is an intended outcome and is independent of the means. A task is one particular means of achieving it. Most design documentation — including most of this system before this page existed — describes tasks and never states the goal, which makes effectiveness undefinable.
Task: acquire a 12-lead ECG; software analyses it.
Task: open ECG review; assess the trace; agree, disagree or record "cannot assess".
Task: activate the local pathway; notify the cath lab.
Task: acknowledge the alarm; record the assessment.
Task: override; request serial ECG.
The organisation's goal is to reduce door-to-balloon time. The clinician's goal includes not activating the cath lab unnecessarily at 3 a.m. Optimising the interface purely for the first produces over-triage; purely for the second produces missed infarcts. Almost every contested decision in this system — default sort order, alarm priority thresholds, whether disagreement is one tap — is a position on that trade-off, and should be argued as such rather than as a usability preference.
Specified context of use
Context of use is the combination of users, goals and tasks, resources, and environment. It is the part of this system that was always present in substance and never named.
The table below is one application's context, worked through in full. Every row would read differently for a device that sits elsewhere on the axes in Reference applications — a home-use device has no shared workstation, no hierarchy between registrar and consultant, and an expendable resource (the user's own cognitive capacity) that AcuteLine never has to consider.
| Component | AcuteLine |
|---|---|
| Users | The seven groups above. |
| Goals & tasks | As decomposed above. Tasks are frequently interrupted and rarely completed in one sitting. |
| Reusable resources | ECG acquisition hardware; workstation, cart and gantry displays; the patient record and any prior ECG; local chest-pain protocol; colleagues, including the on-call cardiologist; assistive technology. |
| Expendable resources | Clinician time and attention — the binding constraint. Also electrodes, network connectivity, and cath lab capacity. |
| Technical environment | Displays from 10″ carts to 4 K reading monitors; variable pixel density; touch and pointer input; intermittent connectivity; shared workstations. See Scaling & displays. |
| Physical environment | Bright resuscitation bay to darkened reading room; noise; gloves; vehicle motion; viewing distance 50 cm to 4 m; screens read off-axis. |
| Social, cultural, organisational | Handover at the keyboard; twelve people per workstation; hierarchy between registrar and consultant; multiple languages; local protocol variation; the knowledge that actions are attributable and auditable. |
Where the way a task is actually performed diverges from the way it is prescribed, that divergence is information about the context, not a discipline problem. The clearest example in this system: slow sign-in on a shared workstation is prescribed as individual authentication and actually performed as one shared account nobody logs out of. The design response is a faster badge-first sign-in and read-only locking — not a policy reminder. See Sign in / sign out.
The three components
Effectiveness — accuracy and completeness
The extent to which actual outcomes match intended outcomes, and the extent to which all intended outcomes are achieved. The two are independent: a queue can be perfectly accurate about every case it shows and radically incomplete because a filter hid eight of them.
- Accuracy — the correct priority is recognised; the correct patient record is opened; the clinician's conclusion matches the truth established later.
- Completeness — every case in scope is reviewed; no patient is omitted by a filter, a failed source, or a pagination boundary.
This is why no default filters and an empty state that proves liveness are completeness controls, not conveniences.
Efficiency — resources used for the results achieved
Resources are time, human effort, financial cost and materials. In this context the first two dominate, and human effort is the one most often left unmeasured.
- Time — time to acknowledge, time to decision, time from acquisition to pathway activation.
- Human effort — alarms handled per clinician-hour, number of screens traversed to reach evidence, mental effort of reconciling a model output with a clinical impression.
Expenditure of human effort can involve excessive demand or underload, and either can cause negative consequences. A model tuned so conservatively that a clinician rarely disagrees produces vigilance decrement: the reviewer stops genuinely reviewing. Efficiency measures that only ever reward "fewer actions" will miss this entirely.
Satisfaction — physical, cognitive and emotional responses
The most neglected component in clinical software, and the one where this system already does real work without having named it.
- Physical — glare, eye strain across a twelve-hour shift, reach and posture
at a wall display, discomfort from prolonged use of a cart. The warm white
--backgroundand the calibrated dark theme are satisfaction decisions. - Cognitive — attitudes and perceptions, explicitly including trust, perceived safety, perceived security and perceived privacy. All of Confidence disclosure is a satisfaction intervention: it manages whether the clinician's trust is calibrated to the model's actual reliability.
- Emotional — the affective response to using the tool under pressure. Alarm wording that is specific and actionable reduces stress; wording that is loud and vague increases it, and a warning phrased to alleviate stress rather than amplify it is a legitimate design requirement.
Use error
The term this system uses — imported into ISO 9241-11 from IEC 62366-1 — is use error: a user action, or lack of action, that leads to a different result than the manufacturer intended or the user expected. Never "user error" or "human error".
The distinction is not politeness. Use error is defined to include the user being unable to complete a task at all, and it typically arises from a mismatch between the user, the interface, the task and the environment — which places it squarely inside the designer's responsibility. Two consequences for how pages here are written:
- A malfunction is not a use error. A failed ingestion source, a dropped feed or a crashed analysis is a system failure. Both must be surfaced, but they belong in different parts of your risk file, and this system's pages distinguish them.
- Users may not know a use error occurred. Which is why silent failure modes — a filtered-out patient, a stale queue, an acknowledged-but-unread alarm — get more attention here than loud ones.
Measuring it
At least one measure for each of effectiveness, efficiency and satisfaction is normally required, and each can be measured objectively or as perceived by the user. The two frequently disagree, and the disagreement is itself a finding — a clinician who believes they reviewed a trace carefully and did not is a usability problem that no objective measure alone will surface.
| Component | Objective measures | Perceived measures |
|---|---|---|
| Effectiveness | Proportion of true findings correctly actioned · wrong-patient actions per 1 000 sessions · cases in scope not reviewed · agreement with adjudicated truth | Clinician's confidence that they reviewed every relevant case · belief that the queue is complete |
| Efficiency | Time to acknowledge by priority · time from acquisition to decision · alarms per clinician-hour · screens traversed to reach evidence | Perceived effort of a review · perceived interruption burden · perceived time spent versus actual |
| Satisfaction | Voluntary reuse when an alternative exists · override rate and its stability · acknowledge-without-open rate as a disengagement proxy | Calibrated trust in the model · perceived safety of acting on an output · comfort over a full shift · willingness to recommend to a colleague |
No single measure represents overall usability, and different measures of the same component can support opposite conclusions. Acknowledge-without-open rate appears above under satisfaction as a disengagement proxy and also functions as an efficiency measure; that overlap is expected and is a reason to report several rather than to pick a winner.
Learnability and maintainability
Both are usability considered for a different goal, not separate qualities.
- Learnability — effectiveness, efficiency and satisfaction for the goal of learning to use the system. The relevant users are a registrar on their first shift and a locum who will use it twice. Neither will read documentation, so the interface has to carry it — which is the argument for standard 12-lead ordering, permanent labels, and priority words rather than colours alone.
- Maintainability — the same for the goal of keeping it running correctly. The users are the systems administrator setting alarm thresholds and the biomedical engineer choosing a display. A misconfigured escalation chain harms patients as surely as a misread trace, and those screens currently receive a fraction of the design attention the clinical ones do. That is a known gap in this system.
Do's and don'ts
Named groups with characteristics, including the people who use the output and the people who maintain the system.
One word covering a registrar on their first shift and a consultant with presbyopia. Nothing can be evaluated against it.
All three components reported together, so a gain in one that was bought from another is visible.
Time alone. Optimising this rewards acknowledging without reading — the disengagement the system exists to prevent.
Clinical safety notes
This page is the context statement that every other page's guidance depends on. Trace it from the context-of-use section of your IEC 62366-1 usability engineering file.
- Guidance holds only inside this context. A rule validated for a gloved clinician at 1 m does not transfer unexamined to a phone in a corridor. Changing the context invalidates the rationale, not just the layout.
- Effectiveness requires stated goals. Without them, "it works" is unfalsifiable and no summative evaluation can be designed.
- Report all three components. Reporting only time-to-acknowledge rewards exactly the disengagement this system is trying to prevent.
- Objective and perceived measures both. Silent use errors are invisible to objective measures alone, because the user does not know they occurred.
- Maintainers and output-users are users. Excluding them from evaluation leaves a configuration surface that can harm every patient in the deployment.
Related
- Status & limitations — what in this system is validated and what is not.
- Accessibility — the outcome, beyond WCAG conformance.
- Scaling & displays — the technical and physical environment.
- Confidence disclosure — satisfaction as trust calibration.