The Art of Writing Perfect Prompts

The art of writing the perfect prompt is to convey ideas clearly and concisely. No extra words. No fuzzy language. A well- constructed prompt guides the caller to say only things the recognizer will understand. If a recognizer is able to understand almost everything that a caller might say in a particular context, then the prompt can be less directed. For example, a system might just say "Hello, and welcome to Thrifty Car Rental. What would you like?" Callers might say hundreds of thousands of things to answer this question, and thus the recognizer would have to be able to recognize most of them to be successful. Most recognizers don't work this way at the moment. If, however, the recognizer is looking for a particular word (such as a manufacturer of automobiles), the prompt must direct callers to answer specifically . For example, by having the prompt ask, "What's the automobile manufacturer?" instead of "What type of automobile?" we could minimize the chance that callers would say words such as "van" or "sedan."

In addition, prompt language must be consistent with:

• The original concept of the design

• The way the company expresses itself in other media

• The rest of the text spoken in the application

Writing Effective Initial Prompts and Commands/Command Phrases

Initial prompts must convey ideas clearly so callers can understand what they are expected to say. This doesn't mean that we need to provide callers with a long, drawn-out explanation at every turn of the dialogue. Once we establish that a particular calling population is comfortable with a speech-recognition system ”and once we confirm that the caller has successfully answered some basic questions, like "Is that correct? Yes or no?" ”then we can start to drop the "Yes or no" part and just ask the basic question.

As we've already discussed, it's important to be clear and consistent when writing prompts that present a list of options. For example, it may not be a good idea to have an initial prompt that says:

"Main menu. You can say ' Reports ,' 'Exchange,' or 'Security.'"

The problem? There might be little or no context for the options ”and the words themselves offer few clues. Both "Reports" and "Exchange" can be either nouns or verbs, and "Security" could refer to anything from data encryption to insurance coverage.

If, however, we rewrote the prompt so that all the selections were expressed in the form of imperative sentences that provide greater precision, callers could quickly understand the ideas ”and their responses would also feel more conversational:

"Main menu. You can say 'Get the reports,' 'Make an exchange,' or 'Change my PIN.'"

Consistency is always important when designing prompts or when those prompts contain commands that the caller is to use later on. For example, the Wildfire Communications "voice-activated personal assistant," also called "Wildfire," uses the command "Describe it" to enable users to hear information about their phone messages (rather than listen to the actual message), such as the time the call arrived. But the clever thing about the design is that the user can say "Describe it" for any object ”and Wildfire will tell the "header" information about that object. If a user said, "Describe it" while working with an e-mail message, Wildfire would tell the caller additional information about that message, such as who sent it, the subject of the message, and so on. By teaching the user a single command ”and employing it consistently throughout the application ”Wildfire makes it easy for its users to get more out of the system without learning new commands.

Designing Effective Retry and Timeout Prompts

How many retry and timeout prompts should a system give a caller before considering it a failure? I generally recommend presenting no more than two; anything more is likely to irritate a caller.

While it's sometimes acceptable to repeat the same prompt twice, often the designer will want to vary them to give the caller more information to help them answer the question correctly or get them back on track. As with help prompts, the best way to begin writing a retry or timeout prompt is by answering the question "Why would the caller not have said something valid at this point?" By considering all the possible answers to that question, we can write prompts that address most ”if not all ”of them. Many of the possible answers relate back to examining how the original prompt was written. For example, if we were designing a system for a motel by an interstate highway (frequented largely by travelers arriving by car or truck), we might assume that we needn't ask "Will you be parking a vehicle in our lot?" Instead, we'd skip ahead and ask, "What's the make and model of your vehicle?"

However, there will be at least a few people who won't be traveling to the motel by car or truck, but by bus, taxi, or maybe even on foot . The question "What's the make and model of your vehicle?" does not apply to them ”and they wouldn't know how to skip the question. A retry or timeout prompt could circumvent this by saying "If you aren't bringing a vehicle, just say 'Let's go on.' Otherwise, what's the make and model of your vehicle?"

