If you’ve ever used a Polycom IP phone, you may be aware of a somewhat strange behavior. When you pick up the handset, you hear a dial tone. The problem is, you hear the same dial tone nearly all the time — even if the network connection is down and the phone can’t make calls. (The only exceptions seem to be if the physical network cable is unplugged, or you try to reboot the phone without a working network connection.) In this fashion, Polycom’s implementation of the dial tone sound violates the user’s expectations. A dial tone is supposed to give you the all clear to make calls, but now the sound plays even when it’s impossible to place a call.

More generally, the situation can be described as follows. The designer of the new version of a product (or an entirely new product replacing an old one) makes the smart decision to emulate the familiar behaviors of the old product. They employ visual cues, messaging, and sounds that help users become comfortable with the newfangled solution. But when some of these legacy characteristics don’t really apply anymore, or the old attributes are copied poorly, you get a mismatch.

When integrating these types of elements into a new product, the best approach is to think carefully about what each one means to the user and what information they expect it to convey. In the case of a dial tone, the solution would be to only play the noise when the IP phone has a working network connection and is communicating properly with the PBX server, thus restoring the value of the dial tone as a status indicator. By thinking this through, designers can make new products that are familiar and intuitive to users, even when the underlying technology is vastly different than what came before.

Updated on August 23: I added more details about the dial tone behavior on the Polycom IP phone, since there are some cases where it actually does stop playing the sound.