In the human-automation interaction, few tools are more important than the alarm. When they are used effectively, they get the user’s attention when it’s needed. Alarms help support optimal performance and the fact that we don’t have to monitor the system constantly helps garner safety and efficiency.
In the healthcare arena, alarms are used quite heavily, and they are entrusted to save lives. They are the last line of defense. Surgical heart rate monitors, for example, must get a clinician’s attention quickly enough to enact a medical intervention. And because of those critical applications, the stakes couldn’t be higher. What happens when an alarm doesn’t work the way it’s supposed to?
As human factors researchers, our job is to maximize the the productivity of the human-computer interaction, increase comfort, and minimize the risk…all at the same time. When it comes to alarms, especially those in medical devices, it is imperative that we spearhead the efforts to making safe, reliable, and successful alarms in a variety of devices and products. While there are many more human factors details to consider, we put together a small compilation of highlights, with specific regard to alarms, to help guide their design in products and devices.
There are four main phases of the human-alarm interaction; an error may occur at any stage:
- Detecting the alarm
- Determining the cause of the alarm
- Determining a response to the alarm
- Executing the response
It is critical that we design alarms with all four phases in mind. If, for some reason, an alarm does not successfully complete its job, the first place to start is to identify in which phase the error occurred. The next steps in fixing the problem would then depend on the phase at fault. (Hint: it may be multiple!)
We can close our eyes, not our ears.
While we can shut our eyes to cut off visual signals, we just can’t do that with our hearing. Because they are so difficult to ignore, auditory signals produce a much higher rate of compliance than visual alerts do. If your alarm needs the user’s attention, and you are able, implement an audible alarm. If it’s on a computer, or something else that requires use of a screen, a visual alarm that can’t be minimized until the problem is resolved, may also do the trick.
We must walk a fine line, of course. Having said all this, alarms that can’t be ignored can be quite annoying. Ever tried to sleep through a fire alarm or a barking dog next door? They are effective, but must be used sparingly– only when immediate compliance is critical.
If the alarm should tell the user where the problem is, include visual signals.
Localization using the auditory system is limited. Human hearing is great at interpreting locations of sounds on the horizontal axis (either side of our bodies), but is not when it comes to the vertical axis or front-to-back. Check out this video found on a favorite YouTube channel called Smarter Every Day— while its core subject matter isn’t necessarily human factors directly, it showcases our hearing abilities in an interesting way.
In order to accommodate for this, it can be useful to include some kind of visual stimulus in addition to an auditory one. It is an effective combination: the auditory alarm would, as was mentioned previously, do a better job of getting the user’s attention. Meanwhile, visual stimuli would indicate where problem is located. Some kind of a flashing light or other conspicuous signal could be extremely useful in searching for targets that need user attention.
To guarantee detection, make auditory alarms loud and variable.
The alarm should be set at least 15dB above the environmental noise level. It is also a good idea to have various frequencies represented in the tone itself. Alarm sounds should be as different as possible from not only one another, but from environmental sounds as well.
Aspects of the noise can be tweaked to make it more noticeable; the pitch, envelope, rhythm, and timbre can all be changed to fit your needs. As a starting point, it’s a good bet to create a sound at the opposite end of the pitch and frequency spectrums from environmental noises. For example, in a factory with many loud, high-pitched sounds, an important alarm should probably be one on the lower side of the spectrum. It should also be some frequency that will be heard even if workers are wearing ear protection. Increasing the contrast would be helpful
Alarms must not frighten, overwhelm, or otherwise incapacitate users more than is necessary.
Many alarms can be startling. Just as many can be frightening, depending on what they are alarming for. But, especially when the stakes are high, it is critical that the alarm does not overburden the user. Remember, its true goal is to be helpful.
One way this can be accomplished is to limit how much the alarm startles users, have it start at a lower intensity (volume or brightness) and incrementally grow to something more detectable. In this way, the alarm won’t blare obnoxiously right off the bat, but will catch the user’s attention nonetheless.
Also consider including a ‘mute’ or ‘decrease volume’ feature that would allow the user to minimize distraction so that they can attend to addressing the alarm’s cause. This functionality must be used with caution, however, because while alarms can be overwhelming, they are often providing a very important message: Something is wrong and you need to fix it, right now! Extensive human factors testing is highly recommended because it’s likely that the alarm may risk is a huge factor in life or death situations.
Build trust in the alarm.
Ensure the entire system is robust and accurate. It is essential to build trust in the alarm, and it just won’t happen if false-alarms or missed events occur too frequently. (See: Boy Who Cried Wolf)
In addition to developing a high-quality, robust product, there are some measures one can take to keep trust in the picture. Consider training the users about the tradeoff of misses and false alarms so that they can accept when either occurs. Trust is lost when the user expects one thing and then doesn’t get it. If the system is going to fault every now and then, simply teaching the user about the odds and tradeoffs may help maintain trust.
Additionally, if it’s possible to do so, provide ‘raw data’ that may help explain why an alarm went off. Don’t let the product be a black box full of magic where the user has no clue what’s happening inside. Provide the numbers behind the operation of the product so that those can be examined after the fact. It may be that the user cannot do anything about the faulted alarm, but the key is that he or she understands why it happened.
For obvious reasons, alarms are often needed to get the user’s attention. Alarms used in medical devices often signal The risk and severity of consequences is variable, but when push comes to shove, the same principles apply. Using human factors principles in the design of alarms truly can save lives: from increasing signal detectability or developing an alarm the user can trust, there are multiple ways to make alarms more user-friendly, and therefore more effective.
For more detail on human factors implications in alarms, check out An Introduction to Human Factors Engineering: A Beta Version by Lee, Wickens, Liu, and Boyle (2017).