Constructing appropriate menus and prompts

When appropriate, you should consider separating any introductory or instructive text from the prompt text; this allows you to reprompt without repeating the introductory text. For example, you might create one audio file that says, “Welcome to the WebVoice demo” and a separate audio file that says, “Say one of the following options: Library, Banking, Calendar.” The first time through the sequence, the application could play the files in succession. If the user returns to this main menu later in the application session, the application could play only the second audio file. For example, the first time the user hears:

Welcome to the WebVoice demo. Select Library, Banking, or Calendar. 

On the second and any subsequent times, the user hears only:

Select Library, Banking, or Calendar. 

If appropriate for your application design, you might even create separate audio files for each menu choice.

When presenting menu items, consider putting the most common choices first so that most users don't have to listen to the remaining options. For example:

Select List Specials, Place an Order, Check Order Status
or Get Mailing Address. 

A possible exception to this guideline is when the most common choice is a more general case of another choice. In this example, “Other loans” is presented last, regardless of its relative frequency of use:

Loan type?
 <3 second pause>
Select Car, Personal or Other Loan. 

Applications that require users to learn new commands are inherently more difficult to use. During the Design phase of your application development process, you will want to make note of the words and phrases that your users typically use to describe common tasks and items. See Design Phase. These are the words and phrases that you will want to incorporate into your prompts and grammars.

Regardless of whether your general style is terse or verbose, try to phrase prompts in a way that conveys the maximum amount of information in the minimum amount of time. For example, use:

rather than:

Sometimes, the most effective way to prompt the user is to word the prompt as a question. For example, use:

rather than:

Please choose from the inquiry menu:
Savings
Checking 

Question prompts are especially useful when the user can make a choice by repeating one of the options verbatim. You can also use question prompts to collect information, as long as the question restricts likely user input to something the application can understand. For example:

Use pronouns such as "it" and "one" to avoid stilted repetition of words. For example:

rather than:

When mixing menu choices and form filling in the same list, you will want to word the prompt to clearly indicate what the user can say. For example, use a prompt such as:

You should avoid using synonyms in prompts; these might mislead the user regarding valid input. For example, use:

rather than:

because the latter might cause the user to think that “query” is a valid response.

Whenever possible, the prompt text should guide the user to the proper word choice. For example:

Try to phrase prompts in a way that minimizes the likelihood of the user inserting extraneous words in the response. For example, if the system cannot interpret dates embedded in sentences, use:

or:

rather than:

because the latter is likely to elicit a response such as:

In general, if you can avoid voice spelling, you should. The letters of the alphabet are notoriously difficult for computers (and humans) to recognize.

If a user must perform voice spelling, then you can take advantage of the fact that some recognition errors are more likely than others. Table 2 shows the results of an experiment conducted to investigate patterns of recognition errors for the letters of the English alphabet. In the table, uppercase letters indicate substitution probabilities that exceeded 10%. Lowercase letters indicate substitutions that occurred during the study, but had substitution probabilities less than 10%.

For example, if a user rejects a returned K in a voice-spelling application, then the letter most likely to have actually been spoken is A. Fourteen of the letters in the table have only one substitution for which the probability of substitution exceeded 10%. Eleven of the letters don't have any substitutes for which the probability of substitution exceeded 10%, and six of those didn't have any substitutions at all. This means that whenever the system returns these letters (H, I, U, W, X, and Y), you can have very high confidence that the speaker actually said that letter. Only two letters (T and G) had two substitutes for which the probability of substitution exceeded 10%. Note that the substitution probabilities are not usually symmetrical (F/S and V/Z are exceptions). If the system returned a D but the user indicated that it was not correct, the letter the user said was most likely an E. If the system returned an E but the user indicated that it was not correct, the letter the user said was most likely a V.

There are several ways that you can use this information to improve the user experience when voice spelling. If the information that the user is spelling is unbounded (such as a user's last name), then you can offer alternatives in the order of their likelihood. For example:

You can also use n-best decoding to find likely substitutes. See Refining confirmation and error correction with confidence levels and n-best lists for details.

If the information that the user is spelling is bounded (such as a part number, or a list of users' last names in a database), then you can often detect and correct voice spelling recognition errors without involving the user. For example, suppose the user is ordering a part by its code:

<Returns F X H U F>
<Checks part number database>
<Doesn't find this number>
<Checks the following possibilities:
<F X H U S
S X H U S
S X H U F>
<Only third one is in database>

In the example above, the system created the different possible part numbers by using the information from the table of substitutions. Because there were no likely substitutes for X, H, or U, the system left them alone, and systematically changed F to S and vice versa.

Where applicable, you may want to word prompts in a way that “feeds the result forward” (that is, incorporates the user response) into the next prompt. For example:

Say Phone or Fax 

Which phone action?
Leave message
Camp
Forward call 

This technique provides feedback that the system correctly understood the response and also reinforces the user's mental model of the dialog state. Using this technique eliminates the need for cumbersome confirmation of every user input; however, you should still confirm user requests for actions that cannot be undone.

This section deals with error recovery only as it relates to prompt wording. See Error recovery and confirming user input for additional information about error recovery.

To promote faster error recovery, prompts should focus on keeping the dialog moving rather than on any mistakes. For example, if you are using self-revealing help, you should avoid having the system say:

because there is no evidence that this helps the user understand what to do next. See Implementing self-revealing help for guidance on how to keep the dialog moving forward with self-revealing help.

Similarly, it is best to avoid claiming that the user “said” a particular response, since the information you present is actually just a reflection of how the speech recognition performed. For example, use:

instead of:

You said 113. This is not a valid quantity.
Please restate your quantity.