Dialogue Organization

This topic discusses grouping application functions and services into domains, which will provide logical groupings for the dialogues.

A domain is a set of call flow functions that are grouped into logical task boundaries. For example, a hypothetical system may contain the Welcome Domain, Catalog Domain, MyAccount Domain and Checkout Domains. Each of these areas represents a logical grouping of functions and services, represented by dialogues.

Function or Service

Domains are usually organized either by service and then function, or by function and then service. No rules dictate which way is best. It depends on the application and requirements. Often one organizational style or the other provides obvious benefits, and is therefore the logical choice. At other times, factors such as business requirements or system constraints may guide the decision.

Domains as Places and Things

Users must have a clear mental model of the system. This overall view helps them in several important ways. Task completion is far easier if users understand where they are and what features are available from a given location in the system. Signposting is a common technique for helping users to understand the system layout and navigate it more easily.

Signposting means referring to domains as places or objects, and in doing so, helping users paint a mental picture of the system. They use this mental map to learn their way around the system. When prompts specifically refer to places and objects, users are encouraged to make similar references.

Examples of signposting prompts are:

"We're at the desktop. From here, you can..."

"I have your calendar open. To schedule an appointment say..."

Constrained Domains

Organizing domains into manageable groupings also helps limit the number and size of active grammars. Systems that offer users an extensive vocabulary at any one time risk lower recognition rates as a result.

Modal or Modeless

Modal designs constrain users to one domain in the application until some appropriate transition is reached, after certain information is received and confirmed, or on explicit request from users. Modeless designs permit a transition to another domain depending on a single user response or command. Sometimes, if too many commands are simultaneously active, errors can occur in which a user's utterance can move the dialogue in unexpected ways. This unintentional migration may cause confusion and possibly amplify the errors.

For example, consider a design for a large, voice-based virtual assistant that was originally modeless. Calendar commands were available from anywhere in the system, as were those that controlled the address book and e-mail. While this seemed like a good idea from a design point of view, giving users great flexibility within the application, users were often confused by its inexplicable transitions from one task to another. In reality, the system was occasionally recognizing certain commands incorrectly. For example, the system sometimes migrated to another subtask or part of the dialogue model on the mistaken belief that the user had initiated a command from some other functional area of the system. When it formulated the appropriate prompt for the next turn in the dialogue based on the error, the apparent change in the direction of the conversation often mystified users.

The solution was to more strictly enforce the modality of the domains and signpost them. To transition to other areas of functionality, users had to make specific requests to "open my address book." This modal behavior helped users develop and maintain a clearer and more predictable vision of the system.

For Further Information

The following table lists other topics discussing dialogue design.

To	See
Get more information on user interface psychology.	The Psychology of User Interfaces
Get more information on design of individual dialogues.	Design of Individual Dialogues
Get more information on call flow.	Call Flow
Get more information on semantic information.	Semantic Items
Get more information on confirming answers.	Confirmation Strategies
Get more information on implementing menus and lists.	Menus
Get more information on providing help to users.	Delivering Help
Get more information on dialogue specifications.	The Dialogue Specification
Get more information on usability testing.	Usability Testing
Get more information on logging and reporting.	Logging and Reporting