Designing consistent dialogs

When users don't know what they can say at a given point in a dialog, the interaction between the user and the application can quickly break down. To help users avoid this “What can I say now?” dilemma, try adopting consistent sound and feel standards to create dialogs that behave consistently, both within your application and across your platform (if you support multiple applications).

Writing directive prompts

You should try to write prompts that clearly indicate to users what they can say. For example:

System: Say Yes, No, or Repeat.

or:

System: Travel to which US state?

or:

System: Select E-mail, Voice mail, or Faxes

Managing nondirective prompts

When you use a complex natural command grammar (or an NLU application) that can accept multiple tokens, you should use a nondirective prompt for the initial interaction with the user. The silence timeout that follows a nondirective prompt should be shorter than the standard default timeout of 7 seconds--typically about 3 seconds--to serve the dual purpose of providing a sufficient window for the more expert user to compose and begin speaking a multiple-token command but not making the less expert user wait too long to get the first self-revealing help message. Recent research has indicated that the appropriate first (and possibly second) levels of self-revealing help for these types of prompts should include examples of valid multiple-token commands. Users are often able to take a multiple-token example and replace the sample information with their own information. Only if these fail to lead the user to produce a valid input should the system switch to a one-token-at-a-time directed dialog. The following dialog demonstrates the successful use of an example:
System: What are your travel needs?
User: <nomatch or silent for 3 seconds>
System: For example, you might say “I want to go from New York to Orlando on December 1.”
User: I want to go from Chicago to Los Angeles on March 15.

The following dialog demonstrates the unsuccessful use of an example. Switch to directed dialog:

System:

What are you travel needs?
User: <nomatch or silent for 3 seconds>
System: For example, you might say “I want to go from New York to Orlando on December 1.”
User: <nomatch or silent for 7 seconds>
System: You might also try “Book a flight on Delta from New York to Orlando on December 1.”
User: <nomatch or silent for 7 seconds>
System: Departure date?

For NLU call routing applications, the examples should be acoustically distinct commands that connect users to frequently-requested destinations.

Maintaining a consistent sound and feel

When an application behaves in a way that the user did not anticipate, the user can become confused and/or frustrated and is more likely to respond inappropriately to subsequent prompts. This, in turn, causes the interaction between the user and the application to break down. To help users avoid this “But why did the application say that?” dilemma, try adopting consistent sound and feel standards (see Adopting a consistent “sound and feel”) to create dialogs that maintain synchronization between the application's actual state and the user's mental model of the application's behavior.

Reusing dialog components

You can improve application consistency and decrease user learning curves by reusing dialogs or dialog components where possible. Components you might reuse include:

Parent topic: Getting specific—low-level design decisions