Design of Individual Dialogues

Once the initial designs for the call flow are complete, the next step is to determine what the default dialogue behavior will be for the system.

Real world users are unpredictable, and the system design needs to accommodate the wide variety of dialogs that may occur. For every node in the conversation, the designer needs to employ a consistent strategy or set of behaviors that can gracefully accommodate the range of unpredictable turns the conversation may take.

In the voice user interface (VUI) world, this is a relatively simple task because, at their most basic level, all VUI interaction models are primarily composed of a collection of recognition and non-recognition states.

• Recognition states prompt the user for some input.
• Non-recognition states are effectively output only.

Since a non-recognition (or output) state does not require input from the user, error handling is generally not an issue. For the moment, this section will focus on the basic strategies most commonly used to handle errors and commands within a recognition state.

Basic Dialogue Components

In designing dialogs, the challenge is in maintaining context. Some of the dialogue components are:

• Main Prompt
• Silence Prompts
• Misrecognition Prompts

Context, in dialogue design parlance, refers to a system's ability to demonstrate awareness of a conversation's progress. Whether on step one of a four-step process or restating a question in step three for the second time, the prompts should include language that reflects the context of what has come before and what will follow.

By using simple tracking techniques and support prompts, designers can maintain context, which makes the system more relevant and helpful.

Recognition States

Typically, a recognition state has a main or initial prompt that is played on entry, plus a number of other supporting prompts that either restate the question or directive in a contextually appropriate way or offer help as the user traverses the state. Successful recognitions proceed to the next state.

One of the most common schemes in use today involves:

• A main or initial prompt
• A first silence prompt
• A second silence prompt
• A first mumble prompt
• A second mumble prompt
• A help prompt

Other common elements employed in some systems are:

• A success prompt
• A cancel prompt
• A status prompt
• A repeat prompt
• A correction prompt

The next few sections examine each of these prompts in more detail to explore how using them may affect the design of an automated interaction.

Main or Initial Prompt

This is the default or entry prompt for the dialogue. Generally, this prompt is played on first entry. All other prompts in the state support this prompt.

Tracked Entry Prompt

In some cases a design may call for a tracked entry. Uses may vary, but a tracked entry for a main prompt is usually used to track first time entries, rather than subsequent entries, to a dialogue and adjust the prompts accordingly. For example, if a system's design allows users to loop back to a dialogue where the initial prompt was "Who should I invite?" the tracked entry prompt might say "Who else should I invite?" on all subsequent entries.

There are other types of common tracked entries. Some dialogue states have multiple points of entry or calling states. To maintain linguistic context, it may be necessary to have slightly different wording of the main prompt.

Silence Prompt

By tracking the number of times the system does not hear anything from the caller, specific prompts can address the error in ways that are appropriate to the context.

Usually, there are two levels of silence time-outs followed by a give-up prompt.

No Recognition or Mumble Prompt

By specifying additional variables to store the number of misrecognitions, the system is able to track how successfully the user is negotiating the dialogue and respond with increasingly specific help messages.

The maximum value for these prompts is at the discretion of the system designer. Currently, two is the norm.

Give-up or Failure Prompt

A give-up or failure can either send the user back to some predetermined state in the system to try another approach, or the system may offer to connect the user to a live operator. Any number of different behaviors can be applied to a give-up event, but in general, it is triggered when the user reaches the maximum threshold for retries.

Responding to Client Disconnects

If Telephony Application Services is deployed on a system using an analog telephony card, user hang ups may go undetected. In this case, the SALT application might continue repeating the dialogue until the next process or application domain recycle. The ideal case is that the application monitors the number of attempts to get a successful recognition, and terminates after that number is exceeded. Use the History property of the QA Client Object to see how many times the QA control has been activated on the client.

Keeping Score

The give-up prompts either can be shared across silence and misrecognition or can be specific to both. Give-up is triggered when either count exceeds the maximum value specified in the design.

Another possible design strategy favors an approach where the error total is cumulative. In other words, one silence followed by a misrecognition counts as two errors. If a third error of either kind occurs, the system plays a give-up prompt.

An advantage of this design is that the system needs only to observe the error and count the number of attempted passes through the state without actually remembering the nature of each individual error. The disadvantage is a slight loss of context.

Currently, the individualized error-counting approach is most commonly used.

Help

This is a context-sensitive help prompt that is triggered when the user invokes the system's help command. The help command is usually global in scope and is therefore generally available anywhere in the system. It can be trapped locally in the prompt function by querying the Command/Exception History in applications created with the Speech Application SDK.

Cancel

The cancel prompt acknowledges the user's request to exit the state. Typically, when exiting a state because of a cancellation request from the user, the system will return to some task-appropriate signpost or landmark.

The cancel prompt can also discourage users from exiting a multi-step interaction that they have nearly completed.

For example,

"Are you sure you want to give up now? There are only two more steps to go!"

See Also

Dialogue Organization