Sounds Exciting

Sounds, beeps, buzzes and clicks can make a useful addition to your user interface, or they can form the most exasperating parts. Subtle sounds can give feedback that a button press was detected and less subtle sounds can inform you that urgent action is required or your machine, or car, or patient might be permanently damaged. But badly designed sounds can annoy the user, and those near to the user.

One common assumption that your system is the central focus of the user’s attention. That leads to the assumption that if your device is making an ‘urgent’ noise then it will be attended to quickly. This violates another rule, that I often refer to, that states that the designer should always assume that the user is very busy. While you are designing one piece of medical equipment, it is easy to forget that the user may be responsible for thirty pieces of equipment spread across six patients. When your device starts beeping urgently, it may mean that a patient needs urgent attention, or it might mean that the machine is sitting at the side of the room waiting to be used, and it is not interacting with a patient in any way. So for urgent noises, it is important to investigate use-cases of the worst case, most dangerous, scenario, but it is also important to investigate the most benign case to find out if the harmless case is going to lead to nuisance noises.

Another common decision is to sound a buzzer if the device is stuck in reset, or in some ‘not working properly’ mode. I recently worked on an after-market automotive device that did this. If some configuration parameters were not set up right, then the device would beep constantly. It seemed reasonable, since you never wanted to drive down the road with the wrong configuration parameters. The problem was that the device would often be like this in the workshop while the vehicle had wiring installed. While the vehicle was being worked on, no one cared about the configuration, but the noise drove everyone nuts – they used to ring me up rather than e-mail me just so I would hear how annoying the background noise was so that I would add an override feature.

You should always give some thought to whether noises can be silenced for these special cases. For the service guys, the ideal thing would be a simple dip switch to turn off the buzzer, but of course the danger with that sort of measure is that it would be left turned off when the device is shipped (or a user would turn it off) and then the buzzer would be disabled in the field. So you have to find a balance between ‘easy to override’ and ‘hard to accidentally override’. The solutions tend to be application specific.

If the user can not override the sound, then it can lead to undesired behaviour.Consider a pasanger seat with a weight sensor, that will beep if the vehicle moves while the seat belt is open. Now a driver who regularly leaves a bag of shopping on the passanger seat gets beeped at even though there is no passanger present - just a bag of groceries that weight enough to be a small person. So the driver plugs the seat belt in and leaves it that way permanently, just to make sure the beep does not happen. Of course this makes it more difficult for a real passanger to put on the belt on the occasions when this driver has a passanger, and it might even discourage this passanger from using the belt at all, which is the opposite of the original design intention. If the original warning sound been only temporary and more subtle then the driver may not have felt obliged to work around it, and so the problem might have been avoided. Again there is a trade of between making the sound so annoying that the user can not ignore it, and allowing for the case where that sound is actually a false alarm.

When designing a sound, always consider whether it is just for the ears of the user, of if other will hear. If you have a ‘failure sound’ (usually implied by a descending tone), when the user presses an illegal key, then the people near to the user will hear it and get the impression that the user is doing badly (if the user is a doctor, and the patient can hear the ‘wrong key’ noise then that can reduce the patient’s confidence in the doctor !). No user will thank you for announcing to the world that they pressed the wrong button, and these users will quickly want to silence the device. Having an easy to access mute or volume facility is vital for any noise-making device. Beeps that might be very subtle in noisy lab environment may be deafening in a library.

For the urgent noises that you might not want to volume control, consider having long silences between the beeps. If a noise is too intrusive, then the user’s priority is to silence the noise, and not to solve the problem. In medical devices I often see staff silence an alarm before they make any attempt to see the alarm message or to asses the patient. It is obvious that their first thought was ‘How do I stop the noise- it is driving me nuts’ when their first thought should be ‘What is the patient care issue that needs to be addressed’. Design noises to inform the user, not to bully them into responding.

My next post will point out some particularly bad uses of sound, and some particularly good ones. In the mean time, if you have any examples of your own, let me know.