Alert fatigue and the economics of interruption
Alert fatigue is one of the few usability problems in clinical software that everyone agrees exists. Agreement has not helped much, because the mechanism that produces it is structural rather than attitudinal, and the structure keeps rebuilding itself.
Warnings accumulate by addition
Almost every alert in a mature system was added for a defensible reason, by someone responding to a specific incident or requirement. Very few were ever removed, because removal requires someone to accept responsibility for the silence. The result is a set that grows monotonically and is curated by no one.
This is an interface problem disguised as a governance problem. No individual addition is unreasonable. The set is unreasonable, and no one owns the set.
What an override rate measures
When a warning is dismissed almost every time it fires, the usual interpretation is that users are not reading carefully. The more economical interpretation is that the warning is usually wrong, and that the people dismissing it have learned this faster than the system has.
Attention is finite and is spent, not summoned. A screen that interrupts a hundred times a day for things that turn out not to matter is not training people to be careless; it is training them, quite rationally, that this particular channel does not carry information. The channel then cannot be used for the rare case where it would have mattered.
Not everything should be able to stop the work
The most useful structural change is usually to separate the alerts that may stop a task from the alerts that may only annotate it, and to make that separation architectural rather than a matter of judgement at authoring time. A hard stop is an expensive instrument. If everything can reach for it, it stops being expensive, and stops working.
Passive presentation deserves more credit than it gets. Something rendered inline, next to the thing it concerns, at the moment the person is already looking there, is read far more often than a modal that arrives after the decision has been made and asks the person to reconsider it from a standing start.
Writing the alert itself
Alert copy is frequently written as though its job were to record that a warning was issued. It names a rule, cites an identifier, and leaves the reader to work out what to do. Copy written for the reader instead answers three things in order: what is the situation, why is it being raised now, and what are the available responses.
The third is the one most often missing. A warning with a single button marked Acknowledge does not offer a response; it offers a formality. If the only available action is to proceed, the interruption has no purpose that a quieter inline note could not serve.
Signs the set has drifted
A few patterns are worth watching for, none of which require special instrumentation to spot. Alerts that fire on nearly every instance of a common action. Alerts whose text has not been revised since the system they referred to was replaced. Alerts that fire after the irreversible step rather than before it. And alerts that people have learned to dismiss before they render, which is visible in how fast they disappear.
The last one is the most telling. When the median dismissal is faster than the text could possibly be read, the alert has become a keystroke, and it should be treated as a defect in the design rather than a lapse in the reader.