Prompt Writing Guidelines
.jpg) |
It is useful to follow specific guidelines for writing each type of prompt effectively. Prompt language should be consistent with company language, character and be true to the intentions of the design.
For the purposes of this discussion, the words "dialog" and "state" are interchangeable and refer to a particular node in the interaction model.
Top-level Prompts
Normally, the first prompt the user hears after the system enters a dialog or state, the top-level prompt asks a question, and the remaining prompts in the state support the resulting interaction. When authoring top-level prompts for a given state, writers should consider how open-ended the question should be. Does the prompt need to include specific command language to correctly guide the user, or is it an opportunity for a more natural-sounding opening?
For example, in the case of an auto attendant, the top-level prompt of the first dialog state could easily be either of these two options:
"Who would you like to call?"
Or
"Say the first and last name of the person you'd like to call."
In a complex application such as an airline's information and reservation system, the system invites users to choose the type of information in which they are interested. In this case, prompting for command language will guide users to speak the words that the recognizer will be able to recognize.
"Welcome to Blue Yonder Airline's reservations and information line. To find out about arrival and departure times for a particular flight, say INFORMATION. To book a flight, say RESERVATIONS."
Writing several variations on the top-level prompt can allow the actor and producer to find the best possible match of wording and voice at the time of the recording session for the prompts. Often there are multiple possibilities for a top-level prompt that deliver the identical meaning with slight variations in vocabulary or word order. It is worth recording the best of these, because it will allow for choices later on when putting the system together. In addition, for personalized systems with known users, varying the top-level prompt can add to the enjoyment of the system in the long term.
Misrecognition Prompts
A system will normally play two misrecognition prompts in sequence if the recognizer is unable to match the user's utterance to currently active grammars. If these retry attempts fail, the system will give up on the interaction and either transfer the user to a live operator or return the user to a previous node in the system in order to attempt the interaction again.
Designers and prompt writers should ask themselves what causes a caller to respond out of grammar. Usability testing will most likely answer this question after the system is running, but while the system is being designed and written, it is helpful to continually imagine all the possible problems that callers might be experiencing that would lead to a misrecognition.
- They do not know how to answer the question.
- They are answering the question but the wording of their response is out of grammar.
- The question is presented so that the grammars are not able to cover all the possible answers.
- A bad connection or ambient sound from the caller's environment has triggered the recognizer.
There are differing approaches to writing level one misrecognition prompts.
Error Message Plus Restatement
The prompt begins with a version of an apology and error statement, and then repeats the main prompt, perhaps with a slight wording variation. Here is an example from an auto-attendant speech system:
| SYS_MAIN: | Would you like me to call the OFFICE number, the MOBILE number, or SEND an E-MAIL? |
| CALLER: | Home |
| SYS_MIS_REC: | Sorry, I didn't catch that. What would you like to do? Call the OFFICE, the MOBILE or send an E-MAIL? |
| CALLER: | Mobile |
| SYSTEM: | Sure. Just a moment please. |
The "Could you repeat that please?" Gamble
A natural sounding but somewhat riskier method is simply asking:
"Could you repeat that please?"
The advantage of using this prompt is that it closely models a real interaction—in the face of an indecipherable utterance, a person would normally request that the caller repeat himself or herself. Although "Could you repeat that please?" is literally a YES/NO question, the meaning of the idiom is so universally accepted and understood that this is not usually a problem for the caller, who will typically restate his or her answer to the original question rather than answering yes or no.
Error Message, Plus Examples of Commands
A more direct but less polite method is to use an error message and give examples of available commands. This helps the caller understand the exact language that will work with the active grammars. The only consideration is whether to use this type of prompt for a level one misrecognition or wait until level two. It is longer, sounds less natural, and could annoy an expert user.
For example:
| SYS_MAIN: | Would you like me to call the OFFICE number, the MOBILE number, or SEND an E-MAIL? |
| CALLER: | Home |
| SYS_MIS_REC: | Sorry, I didn't catch that. You can say CALL THE OFFICE, CALL THE MOBILE, or you can tell me to SEND AN E-MAIL MESSAGE. |
Apologies and Error Messages
Some speech systems use precisely the same language for the error messages that precede the misrecognition and silence prompts throughout the entire interface. This method gives the caller a consistent cue that an error message will follow. For example:
| MIS_REC_1: | I'm sorry, I didn't understand. Do you want me to send an e-mail? |
| MIS_REC_2: | I'm sorry, I still didn't understand. If you want to send an e-mail, say SEND etc... |
Or, in the case of time-outs:
| TIME_OUT_1: | I'm sorry, I didn't hear you. Do you want me to send an e-mail? |
| TIME_OUT_2: | I'm sorry, I still didn't hear you. If you want to send an e-mail, say SEND etc... |
Other systems vary the error messages, using different language, which, although clearly signaling an error message, adds more variety to the user's experience. In the context of a system that users access multiple times per day or week, these variations can add longevity.
Silence Prompts
Normally a system will play two silence prompts in sequence, after a predetermined interval of n seconds, before it gives up on the interaction and transfers the caller to a live operator, or returns the caller to a previous state to attempt the interaction again.
There are two different methods for writing the first silence prompt:
- Repeat the original question, that is, the top level prompt, sometimes preceded by an error message, sometimes including a slight variation in wording but without any additional information.
- Provide additional information to the user.
Example—No Additional Information:
| SYS_TOP_MAIN: | Would you like that gift-wrapped? |
| CALLER: | Silence... |
| SYS-SILENCE: | I'm sorry, I didn't hear you—did you want gift-wrapping for your purchase? |
| CALLER: | No... |
Example—With Additional Information:
| SYS_TOP_MAIN: | Would you like that gift-wrapped? |
| CALLER: | Silence... |
| SYS_SILENCE: | I'm sorry, I didn't hear you. If you'd like your purchase gift-wrapped, please say YES. Otherwise, say NO and we'll send it as is.? |
| CALLER: | No... |
There are positive and negative points for each of these approaches. The first approach sounds more natural, whereas the second makes the system easier to use by clearly instructing the user on the available options. To decide, the writer must consider the possible reasons why the users did not respond.
- They did not hear the question.
- They did not understand the question.
- They did not know the answer to the question.
- They were formulating their answer when the time-out period ended.
- They were doing something else, and were distracted.
- They responded, but because of unreliable mobile connections, the system did not hear anything.
For about half of these cases, the user might benefit from additional information. For the remainder, additional help-type prompting could be irritating for users, particularly if they are expert users of the system. A user can barge in and interrupt the system if the prompt is giving unnecessary information, and a user can always explicitly ask for help and receive context-specific instructions. Some designers argue that help is more effective when explicitly requested by the user.
The designer and prompt writer can analyze instances of the first-level time-out prompt on a case-by-case basis to determine which approach works best for the specific audience. Perhaps if the state occurs early in the interaction, more information is appropriate. If only a YES/NO response is needed, then the first approach might be entirely adequate.
By the time the interaction arrives at the second silence prompt, additional information can be included automatically. Designers can explicitly direct the caller to ask for help if the second silence prompt does not include the full range of caller actions. An apology and error statement should precede the second silence prompt.
For example:
"I'm sorry, I still didn't hear you. Please say GIFT WRAPPING if you want..." and so on
The same discussion of varying as opposed to consistent error messages applies here, just as it does with misrecognition prompts.
Help Prompts
Writing useful and effective help prompts can be difficult for several reasons:
- It is unclear why or when the user is asking for help.
- The mumble and silence prompts may have already revealed all the help information.
Because the caller has actually asked for help, the prompt can be comprehensive and long-form. See Delivering Help.
Failure, Success Prompts
The last category of commonly used prompts is success and failure prompts. These are basically self-explanatory.
In a system where live operators provide support, a failure prompt will precede the transfer of the user to an operator. If two levels of error prompts have failed to assist the user successfully, then the system will give up on the interaction and play a failure prompt, such as:
| SYSTEM: | I'm sorry I wasn't able to help you. I'll connect you to an operator. |
In this particular case, the system transfers the user to a live person for further assistance. In another situation, the system may send the user back to some logical point in the dialog where he or she is free to try again or do something else.
The main issue when designing and writing success prompts is the placement of the prompt. A slot might reside at the end of the dialog state. Alternatively, success statements might reside in the main prompt of the next dialog state in the flow.
Designers should be careful not to err on the side of overusing success prompts. Exclamations of "Great," "Thanks" and "Got it" every time the user successfully traverses a node are not recommended, as they will quickly become annoying. Modeling these positive responses on normal conversational frequency is the best approach.