VUI Design

As mentioned in previous sections, a VUI can be broken up into dialog states - even mixed initiative/NLU dialogs. So a VUI can be documented in the following way:

Description

This is in effect the executive summary. What does the a application do? Who are the target audience for the application? What special requirements are there for the application?

You should also include some reference to the standard dialog state model that'll be used. So if every state has a help prompt, escalating error prompts, repeats a prompt if the caller doesn't make any input, etc. Whether there is barge-in or not. All this should be mentioned.

Call Flow Diagram

This diagram shows the call flow - everything from the welcome state (normally just a prompt) through to the final goodbye state (also just a prompt). Yes, a single prompt can also be a "state" - particularly as you might want to determine whether barge-in is turned on or not.

Normally there is no need to document all the possible noinput/nomatch error handling. This is covered by the dialog state itself. Here's an example of a very basic call-flow state diagram:

Dialog States

Now you have to describe all the dialog states. This could/should cover:

• A description of the purpose of this dialog state
• Are there any special requirements for this state?
• What dialog states can preceed this one?
• Is barge-in turned on?
• Are any global grammars active?
• A list of all the prompts associated with the state
• Which dialog state(s) to go to after this one
• Are there any particular back-end/techical issues associated with this state?

Using this document it should be possible to program the voice user interface. It should detail all the prompts, which prompts are to be used for which caller groups, what order the prompts come in, which grammars are active, what special issues need to be borne in mind when writing the VoiceXML code. For instance, normally <noinput> is treated as an error. However, if you're presenting a long list, then quite often <noinput> means move on to the next element in the list. Quite often you will have different prompts for different caller groups. You may have a different prompt if you re-enter the state having been at other states in between. All this information should be packed into the dialog states in order to complete the UI design.

Prompts

If you format your document properly (admittedly using Word), you can mark or format all your prompts/snippets as being prompts. Then you can automatically generate a list of prompts from the document, which you can use for the recording session.

If you have any comments, ideas, issues, etc. about this topic why not try the voice-push forums