A similar situation arises when a caller embarks down a path they either didn't mean to take, or no longer wishes to take. A retry prompt can get the caller unstuck by including the phrase " or if you don't want to be here say 'Main menu.'"

To be more foolproof, retry and timeout prompts should include further information about how to answer the question, but not so much information that it overwhelms the caller. Often the easiest way to do this is by providing a quick example. Instead of "Say the model year and make of your vehicle," the retry prompt could be "Say the model year and make of your car; for example, '1969 Mercedes-Benz.'" This tells the caller what format to use in answering the question.

An alternative is to suggest the touchtone equivalents to spoken answers, as in this example: "You can say 'Get the reports' or press 1, 'Make an exchange' or press 2, or say 'Change my PIN' or press 3." This approach is obviously better suited to questions with a limited number of possible responses ”not hundreds, as in the vehicle example above.

Finally, all retry and timeout prompts should offer to direct callers to either the help prompt or a "live" representative, as in this example: "You can also say 'Help' or press the star key, or press zero for an operator."

Designing Effective Help Prompts

The help prompt is often the hardest to write, because the sequence of events leading up to the situation isn't tracked. Did the caller say "Help" immediately after hearing the initial question ”or after two timeout and two retry prompts? We could be dealing with callers in greatly varying states of mind ”from mildly confused to frustrated and irate.

When writing help prompts we again ask ourselves , "Why would anyone not know how to answer this prompt?" We need to ensure that the caller knows

• Why we're asking the question

• Where they are in the dialogue

• How (e.g., the format) to answer the question correctly

• How to get more help (e.g., talking to a "live" representative)

• How to escape this state to a "safety" zone (e.g., a main menu)

Here's a typical initial prompt and the help prompt that went with it.

Initial Prompt : At what airport, or city, are you picking up the car?

Help Prompt : Sometimes, rates and availability can depend on the location where you're picking up the car. Thrifty Car Rental has locations at airports throughout the U.S., Canada, and also in the rest of the world. <pause> To specify an airport, just say the name of the city and state you're interested in.

Note the use of the pause in that prompt. In this context that pause serves as a way to separate the background explanation from the command that the caller should react to ”the pause gives a rhythmic break to regain the caller's attention.

Designing Effective Confirmation Prompts

Confirmations are an essential part of any design ”even if they seem casual and unobtrusive ”and they come in two varieties: explicit and implicit.

An explicit confirmation is when the system prompts the caller to answer a direct question before proceeding. For example: "OK, I think you'd like to buy 100 shares of Apple Computer, symbol AAPL, at the market price. Is that correct?"

This type of confirmation is best used when the risk of an unrecoverable error is present. To further prevent mistakes caused by misinterpretation of a caller's response, you can employ one of the following methods .

• The system can ask a "yes/no" question; for example, "Is that correct? Yes or no?"

• The system can ask the caller to say a PIN or a special password to confirm the transaction ”or say "Cancel it" to cancel the transaction. This method assumes that the recognizer will not confuse the words "Cancel it" and the caller's password.

• The system can supplement the password confirmation by asking the caller to enter a number using the touchtone keypad to confirm or cancel. For example: "You have requested to purchase 100 shares of Apple Computer, symbol AAPL, at the market price. To confirm this transaction, press 1. To cancel, press 9." (If you use this method, attempt to avoid numbers that are close to each other on the keypad.)

• The system can disable the caller's ability to truncate the playing of a prompt by saying something or entering a touchtone number. If the system is programmed to disable this feature only during confirmations, it will prevent callers from accidentally assuming that the transaction is correct before hearing the entire confirmation statement. This method also reduces the liability of the company in the event of an error because it proves that the company did its best to ensure that the caller heard the entire statement before confirming it. It's worth noting that many companies save recordings of caller transactions to defend themselves in the event of any legal action ”usually to defend themselves from callers who claim that the machine made a mistake when, in fact, the system actually did exactly what the caller requested.