8.3 Prompt Design

When you design prompts, you must communicate clearly to the caller, appropriately capture the persona of the application, keep the caller engaged, maximize caller success and comfort, and avoid ambiguities. Much of the look and feel of the application will depend on the wording of prompts. Chapter 10 covers many of the specific guidelines and lessons about prompt wording. Here we discuss the methodological issues.

There are well-understood methodologies for writing prompts in a way that will lead to natural-sounding, comprehensible communication. The single most important point is to bring the design experience close to the user experience. This is what we mean by conversational design, one of the basic methodological principles discussed in Chapter 3. Conversational design has two aspects, both of which grow out of the fact that you are designing a spoken language experience for your callers. First, you should design prompts in their conversational context, and second, you should experience the prompts in an auditory mode.

8.3.1 Conversational Design

The key to conversational design is to think about each prompt in its conversational context. You do this by writing sample dialogs that traverse many of the possible paths through the application. A sample dialog is an actual conversational sequence, specifying both the system side and the caller side of a conversation. By working out the prompt wording through the creation of sample dialogs, you will be thinking of the prompt wording in context. You should craft a large set of sample dialogs, covering prompts throughout the application. Some of the sample dialogs should cover error recovery and help prompts.

Many current tools encourage an approach to prompt design that involves a complete specification of all the prompts related to one dialog state (e.g., initial prompt, error prompts, help prompt), followed by a specification of all the prompts related to the next state, and so on. This approach often leads to stilted-sounding applications because the prompts are not conceived in context. Creating sample dialogs can solve the problem.

The following is a real example of two versions of a bill-paying application. The first version was written with a standard tool, going state-by-state, writing all the prompts for each state (i.e., not in conversational context).

(1)

CALLER:	Bill payment.
SYSTEM:	What bill would you like to pay?
CALLER:	MasterCard.
SYSTEM:	How much would you like to pay?
CALLER:	Two hundred and fifteen dollars.
SYSTEM:	What date would you like the bill to be paid?
CALLER:	August first.
SYSTEM:	Confirming: You'd like to pay MasterCard in the amount of two hundred and fifty dollars on August first. Is this correct?
CALLER:	No.
SYSTEM:	Which part would you like to change?
CALLER:	The amount.
SYSTEM:	How much would you like to pay? [same recording as first-time request]

We were called in to review and then rewrite the prompts for the system. We created new prompts using sample dialogs. The following was the result for the same path through the application:

(2)

CALLER:	Bill payment.
SYSTEM:	Sure, "bill payment." What bill would you like to pay?
CALLER:	MasterCard.
SYSTEM:	How much would you like to pay?
CALLER:	Two hundred and fifteen dollars.
SYSTEM:	And on what date would you like it paid?
CALLER:	August first.
SYSTEM:	Let me confirm that: You'd like to pay MasterCard in the amount of two hundred and fifty dollars on August first. Did I get that right?
CALLER:	No.
SYSTEM:	Which part did I get wrong?
CALLER:	The amount.
SYSTEM:	Sorry about that. What's the correct amount?

Clearly, this is not a scientifically valid comparison of the two techniques, given that different designers were involved. However, it is instructive to look at the nature of the differences between the two examples. Notice how much better the second version flows (try reading them both aloud). Notice the extra words, which help relate a prompt to what came immediately before it (e.g., "Sure, …", "And …").

It is especially instructive to compare the final prompt in each example. In both cases, the final prompt is resoliciting the amount to be paid. In the first example, the final prompt, "How much would you like to pay?" is merely a reuse of the recording used the first time (every time callers enter the Amount state, that is the prompt played). In the second case, a different prompt is played, given that the Amount state is entered following a disconfirmation (it is entered in order to resolicit the amount, after an error). In this case, the prompt is written in a way that shows more conversational awareness. To begin with, the first clause of the prompt functions as an apologetic acknowledgment. Furthermore, the word "correct" is given informational focus through emphasis.

The difference in the final prompts is an example of a general guideline for prompting: To account for conversational context, it is often necessary to provide multiple possible initial prompts in a dialog state. The choice of which initial prompt to play should be conditioned on the immediate dialog history. You should always check all dialog histories for a state (e.g., all possible predecessor states) and determine which ones would benefit from alternative versions of the initial prompt. This need will become obvious if you design your prompts through sample dialogs.

The improvements in prompting based on sample dialogs bring value not only because the resulting conversation is more cohesive, but also because it is more comprehensible. Chapter 10 covers, in detail, the issues surrounding the crafting of prompts.

Sample dialogs afford the designer a view of otherwise discrete messages and prompts with the full benefit of context, as an interaction between the caller and the system's persona. Designing your application via generous sample dialogs ensures that the design process closely parallels the user's experience. It is hard to imagine how a persona-rich application might be created without the illuminating perspective afforded by sample dialogs.

8.3.2 Auditory Design

The caller is engaged in a spoken language interaction. As discussed in Chapter 10, spoken language is fundamentally different from written language. Given the differences between spoken and written language, humans have very different expectations when reading than they do when hearing language.

To be sure that you have an accurate view of your prompts, it is essential to listen to them. We strongly recommend saying your prompts out loud as you craft them. Additionally, it is extremely valuable to read through sample dialogs with a colleague, one of you providing the voice of the system and the other the caller. Even very experienced designers will react differently when they hear their prompts actually spoken.

We have had the experience a number of times, when working with customers, that they react negatively to a dialog spec as they read through the prompts, often complaining that they are too "informal." However, if we present customers with prerecorded sample dialogs, those same prompts often sound fine to them.

Using the two techniques described in this section crafting prompts through the creation of sample dialogs, and reading those dialogs aloud you can move your design experience closer to the way the user experiences your system. We have observed significant improvements in the quality of prompts when designed in this manner. Using this approach will help you use your own innate conversational capabilities as you craft prompts.