The notable example of alarm fatigue is the designated pillow on board of the Tu-144 (the Russian copy of the Concorde) to stuff into the alarm horn. The wikipedia page is itself a “bestof” bad engineering/operating practices, which are worth a good laugh now that it is not flying anymore. See chapter “Reasons for cancellation” - https://en.wikipedia.org/wiki/Tupolev_Tu-144
Most telephone hardware has some form of self-checking and fault detection. Alarms are classified into "minor" and "major", sometimes also "power" or "critical". Each piece of equipment has its own alarm indicator lamps, and contacts for external alarms as well. Typically the external contacts are wired to both an "aisle light" which aggregates all the equipment in that lineup, and a floor-wide or section-wide "alarm sounder". When the sounder goes off, you look down the aisle to see which lineup has the trouble, then walk down the lineup to find the individual unit and address the problem.
But first, you push the ACO button. The alarm cutoff button silences the sounder, which won't come back on unless something new happens. ACO also tells the other workers that someone is on the case.
Crucially, it preserves attention. If the sounder was going the whole time someone was working on a repair, nothing would ever get done, because the workers would be down at the corner bar trying to get some sanity back.
The designer responsible for an alarm wants to avoid being blamed for the operator missing that specific alarm so they're incentivized to make their alarm as prominent as they can get away with. Of course once most designers are doing that then they have to keep doing it or risk get drowned out.
One way to fix that is by having someone who is responsible for the entire experience who can dictate shared prioritization, requirements, alerting frameworks, rate limiters, etc. In cases where the operator uses multiple products from different companies (e.g. in a hospital) that's especially hard which is why there's a cacophony of noise even though everyone involved acknowledges that it's a problem.
Somehow this works just fine in telecom. I was handling equipment from DSC, Alcatel, Fujitsu, Marconi, Rockwell, Cerent, Nortel, Pirelli, CarrierAccess, Tellabs, Cisco, ADC, Lucent, and more. There are Telcordia and NEBS standards for alarm severity and wiring, and everything just works when you hook it up. Does the medical industry not have standards?
Ref:
https://www.ecri.org/alarm-safety-handbook
https://www.jointcommission.org/resources/patient-safety-top...
Everyone does it. I’ve caught myself doing it. So I move to the previous domino and work on that.
Red lights mean that the sensors have detected a state that may damage the car or put you in danger. You should stop immediately. Examples: low oil pressure, overheat, emergency brake still on, low brake fluid. You can safely tell a new driver that if they are driving and they see a red light on the dash it means stop right now.
Yellow means that something is operating outside of nominal ranges and you should try and fix it soon. Examples: low tire pressure, low washer fluid, check engine light.
If you're interested in specific stories I'd recommend "Set Phases on Stun" by Steven Casey. (It shows up in the syllabus of a number of Human-Computer Interaction classes.)
But as a general heuristic: If one operator has trouble dealing with the number of false alarms you can just hire a new operator, but if most of the operators find it problematic then the problem clearly isn't with the operators.
1: https://en.wikipedia.org/wiki/Alarm_fatigue