Home > Resource Center > VUI-Design > Effective Voice Prompts

Effective Voice Prompts

Writing prompts is far trickier than the novice Voice User Interface (VUI) designer may realize. When you develop your voice applications, don't leave the final wording of your prompts until the very end. Instead, invest at the outset in the careful crafting of your prompts.

Below are some quick tips to help you write effective prompts. Combined with thoroughly testing your applications end to end and listening carefully to how the prompts sound in context (e.g., how real callers react to them), you will see a marked improvement in your application's performance.

Error Prompts
Two important error prompts are the no-input and the no-match prompts.

A no-input prompt is triggered when the application is unable to detect any voice or keypad (also called DTMF for Dual Tone Multi Frequency) input from the user. That usually means that the user is confused as to what to say, and the prompt should accordingly provide helpful information to direct the user on what to do.

A no-match prompt is triggered when the application is unable to interpret the voice or DTMF input from the user. That usually happens when the caller did not fully understand what the application is expecting of them.

A prompt that simply says, "Sorry, I didn't hear anything," is not helpful for dealing with a no-match or no-input scenario. A more helpful prompt would be one that said, "I didn't understand that. Please speak or enter your social security number. You can also say 'help' for more instructions on how to use the system."

Confirmation Prompts
There are two types of confirmation prompts: (1) explicit and (2) implicit.

1. In an explicit confirmation, the prompt echoes back the information it thought it was given by the caller and explicitly requests a yes/no answer to its explicit confirmation request.
   
2. In an implicit confirmation, the application either echoes back the information without requesting any confirmation feedback, or does not echo it back at all.

Confirming means repeating, and you want to be judicious about repeating information. Repeating every bit of information that you obtain from a caller will annoy the caller and make the application sound robotic.

You should use explicit confirmation only if the information that you are collecting is "crucial", and/or when you are about to execute an action that may be costly to undo (e.g., transferring money from one bank account to another bank account).

Content Feed Prompts
Treat prompts with critical information differently from other prompts.

If the information provided by the prompt requires the caller to write down the information (e.g., a confirmation number), at the very least warn the caller, but better yet, give them a chance to get ready by saying, "I am about to give you your confirmation number; when you are ready to write it down, say, 'go on.'"

After the information is given, immediately let the caller know that the system can repeat the information for them. "Would you like me to repeat the information to you?"

Selection Prompts
Here are some quick things to keep in mind when designing selection prompts:

1. Put the most frequently requested options at "the top" of the menu.
   
2. Use the same part of speech/clausal form when listing menu options:
   * Bad prompt: "You can say, Balance, Transfer, or Withdraw".
   * Good prompt: "You can say, Check balance, Transfer funds, Withdraw funds".
   
3. If you have more than one menu in your application, be consistent across menus.
   
4. If you enable callers to enter DTMF, let them know early on that they can punch the keypad (but don't repeat the instruction at every step).
   
5. Limit the number of choices to 3 or 4.
   
6. Unless necessary, avoid the construct, "For X, say X, for Y, say Y, For Z, say Z." Generally, a better way to provide menu selections is to use the construct, "You can say, X, Y, or Z."
   
7. Allow callers to barge-in when listing a menu. This is especially useful if the menu is listing more than 4 items.

Incremental Prompts
Incremental prompts are used when the default caller is expected to be an "expert" user of the application. For instance, if most callers are frequent users of the system and are going to know what to say at the main menu, it is best to open with a succinct, even cryptic prompt, and introduce a more explicit prompt only when necessary - e.g., if the caller does not respond within a timeout period or if they ask for help.

For example, a stock quote application could bluntly open with, "Welcome to Hot Stocks. Which stock?" If the caller does not respond within some timeout period (i.e., gets confused), the system could then come back with, "You can say, IBM, Microsoft, Sun, or Apple."

Tapering Prompts
As a general rule, you don't want your system to be needlessly redundant within a prompt or across the call. A system that robotically repeats itself is exhausting to listen to and a waste of the caller's time.

Needlessly wordy: "IBM is trading at 52.15 dollars, up 1.20. Microsoft is trading at 67.51 dollars, up 0.70. Apple Computers is trading at 37.78 dollars, up 2.67."

Using tapering: "IBM is trading at 52.15 dollars, up 1.20. Microsoft at 67.51, up 0.70. Apple Computers at 37.78 , up 2.67."

In the next issue of the newsletter, I will touch on the topic of measuring how your voice application is doing so that you can take the next step of tuning its performance. If you have any suggestions for what you would like to see in future newsletters, please feel free to email me directly at bouzid@angel.com.

Ahmed Bouzid