Messaging
Eight surfaces in this system tell a clinician something. Choosing between them by how important the message feels is how a ward ends up with four things flashing and nobody reading any of them. The vehicle is chosen by what the message obliges the reader to do, and nothing else.
A message that must not be missed is never transient. Anything that disappears on a timer has been designed on the assumption that the reader was looking, and the reader is frequently not looking.
One message, one vehicle. The same fact delivered as a banner and a toast is two messages as far as the reader is concerned, and the second one teaches them the first can be ignored.
Why this page exists
Every component that carries a message documents itself well. None of them can tell you whether they are the right choice, because that question is only answerable by looking at all of them at once. This foundation is the only place in the system that does.
The failure it exists to prevent is not a badly written message. It is a well-written message in the wrong vehicle — a critical result as a toast that faded while the clinician was turned away, a routine confirmation as a modal that has to be dismissed forty times a shift, a device fault as a chip nobody has any reason to look at.
The vehicles
| Vehicle | Obliges the reader to | Ends when |
|---|---|---|
| Alarm / alert banner | Act, or explicitly decline to act | The condition resolves, or a person acknowledges it |
| Dialog | Decide, before anything else can happen | They decide |
| Toast | Nothing | A timer expires |
| Status chip | Nothing — it describes an object they are already looking at | The object's state changes |
| Badge | Nothing — it counts things elsewhere | The count changes |
| Inline field error | Fix the field before submitting | The input becomes valid |
| Empty state | Nothing — it proves the system looked | There is something to show |
| Progress | Wait, or leave and come back | The work finishes or fails |
Read the middle column and the choice is usually made for you. A confirmation that a note saved obliges the reader to do nothing, so it is a toast. A haemodynamic alarm obliges them to act, so it is not.
Choosing
Four questions, in order. The first answer that applies decides it.
| Ask | If yes |
|---|---|
| Is a patient at risk if nobody sees this? | Alarm banner, at the priority its condition warrants under IEC 60601-1-8, persistent until resolved or acknowledged. Nothing else is admissible, and the cost of over-using it is covered under volume. |
| Must the reader choose between options before the software can continue? | Dialog — but see blocking, because most things that feel like this are not. |
| Does it describe one object the reader is looking at? | Status chip or inline text, on that object. A message about a row belongs in the row. Moving it to the top of the screen severs it from its subject and makes the reader match them up by hand. |
| Would the reader be materially worse off for missing it? | Persistent banner, dismissible only by resolving it. Degraded mode, an unreachable source system, an expiring credential. |
| None of the above | Toast, or nothing at all. "Or nothing at all" is the answer more often than it is chosen — see volume. |
Transient means "safe to miss"
A toast is a claim about consequences: if you did not see this, nothing is lost. That is the only thing its timer can honestly mean. Using one for anything else is not a styling decision, it is an untrue statement about risk made in a component.
Toast & notification queue already forbids alarms, results and errors in a toast. The general form of that rule:
- Nothing with a consequence dismisses itself. If missing it costs anything, it stays until a person deals with it.
- Nothing the reader must fix is transient. An error that vanishes takes the instructions for fixing it along.
- A queue is not persistence. Letting toasts pile up while each still expires gives the appearance of a record and the behaviour of none.
- Hover-to-pause is not a mitigation. It requires the reader to already be looking, which is the assumption in question — and roughly half of the surfaces this system targets have no hover at all, per Interaction & states.
Blocking has to be earned
A dialog stops everything. That is justified when the software genuinely cannot proceed without a decision, and at no other time.
The test is whether there is a real branch. "Save changes / Discard / Cancel" is a branch. "Your session will expire in 5 minutes — OK" is not; it is a notice wearing a decision's clothes, and its only button restores the state that existed before it appeared. Information does not block. It goes in a banner, where it stays visible without holding the clinician still.
Two conditions on any dialog that survives that test:
- It never appears over an unresolved alarm. Covering an active alarm to ask about anything is a defect regardless of what the dialog is for — see Elevation & layering, where the alarm layer sits above everything a dialog can reach.
- It never steals a keystroke. A dialog that appears under a clinician's hands takes the next Enter as an answer to a question they have not read. Newly-appeared dialogs do not accept confirmation for a short interval, per Motion.
Volume is the whole problem
Every rule above is about which vehicle. In practice, messaging systems fail on quantity, and the clinical name for that failure is alarm fatigue. A system where the right message is always in the right vehicle and there are two hundred of them a shift has achieved nothing.
So the budget is part of the design, not an operational concern discovered later:
- Every message class carries an expected rate — per patient, per shift — stated when the message is designed, not measured after complaints. A message whose rate nobody can estimate is a message nobody has thought about.
- Interruption is rationed explicitly. The number of things permitted to take a clinician's attention away from what they are doing is small and enumerable. If it cannot be enumerated, it is not rationed.
- A message that is almost always ignored is removed, not restyled. Making an ignored message louder converts a wasted message into a harmful one, because it spends attention that the next real message needed.
- Rates are monitored in the field. Design-time estimates are guesses; Suppression & alarm limits covers what to do when reality disagrees, and the answer is never to give the clinician a mute button and stop asking.
When a message changes vehicle
A pending result that becomes overdue, a degraded mode that becomes a failure — the condition changes and the vehicle should change with it. Three rules make that safe:
- Escalation is upward only within a single episode. A message that has become an alarm does not quietly become a chip again because the number drifted back over a threshold. It resolves or it is acknowledged.
- The reader is told it escalated, and from what. A banner that appears with no history reads as a new event, and a clinician who already dismissed the chip version deserves to know it is the same thing.
- Escalation never duplicates. The chip becomes the banner; it does not accompany it. Two live representations of one condition is the "one message, one vehicle" rule broken across time instead of across space.
Outcomes of use
What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.
- Effectiveness — the messages that matter are seen. The mechanism is entirely negative: they are seen because the others were not sent.
- Efficiency — a clinician is not stopped to be told things. Most of the time lost to messaging is lost to dialogs that had no branch in them.
- Satisfaction — an interface that interrupts rarely is trusted when it does. This is the attribute most directly destroyed by treating message design as a component-level concern.
Do's and don'ts
Note saved — a toast, three seconds.
Obliges the reader to do nothing and costs nothing to miss. The timer is telling the truth.
Critical result available — a toast, eight seconds.
The timer now asserts that missing this costs nothing. It is the most consequential claim on the screen and it is false.
A persistent banner: Pathology feed unreachable since 04:10. Results may be incomplete.
Stays until it is true again. Nobody has to remember it, which is the point of putting it on a screen.
A modal: Pathology feed unreachable. [ OK ]
No branch, so no decision. It stopped the clinician to tell them something, then removed the information when they acknowledged being told.
Row 4 · Awaiting review
The message is attached to its subject. Nothing has to be matched up by hand.
Top of screen: 1 study is awaiting review.
Severed from its subject. The reader now has a search task instead of a message.
Escalated from "awaiting review" at 04:12 — now overdue.
One condition, one live representation, with its history. The reader knows this is not a new event.
A banner, a toast and the chip still on the row.
Three artefacts, one fact. The reader learns that two of the three can be ignored, and cannot tell which two.
Clinical safety notes
Trace these in your risk file (ISO 14971) and usability engineering file (IEC 62366-1).
- Nothing with a consequence is transient. Mitigates: a clinically material message expiring unseen while the reader was turned away.
- One condition, one live representation. Mitigates: duplicated messaging teaching clinicians that a class of message can be ignored.
- Blocking requires a real branch. Mitigates: modal fatigue, and the reflex dismissal it trains — which lands on the one dialog that mattered.
- No dialog over an unresolved alarm, and no dialog accepting a keystroke on appearance. Mitigates: an alarm obscured, and a decision made by a hand already in motion.
- Every message class has a stated expected rate. Mitigates: alarm fatigue designed in and discovered in the field.
- Ignored messages are removed rather than amplified. Mitigates: attention spent on a message nobody acts on, at the cost of the next one.
- Escalation is upward, announced, and non-duplicating. Mitigates: a recurring condition read as a series of unrelated new events.
Related
- Alert banner — the priorities, and what each one is for.
- Toast & notification queue — the specific prohibitions this page generalises.
- Dialog — the branch test, at component level.
- Suppression & alarm limits — what to do when the rate turns out to be wrong in the field.
- Acknowledge & escalate — what acknowledgement means, and why it is never bulk.
- Voice & tone — once the vehicle is chosen, the words.
- Elevation & layering — which vehicle may cover which.