Some Things Are Better Left Unsaid
Bad User!
It is not at all uncommon to be scolded by an application in the Dual Tone Multi-frequency (DTMF) world. To wit:
System: To do [this], press one. To do [that], press, two.
User: (presses DTMF three)
System: That is an incorrect response!
And while the tendency to scold is less prevalent in the speech world, it has not entirely disappeared. Consider the following:
System: What is your area code?
User: 123.
System: 1-2-3. Is that correct?
User: Yes.
System: You have provided an invalid area code.
You have to wonder about this tendency. Apparently, correcting others and pointing out their mistakes is intrinsically reinforcing for some people. Like the child who celebrates the misfortune of another child with the traditional nah-nah-nee-nah-nah taunt, some VUI designers just can’t seem to resist the temptation to scold their users.
And to what end? Beyond the dark pleasures apparently derived from dishing out a scolding, no good can come from the practice.
Such prompts should never be employed!
Besides being annoying and insulting to the user, such prompts are actually superfluous.
Behavioral Targets
What are the actual behaviors the DTMF designer above is trying to prompt?
There are only two: pressing DTMF one or pressing DTMF two. How does telling a user that he has made an “incorrect” response help move the user closer to one of those target behaviors? (Hint: It doesn’t.) Any prompt or any prompt content that does not stimulate one of those two responses serves no good purpose and is therefore superfluous.
In any event, it is always better to tell the user what he can do rather than what he cannot do. A better way to handle the DTMF three input might be:
System: To do [this], press one. To do [that], press, two.
User: (presses DTMF three)
System: For [this], press one. [That], two.
Generally speaking, it is a good idea for the system to “assume the blame” whenever these sorts of problems arise. In the speech example above, the system instead blames the user. A better way to handle the speech example might be:
System: What is your area code?
User: 123.
System: 1-2-3. Is that correct?
User: Yes.
System: Sorry but I couldn’t verify area code 1-2-3.
Would you like to try again?
While not perfect, the suggested alternative prompt implies that the “failure” is on the part of the system (“Sorry but I cannot verify….”) and not due to any shortcomings on the part of the user.
Let Me Tell You a Thing or Two…
Another effective way to condescendingly insult a user is to lecture him. Lecturing often occurs in “help” prompts but, like scolding, is also prevalent in error recovery routines. Consider the following example, taken from an insurance system. The prompt is an inactivity or timeout message which is read when the user does not respond:
System: Are you a provider or are you a subscriber?
User: (says nothing).
System: Feel free to interrupt me at any time. I need to know if you are a provider or if you are a subscriber. If you’re calling from a hospital, doctor’s office or other location where medical services are rendered, you are a provider. If you have a policy with us, you are a subscriber. At this point you can say, either “provider” or “subscriber.” You can also answer the question using your telephone keypad. To choose provider, press one. If you are a subscriber, press two. Please answer now. Are you a provider or are you a subscriber?
Off Target Once More
Once again, the designer has lost sight of the behavioral target. In an effort to thoroughly explain, define, inform, afford choices, etc., the prompt used in the example wastes the user’s time saying far more than what might be needed to obtain an answer. A much more effective strategy is initial repetition, followed by DTMF fallback:
System: Are you a provider or are you a subscriber?
User: (says nothing).
System: Are you a provider or are you a subscriber?
User: (says nothing).
System: Providers, press one. Subscribers, two.
Walter Rolandi is the founder and owner of The Voice User Interface Company in
Columbia, S.C. Rolandi provides consultative services in the design, development and evaluation of telephony-based voice user interfaces (VUI) and evaluates ASR, TTS and conversational dialog technologies. He can be reached at wrolandi@wrolandi.com .