The Dialogue Specification

There is no standard way to represent a dialogue model. There are, however, some common elements that most specifications include. This section will discuss the various components common to most dialogue specifications.

What Needs to be Represented

The dialogue design specification is the document that provides the team and clients with a model of the project. As much as possible, the specification must represent the macro view of the application as well as the fine details at the more micro level.

The Elevator Pitch

A short text description of the system provides the team with a useful synopsis. Think of this synopsis as the "elevator pitch"—a paragraph that describes what the system does in 30 seconds or less. Stating the goals in three sentences or less is a useful indicator of the clarity of the project. Having a unified way of describing the project ensures that everyone has the same understanding of the project. (If the project cannot be described in a few succinct sentences, the project might not be ready to move forward.)

Call Flow Diagram

The dialogue specification should include a fully realized visual representation of the call flow. This representation usually requires one or more diagrams in order to illustrate the logical call flow for the system.

Dialogue State Tables

These tabular representations of each dialogue state in the system are one of the main components of the specification. Typically, these tables include the following information:

• A unique name or ID
• The names or IDs of any dialogue states that can call into the current state
• The active grammars
• Some number of uniquely named prompts
• The default text for each prompt
• The expected user inputs
• The destination state (or prompt response) for each user input
• All other active grammars or commands
• The destination state (or prompt response) for each command
• Any additional necessary notes

See Also

Dialogue Organization