See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221034540

Voice User Interface Design Patterns.

Conference Paper · January 2006

Source: DBLP

CITATIONS READS

33 6,343

2 authors:

Dirk Schnelle-Walka Fernando Lyardet

modality.ai 63 PUBLICATIONS   787 CITATIONS   
72 PUBLICATIONS   257 CITATIONS   
SEE PROFILE
SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Multimodal Standards View project

All content following this page was uploaded by Dirk Schnelle-Walka on 14 January 2014.

The user has requested enhancement of the downloaded file.

 Voice User Interface Design Patterns
Dirk Schnelle and Fernando Lyardet
Telecooperation Group
Darmstadt University of Technology
Hochschulstraÿe 10
D-64283 Darmstadt, Germany
{dirk|fernando}@tk.informatik.tu-darmstadt.de
phone: +49 (6151) 16-4267
fax: +49 (6151) 16-3052

Abstract
We present in this paper a set of design patterns we have mined in
the area of Voice User Interfaces (VUI). In a previous paper [14], we
introduced several patterns regarding fundamental issues of developing
a voice application. In this paper we explore further aspects concerning
the internal structure of an audio interface, the construction of the in-
teraction style, the system response architecture, and implementation
strategies to meet the demands of real world scenarios.

1 Introduction
Voice User Interfaces are particularly dicult to build due to their transient
and invisible nature. Unlike visual interfaces, once the commands and ac-
tions have been communicated to the user, they are not there anymore.
Another particular aspect of VUI is that the interaction with the user in-
terface is not only aected by the objective limitations of a voice channel,
but human factors play a decisive role: auditive and orientation capabilities,
attention, clarity, diction, speed, and ambient noise.
The design patterns presented in [14] demonstrated that it is possible to
build a language to talk about VUI designs. In this paper we continue build-
ing this new pattern language, focusing on the dierent dialog strategies,
auditory design, and usage scenarios.
The structure of the paper is as follows: we rst provide an overview
of the whole pattern language. Afterwards, we introduce the discovered
patterns grouped by the VUI design aspect they address: Interaction Style,
the organization of a spoken response and a nal set of patterns that address
voice usability issues in large scale settings.

B3-1
 2 OVERVIEW

Dialog Strategy System Response Usability

Form Filling Persona Busy Waiting

Menu Hierarchy Structured Audio Language Selector

Mixed Initiative Context Aware Call

Figure 1: Categorization of Audio Patterns

Information Provide increasing
Structured Audio Spreading levels of detail
Convey the right upon user’s request Escalating
Provide structural amount of Detail
information information
Detailed Let user
Enable the user
Information know what
with interaction means
she can do Scripted
Provide detailed Index Interaction
information about the
current topic upon Decorate the options
user’s request Direct the user with further information
User
for new users
Provide the user
Present the options
with queues of current
on-going acitivity, Use the native language Decoration
trail-followed
Collect information Language Selector
Active Reference
from the user
Menu Hierarchy
Fall back for Provide the user
Novices Mixed Initiative with additional
information, while she
Form Filling is passivley waiting
Use contextual
Define a look&feel
information to Busy Waiting
preset data
Context Aware Call
Persona
Define a look&feel

Figure 2: Relation of Audio Patterns

2 Overview
In this section we present patterns we have mined and categorized according
to their main purpose. An overview is given in gure 1. The existing pat-
terns in the language (taken from [14]), marked with a grayed box, are not
described in this paper.
The patterns belong to a language we started in [14], as shown in gure 2.
These new patterns expand the language in important areas of VUI de-
sign, closer to how the actual process of VUI design development actually
takes place. In this context, the election and development of an appropriate
dialog strategy is a rst step designers must take when building a VUI inter-
face. Menu Hierarchy serves as general organizational scheme for many
Audio Patterns. Novel designers would naturally apply it, although it is just
one characteristic of a dialog strategy. Further dialog strategies are explained
in section 4.1. Another major design concern described later in section 4.2

B3-2
 3 CHALLENGES WITH AUDIO

Problems inherent to audio Technical problems

Speech is one-dimensional Speech synthesis quality
Speech is transient Speech recognition performance
Speech is invisible Recognition: Flexibility vs. Accuracy
Speech is asymmetric

Table 1: Challenges of an audio only application

focuses on the system output or rather, the system response. Note that the
system response structure will be underlying the dialog structuring and in-
teraction mechanisms implemented later, thus becoming the cornerstone of
how the overall user interface will be perceived.

3 Challenges with Audio

Nowadays, the design of ecient speech interfaces is considered by many to
be more an art than an engineering science. This thesis is also supported by
Junqua in [10] who concludes his book with the challenge:

Today building the dialog component of a conversational system

is more an art than engineering or science. We need to develop
techniques for dialog design that are grounded on strong theo-
retical frameworks.

Patterns and pattern languages oer an approach to design with much

potential [3]. The patterns described in this paper continue to build a
pattern language to talk about VUI design.
An application designed for audio only input and output faces several
challenges, shown in gure 1, before it can be named easy to use. Some of
them are named in [11].

Speech is one-dimensional The eye is active whereas the ear is passive,

i.e. the ear cannot browse a set of recordings the way the eye can scan
a screen of text and gures. It has to wait until the information is
available, and once received, it is not there anymore.

Speech is transient Listening is controlled by the short term memory. Lis-

tening to long utterances has the eect that users forget most of the
information that was given at the beginning. This means that speech is
not the ideal medium for delivering large amounts of data. An advan-
tage of the transient nature of speech is that people can perceive visual
and aural information in parallel. Because of this property, speech is
ideal to deliver information without forcing the user to switch context.

B3-3
 3 CHALLENGES WITH AUDIO

Speech is invisible It is dicult to indicate to the user what actions she

may perform and what words and phrases she must say to perform
these actions. This invisibility may sometimes leave the user with the
impression that she does not control the system.

Speech is asymmetric People can speak faster than they type, but can
listen much more slowly than they can read. This has a direct inuence
on the amount of audio data and the information being delivered. This
property is extremely useful in cases where we have the possibility
of using additional displays to supplement the basic audio interface.
We can use the displays for delivering information which is unsuitable
for audio due to its length, and focus on using the audio device for
interaction and delivering short pieces of information.

Speech synthesis quality The quality of modern text-to-speech engines

is still low. In general, people prefer to listen to pre-recorded audio
because it sounds more natural. However, for this to work, the data
to be delivered has to be known in advance and recorded as audio,
which consumes additional memory. For dynamic documents, where
the content depends on the user's actions, text-to-speech may be the
only feasible solution.

Speech recognition performance Speech is not recognized with an accu-

racy of 100%. Even humans are not able to do that. There will always
be a doubt in the recognized input which has to be handled somehow.

Flexibility vs. Accuracy Speech can have many faces for the same issue
and natural language user interfaces must serve many of them. This
has a direct impact to recognition accuracy. To illustrate this trade
o between exibility of the interface and its accuracy, consider the
following example for entering a date. A exible interface would allow
the user to speak the date in any format the user desires (e.g., March
2nd, yesterday, 2nd of March 2004, etc.). Another possibility would
be to prompt the user individually for each of the components of the
date (e.g., Say the year, Say the month, etc.). Obviously, the rst
method is much more exible for the user, but requires much more
work from the recognition software, and is far more error-prone than
the second approach.

The rst four items, one-dimensionality, transientness, invisibility, and

asymmetry, are inherent to audio. It will be impossible to solve them com-
pletely, but it is important to know them and to nd a workaround. The
following items, quality of TTS, recognition performance, and exibility, are
technical problems by their nature. We assume that they can be solved
somehow, see gure 1.

B3-4
 3 CHALLENGES WITH AUDIO

<<extends>>

Novice Use of a Development of a

Voice User Interface Voice User Interface

<<extends>> User VUI Designer

Experienced User

Figure 3: Simplied view on roles involved in VUI design

Existing guidelines [2, 5, 8] are essentially restricted to giving hints to

master these challenges. This paper continues the development of a pattern
language [14] integrating many guidelines and solution approaches developed
during the past 15 years. The goal is to document and share this knowledge
with new designers (see gure 3) as well as providing a language to talk
about Voice User Interface (VUI) designs. The notation of a pattern lan-
guage allows for such a required theoretical framework that was requested by
Junqua. An example implementation of each pattern is given. The scenario
of our examples is at a car inspection, where a worker processes a list of
work items. We use VoiceXML for the example code and a specication of
the tags can be found in [18].
Some of the pattern descriptions feature a section about known uses. In
general, this is a real telephony application which can be called. Some of the
phone numbers may incur calling charges. It is also possible that they are
not accessible from outside of Germany.
Figure 3 shows a simplied overview of the roles involved in VUI design.
Novices are users that have not used the application before, and are neither
familiar with the concepts of the application nor the grammar they can use.
Experienced users have a systematic understanding of the application and its
functionality. The VUI designer develops the application and the concepts
on how to present it to the user.
For some of the patterns we suggest to use a wizard-of-oz experiment [6].
This is a well known strategy taken from the eld of human-computer in-
teraction. Test persons interact with an application which they believe to
behave autonomous. Actually it is operated by an unseen human being, the
wizard. Instead of real voice recognition, the user's input is manually entered
into the system and processed as a text stream rather than an audio stream.
These experiments should reveal information about use and eectiveness of
the application.
The name of the experiment comes from The Wonderful Wizard of Oz
story, in which an ordinary man hides behind a curtain and pretends to be
a powerful wizard.

B3-5
 4 VUI DESIGN PATTERNS

4 VUI Design Patterns

4.1 Dialog strategy
As GUI-based applications, voice applications interaction consists of user
input and system output. User input can be [4] an audio recording of a user,
touch tone, or more commonly voice recognition of a user's speech. Similarly,
system output can be text-to-speech or pre-recorded sound.
This section addresses various interaction styles, also known as dialog
strategies [2]. All these patterns feature a common set of forces:

• Dialogs have to to be ecient and short

• Dialogs have to be clear and structured

• Novices have to be guided. They need to know what kind of informa-

tion to provide

• Experienced users know what to say and need a fast way to enter the
data

4.1.1 Form Filling

Intent Gather information from the user.

Context The user has to provide data that can't be gathered through
a selection process. Forms are a well known concept of the real world to
provide information in a sequential order, one at a time.

Problem How to collect structured information from the user?

Forces
• Forms forces users to provide one datum at a time

• Natural language communication allows to provide more than one da-

tum at a time

• Speech is invisible: Users might forget what they entered in the begin-
ning

• Speech recognition performance: Users need feedback about the en-

tered data

B3-6
4.1 Dialog strategy 4 VUI DESIGN PATTERNS

Solution Identify a short description or label of the eld to be lled in

and prepare a variable to store the entered information. Use comprehensive
instructions for the label [15] using a consistent, brief, and clear terminology
with which the user is familiar. Prepare a grammar to retrieve the valid
values for the elds. Ensure that the label contains clues about the format
of the user's utterance. To ensure the correctness of the data, an own error
handler for each eld may be used.
Present the label to the user, followed with an optional input prompt
and silence to let the user enter the data. as if she were lling out a form.
Present a summary of all entered data to let the user conrm the data
or re-enter them.

Structure This is illustrated in the following gure. The user is requested

for an utterance in node Field 1. If she does not make an utterance within
a certain time, or made an erroneous input, she will be reprompted. If all
goes well, the dialog proceeds to the next eld until she reaches the node
Summary, where she is asked to conrm a summary of her inputs. If she
rejects the summary, the dialog proceeds with the rst eld for another try.
In an alternative approach, the user can be prompted to conrm each
eld separately.
[input] [input] [confirmed]
Field 1 Field 2 Summary

[timeout, error] [timeout, error]

[not confirmed]

Consequences
+ Dialogs are clear and structured

+ Good for beginners/novices

+ System messages are not to be confused

o System controls dialog ow

- Dialogs appear rigid and inexible

- Dialogs become lengthy

- Does not solve the problem to provide more data at a time

Known Uses The Poldi Gewinnspiel of the 1. FC Köln used Form Fill-
ing to request the desired information about the caller, like membership of
the 1. FC Köln and to enter the answers to the quiz. The application went
oine in 2005, but was callable at +49 (180) 5 29 00 29.

B3-7
4.1 Dialog strategy 4 VUI DESIGN PATTERNS

The dating line L.U.C.Y. from Com Vision uses Form Filling to request
the data of the caller, i.e. sex, age and ZIP code. Having entered all data,
the system summarizes all data in one go. The application can be called at
+49 (12) 345 662 662.
The Citiphone Banking application uses Form Filling to enter the
data, i.e. account number or bank code for a bank transfer. After the caller
entered a value for a eld, she is asked for conrmation. The application can
be called at +49 (180) 33 22 111.

Related patterns Form pattern [17] solves a similar problem for graph-
ical user interfaces.
Escalating Detail as a means of error recovery.
Mixed Initiative is an alternate approach and enables the user to pro-
vide more than one datum at a time.

Sample code In a car inspection scenario, the worker enters the data after
a car has been repaired. He enters his worker id, the order number and other
data that belongs to the order such as part numbers in a form before the
back-end system continues with the billing process.
Note: The VoiceXML <form> element must not be confused with the
form concept that is described in this pattern. <field> elements are just
one side of the elements which a <form> may contain.
<form i d=" p r e p a r e _ b i l l ">
< f i e l d name=" i d " type=" d i g i t s ">
<prompt>P l e a s e say your i d .</ prompt>
</ f i e l d>

< f i e l d name=" o r d e r " type=" d i g i t s ">

<prompt>P l e a s e say t h e o r d e r number</ prompt>
</ f i e l d>
...
<b l o c k>
<submit next=" h t t p : //www. example . com/ s e r v l e t / b i l l "
n a m e l i s t=" id , o r d e r , part_number " />
</ b l o c k>
</ form>

Also Known As Directed Dialog, System Initiative

4.1.2 Menu Hierarchy

Intent Guide the user to the information of interest

B3-8
4.1 Dialog strategy 4 VUI DESIGN PATTERNS

Context The user has to provide data that can be gathered through a
selection process. The options to be presented to the user are interrelated in
a hierarchy, or can be made to appear that way.

Problem How to guide the user to a certain piece of information?

Forces
• Hierarchical structures are easy to understand

• Not all options can be grouped in a hierarchical structure

• Long menus more ecient [16]

• Speech is one-dimensional: Long menus force the user to wait until the
wanted option is presented

• Speech is one-dimensional: The system's response time to present a

menu is very high

• Speech is invisible: Users cannot see the structure of the data

• Speech is transient: The user has to remember the path

Solution Form categories of similar option items to create a tree struc-

ture [13]. If this is not clearly solvable, the initial design can be improved
upon the user's feedback. Use a natural sequence of the items to determine
the presentation sequence [15]. In case there is no natural sequence, choose
an order that is obvious to the user, such as most frequently used items rst
or alphabetic sequence of terms. Present these options in a menu to the user.
Avoid listening to long prompts by using barge-in. Aid the user by naming
the appropriate commands in the prompt [20]. Enable the user to deviate
from prompted words by specifying alternative words in the the grammar or
use the touch tone key-pad. Conduct wizard-of-oz experiments to evaluate
the menu with respect to the wording of the prompts and the grammar.
Once, the user makes a selection, the system oers another menu until the
application settles on the one item or action the user wants. Remember the
user's path to allow for going up in the hierarchy.
The limitations of the short-term-memory has been studied by several
authors and is still discussed in the HCI eld. Some authors like Miller [12]
suggest that a person can only remember 7+/-2 information chunks. In an
ongoing project we conducted a user study were we found that more than 6
options are rejected by most users. Since the path must also be kept in
the memory, we assume, that this limit is also applicable for the depth of a
menu tree. Therefore, the length and the depth of such a menu tree should
be as at as possible, and should also not exceed the magical number 7.

B3-9
4.1 Dialog strategy 4 VUI DESIGN PATTERNS

Structure This is illustrated in the following gure. The user is requested

for a choice in node Option 1. Depending on her answer the dialog proceeds
with the appropriate next option until it reaches a leaf.
[option 2.1] [option 3.1]
Option 2.1 Option 3.1

[option 2.2] [option 3.2]

Option 1 Option 2.2 Option 3.2

[option 2.3] [option 3.3]

Option 2.3 Option 3.3

Consequences
+ Dialogs are clear and structured
+ Good for beginners/novices
+ The user is guided by the system and gets more details on demand
+ The user is able to control the leaves she wants to enter or leave
o System controls dialog ow
- Dialogs are too structured
- The lost-in-space problem increases when the number of options or the
depth of the hierarchy are too high
- Poorly chosen categories force the user to re-enter the menu to nd the
category that matches their reason for calling [16]

Known Uses The trac information InfoTrac from Viasuisse uses a

hierarchical structure to enter the route, in which the caller is interested.
Since Switzerland is multilingual, the application rst asks for the desired
language. It continues in the chosen language to enter the desired kind of
trac, like highways, train, etc. Having chosen i.e. highway the application
turns to Form Filling to enter the id of the highway. The application can
be called at +41 (900) 400 500.

Related patterns Typical applications use Form Filling and Menu

Hierarchy at dierent points, depending on the information and the user's
mental model [2].
Index or Scripted Interaction may be used to present the available
options.
Active Reference can be used to help the user stay oriented in the
hierarchy.
Hierarchical Set [17] solves a similar problem in visual oriented ap-
plications.

B3-10
4.1 Dialog strategy 4 VUI DESIGN PATTERNS

Sample code At the car inspection the worker browses for information
about a part that needs to be exchanged. The parts are sorted in a hierar-
chical structure. Having navigated to the exhaust system, she is been asked
for the sub-part in which she is interested.
<menu>
<prompt>
Say t h e p a r t o f t h e e x h a u s t system <enumerate />
</ prompt>
<c h o i c e next=" h t t p : //www. example . com/ p i p e . vxml">
Exhaust p i p e
</ c h o i c e>
<c h o i c e next=" h t t p : //www. example . com/ c o n v e r t e r . vxml">
Catalytic converter
</ c h o i c e>
<c h o i c e next=" h t t p : //www. example . com/ r e a r _ m u f f l e r . vxml">
Rear m u f f l e r
</ c h o i c e>
...
</menu>

4.1.3 Mixed Initiative

Intent Collect information from the user.

Context Users with a dierent level of experience have to enter some piece
of information that may have interdependencies. The dialog should imitate
a natural human-to-human conversation.

Problem How to collect information from the user seamlessly?

Forces
• Users want to enter data without too many restrictions

• It is possible to say the same thing in endless dierent ways.

• Combination of user data grows by a factorial order

• Grammars can cover only part of the ways to capture user input

• Speech is invisible: Users may not know what to say

Solution Start the conversation with an open ended prompt, i.e. How may
I help you?. Create a eld, also known as slot for each piece of information
to obtain from the user. Allow the user to provide more information than
the current question expects, i.e.

B3-11
4.1 Dialog strategy 4 VUI DESIGN PATTERNS

System: Where do you want to go?

User: I want to go to Darmstadt by train at 17:00.
Also allow lling or corrections of eld that are out of focus, i.e.
System: At what time do you want to go to Darmstadt?
User: No. I want to go to Mannheim.
Use references in the dialog context, i.e.
System: Bayern München lost 2:3
User: What is their current rank?
Use barge-in to enable the user to interrupt system prompts. If the
application's task can be divided into multiple sub-tasks, do not stick to the
principle of Say what you want at any time you want to described above.
This reduces the occurrence of the system's misbehaviour in the presence of
recognition failures.
Use suitable follow-up prompts, once the eld gets lled. Present the
collected information in a nal prompt and ask the user for conrmation.
Use Escalating Detail to aid the user in case of a timeout (the user did
not say anything) or in case of a reject (the utterance could not be mapped
to the grammar). Use Form Filling as the last escalation level. Conduct
wizard-of-oz experiments to evaluate the grammar.

Structure An example of a structure is shown in the following gure. The

user is requested to provide information for eld1 and eld2 after the initial
InputPrompt. If she provides information for eld1 she will be prompted for
eld2 in PromptField 2, whereas if she provides information for eld2 she
will be prompted for eld1 in PromptField 1. Having provided the missing
piece of information she will be asked to conrm the entered information in
ConrmAll. As an alternative she can provide information for both elds at
once and will be asked to conrm all in the next dialog step.
[filled=field1]
PromptField 1

[filled=field1,field2]
InputPrompt ConfirmAll

PromptField 2
[filled=field2]

Consequences
+ Dialogs are more natural

+ Users can provide more than one information item at once

B3-12
4.1 Dialog strategy 4 VUI DESIGN PATTERNS

+ Dialogs can become more ecient and shorter

+ Users can take control of the dialog ow

- Recognition rate decreases since the user is free to make any utterance

- User is fooled to think she is in a real free form entry, which will cause
her to use words that might not belong to the grammar

- Turn taking (When should or can the user speak?) and intention recog-
nition (What are the goals of the user?) come up as new problems [7]

Known Uses The cinema Cinecitta in Nuremberg oers a voice portal as

a cinema information. After calling the system gives a short overview about
its capabilities. The user is free to interrupt the system at any time. If the
user does not make an utterance or calls for help, the system falls back into
a Form Filling like dialog strategy, by asking rst for the hour and then
presents a list of lms that are shown at the given time. The user is free
to resume the initiative again at any time. The application can be called at
+49 (911) 20 66 67.

Related patterns Escalating Detail is used to aid the user to get

back on track.
If the user fails to enter the data, the dialog strategy may fall back into
Form Filling.
Persona might be used to make the dialog appear more natural.

Sample code In a car inspection scenario, the worker enters the data after
a car has been repaired. He enters his worker id, the order number and other
data, that belongs to the order, such as part numbers into the system before
the back-end system continues with the billing process. The worker can enter
all data at once or in a sequential order.
<form i d=" r e p a i r _ d o n e ">
<grammar s r c=" r e p a i r . grxml "
type=" a p p l i c a t i o n / s r g s+xml" />

< i n i t i a l name=" g e t _ i n f o ">

<prompt>Say t h e data f o r t h e b i l l</ prompt>
<c a t c h e v e n t=" nomatch ">
<prompt>
Let us t r y g e t t i n g each f i e l d s e p a r a t e l y .
</ prompt>
<reprompt />
<a s s i g n name=" g e t _ i n f o " expr=" t r u e " />
</ c a t c h>
</ i n i t i a l>

B3-13
4.2 Design of the system response 4 VUI DESIGN PATTERNS

< f i e l d name=" i d ">

<grammar s r c=" r e a p a i r . grxml#i d " />
<prompt>P l e a s e say your i d .</ prompt>
</ f i e l d>

< f i e l d name=" o r d e r ">

<grammar s r c=" r e p a i r . grxml#o r d e r " />
<prompt>P l e a s e say t h e o r d e r number</ prompt>
</ f i e l d>
...

<b l o c k>
<submit next=" h t t p : //www. example . com/ s e r v l e t / b i l l "
n a m e l i s t=" id , o r d e r , part_number " />
</ b l o c k>
</ form>

4.2 Design of the system response

Developing voice based applications with VoiceXML is straightforward. The
design of quality speech interfaces on the other hand, is a non-trivial task.
This section introduces some patterns that can help to design the system's
response to the user input.

4.2.1 Persona
Intent Dene a look & feel for voice based applications.

Context Users of voice based applications build their own mental image
of a personality or character that they infer from the application's voice and
language. Such mental image relates certain properties to the virtual dialog
partner, where systems responses should fall within a foreseeable range of
possibilities.

Problem How to realize a look & feel for voice based applications?

Forces
• Interests of the target groups are dierent

• Interaction with voice based application should provide an underlying

coherent and stable personality

• The system's responses must be consistent. New characters distract

the user.

B3-14
4.2 Design of the system response 4 VUI DESIGN PATTERNS

• Dialogs should appear more natural

• Users know that they are talking to a machine

• The character must match the user's mental image of the application

Solution Identify the audience and enumerate the benets to members of

the intended audience. Specify what impressions and feelings the application
should convey to the audience. Describe the ctional persona by writing a
short biography of her to get hints, how to phrase messages and prompts.
Dene the wording of each message and prompt so it conveys the persona's
message and personality. Compare several synthesized voices and select the
voice with the tone, accent and energy that matches the persona's. Deter-
mine the speed, tone and prosody of each prompt. Use markup languages
like SSML [19], to encode the voice characteristics or a voice actor emulating
the persona, when recording the messages and prompts. Assure congruence
of synthesized and prerecorded audio if both techniques are combined. In
addition, choose the appropriate non-verbal sounds, background music or
pauses to improve the clarity of prompts and messages. Make sure, that the
usage is consistent throughout the whole dialog.

Consequences
+ VUI anticipates the caller's needs

+ Callers of the target group are satised

+ Common look & feel for the application

- Callers outside the target group feel sidestepped

- Users are distracted if the the persona is chosen wrong

- Not applicable if the target group varies widely

Known Uses BERTI, the soccer information service from Sympalog uses
the ctive person BERTI to interact in a Mixed Initiative dialog with the
caller. The application can be called at +49 (9131) 61 00 17.
The Poldi Gewinnspiel of the 1. FC Köln used a very famous person to
create their Persona: Lukas Podolski. The application went oine in 2005,
but was callable at +49 (180) 5 29 00 29.

Related patterns Persona is often used as an extension to the chosen

dialog strategy, Form Filling, Menu Hierarchy, or Mixed Initiative,
to make the dialog appear more natural.

B3-15
4.2 Design of the system response 4 VUI DESIGN PATTERNS

Sample code In our car inspection scenario, the customer can call to get
information about the progress of the repair. He has to identify herself with
her customer id to retrieve the current repairs that are associated with this
customer.
The sample code provides an example, how SSML tags can be used to
use prosodic information within an application to control the TTS output.
This example can give only an idea about this pattern. The decision for a
persona is more or less a philosophical question, that has to be consistent
throughout the whole dialog.
< f i e l d name=" customer ">
<prompt>
Hi , my name i s B i l l . I can g i v e you some i n f o r m a t i o n
about t h e s t a t u s o f your c a r r e p a i r .<break />

P l e a s e say your
<emphasis l e v e l=" s t r o n g ">customer i d</ emphasis> t h a t
i s p r i n t e d on your copy o f t h e
<emphasis l e v e l=" s t r o n g ">o r d e r</ emphasis> .
</ prompt>
<grammar mode=" v o i c e " r o o t=" customer_id ">
...
</grammar>
</ f i e l d>

4.2.2 Structured audio

Intent Provide structural information in audio.

Context Graphical documents oer many possibilities to structure the

contents by means of headlines, dierent fonts and many other. This struc-
ture helps the user to stay oriented and allows for easy and fast access to
the desired information.

Problem How to provide information about document structure in audio?

Forces
• Structural information helps the user for easy and fast access to infor-
mation

• Visual content is a fundamental part of any document

• Structural meta information gets lost while reading the document

• Voice applications have no direct means to represent structural infor-

mation

B3-16
4.2 Design of the system response 4 VUI DESIGN PATTERNS

Solution Use sounds in form of auditory icons, earcons or background

sounds to represent the structure. As an alternative, dierent speakers may
also be used [9].

Structure The following gure shows an example, how an auditory icon

item.raw is used to introduce the distinct items, Item 1 and Item 2 read by
the TTS engine.

item.raw Item 1 item.raw Item 2

Consequences
+ Use of structural information in audio

+ Easier for the user to concentrate on the content

- A sound may have a dierent meanings to users

- Exhaustive use may distract user's attention

Known Uses The AHA framework [9] uses Structured Audio to render
structural information of web pages in audio.

Sample code At our car inspection scenario, the worker listens to a list
of repairs that have to be done. Each item is marked with an item sound to
indicate the list structure.
< f i e l d name=" d e t a i l C h o i c e ">
...
<prompt>
This c a r n e e d s t h e f o l l o w i n g r e p a i r s :
<mark name=" o i l C h a n g e " />
<a u d i o s r c=" item . raw"/> o i l change <break />
<mark name=" changeTyres " />
<a u d i o s r c=" item . raw"/> change t y r e s <break />
<mark name=" c h e c k N o i s e " />
<a u d i o s r c=" item . raw"/> check n o i s e from e x h a u s t
<break />
</ prompt>
...
</ f i e l d>

B3-17
4.3 Usability in Business Scenarios 4 VUI DESIGN PATTERNS

4.3 Usability in Business Scenarios

We present some of the most common usability issues in publicly available
voice applications. In particular, these problems and cardinal aspects that
we consider should be addressed in voice applications that are expected to
become a central part of the communication and information strategy of any
organization.

4.3.1 Language Selector

Intent Support language selection for users.

Context Voice applications usability is aected by a number of objective

factors such as speed, noise and attention. But also by other more sub-
jective, such as vocabulary, expressions, intonation and pronunciation. All
these factors introduce dierent degrees of complexity when accessing con-
tent through a voice interface. However, the language remains as the biggest
barrier.

Problem How to provide users with an eective language selection mech-

anism?

Forces
• Global companies and current increasing migration within multilingual
economic regions such as the EU or Mercosur force services to be oered
in multiple languages

• Users want to access a service in their native language

• Service has to be translated

• The default language of the company that oers the service is unknown
to users

• Recognition of multiple languages concurrently is not supported by all

recognizers

Solution Order the languages to be supported according to their impor-

tance in the host country or the area of the country. Use the list of ocial
languages of the country in case of doubt. Greet the caller in all languages
that are supported or in the language to be considered dominant. Ask the
user for the language to use in each language in the determined order. If the
recognizer does not support concurrent recognition of multiple languages, use
Scripted Interaction to ask simple Yes/No questions in each language

B3-18
4.3 Usability in Business Scenarios 4 VUI DESIGN PATTERNS

Structure This is illustrated in the following gure. After the Greeting,

the application prompts the option of interaction with the language L1 in
that language and the option for L2 in language L2. After the user has
chosen the language, the application continues with the selected language in
L1 Application or L2 Application.
[L1]
L1 Application

Greeting Language 1 Language 2

L2 Application
[L2]

Consequences
+ Allow users to easily recognize an option

+ Enable users with little foreign language skills access the system

- Listening options in many dierent languages can be confusing

- Problem of translating the application remains unsolved

Known Uses An example can be found in major airlines services such as

the United Airlines customer service: +49 (69) 50 07 03 87.
The trac information InfoTrac from Viasuisse asks the user in all
ocial languages of the Switzerland in the language to determine in which
language the user want to interact with the system. The application can be
called at +41 (900) 400 500.

Related patterns Scripted Interaction can be used to ask for the

language. Context-aware Call can be used to automatically suggest the
language from the caller's ID.

Sample code If the customer calls our international garage, if her car is
ready, the application asks for the language, sh wants to use.
<form i d=" l a n g u a g e ">
< f i e l d i d=" l a n g u a g e ">
<prompt>
Welcome t o t h e c a r i n s p e c t i o n .
<p xml:lang=" en ">Do you want t o u s e E n g l i s h ?</p>
<p xml:lang=" de ">
Moechten S i e Deutsch verwenden ?
</p>
<p xml:lang=" e s ">Desea a c c e d e r e s Espanol ?</p>
</ prompt>
<grammar s r c=" l a n g u a g e . grxml "

B3-19
4.3 Usability in Business Scenarios 4 VUI DESIGN PATTERNS

type=" a p p l i c a t i o n / s r g s+xml" />

< f i l l e d>
< i f cond=" l a n g u a g e =' e n g l i s h ' ">
<g o t o next=" en / c a r . vxml" />
< e l s e i f cond=" l a n g u a g e =' deutsch ' ">
<g o t o next=" de / c a r . vxml" />
< e l s e i f cond=" l a n g u a g e =' e s p a n o l ' ">
<g o t o next=" e s / c a r . vxml" />
</ i f>
<reprompt />
</ f i l l e d>
</ t r a n s f e r>
</ form>

4.3.2 Busy Waiting

Intent Provide a meaningful interaction to the users waiting to be at-
tended.

Context Personalized attention is a scarce resource. More and more, com-

panies are rapidly moving to provide their customers to centralized call-
centers with an increasing number of self-service functionality in order to
cope with the ever-growing demand. However, human intervention to re-
solve conicts cannot be totally replaced. In these scenarios, bottlenecks are
more likely to appear as human attention (operator) does not scale well but
only through the addition of more operators. As such, customers looking for
human attention often nd themselves waiting to be attended.

Problem How to transform the passive user wait in a phone line into a
more active, engaging experience (and keep them waiting!)?

Forces
• Waiting is avoided by customers
• Avoid users leaving the service (possibly in favor of a competitor)
• Minimize the time users spend waiting to be attended
• Physical limitations of the telephone system or used services to attend
more people at the same time
• The company wants to oer the service, but adding more operators is
costly
• Users expect a 24x7 service
• Not all call centers are available 24x7

B3-20
4.3 Usability in Business Scenarios 4 VUI DESIGN PATTERNS

Solution The solution needs to address the uncertainty of the waiting

status (Am I going to be attended? Will it take long? How many people
are already waiting? Why keep waiting?). There are number of information
that can be conveyed to the user to bring clarity and sense of the time spent
queued :
Clearly state if the service is available 24h or not. Mention the time-
zone, if the application covers an area over multiple time-zones. At regular
intervals of time provide some information.
This information can be one or a combination of the following modules.
This can vary, depending on the target group.

• Let the user know that the system is aware of the waiting, apologize
and reinforce the message that the user will be attended as soon as
possible.

• Provide information about how many people are on the queue (as a
subjective delay measure) or better, provide an estimate of the waiting
time

• Oer alternative ways to perform a request. For instance, oering the

user self service options or directing users to the customer website.

• Provide short advertisements about new services, products and last

minute oers.

• Play a smooth and calming music in the background. This can be com-
bined with brief corporate or branding messages and intervals where
only the music is heard.

Structure This is illustrated in the following gure. In Connect a caller

should be connected to a technician. During the transfer she hears music.
If the connection was successful, she gets transferred to the technician. If
a timeout occurs, she can be provided with some other information, i.e.
numbers of persons waiting, before she hears the music again.
[connected]
connect Transfer

[timeout]

Info

Consequences
+ Users become more satised because they know more.

+ Changes the waiting period into informative moments

B3-21
4.3 Usability in Business Scenarios 4 VUI DESIGN PATTERNS

- It doesn't solve the need of more operators

- Users might feel caught by the application if they get information in

which they are not interested

- Telephones usually have a lower sound quality than a radio. There-

fore, playing advertisements originally prepared and recorded for radio
emission may not be easy to follow and understand

Known Uses The customer service at T-Online informs the user upon
alternative request possibilities, if all technicians are busy. While the user
is in the waiting queue, she gets notied that she will be connected to a
technician as soon as possible from time to time. The application can be
called at +49 (180) 5 30 50 00.

Related patterns A Place To Wait [1] with the constraints of the

audio domain and a virtual environment

Sample code If the customer calls the garage, if her car is ready, she may
end up in a queue. Each 60 seconds, she will be informed about the number
of persons to be served rst.
<form i d=" x f e r ">
<t r a n s f e r name=" m y c a l l " d e s t=" t e l : +1 −555 −123 −4567"
t r a n s f e r a u d i o=" music . wav" c o n n e c t t i m e o u t=" 60 s "
b r i d g e=" t r u e ">
<prompt>
Say c a n c e l t o d i s c o n n e c t t h i s c a l l a t any time .
</ prompt>
<grammar s r c=" c a n c e l . grxml "
type=" a p p l i c a t i o n / s r g s+xml" />
< f i l l e d>
<o b j e c t name=" s i z e "
c l a s s i d=" method: /// queue . s i z e "
data=" h t t p : //www. example . com/ queue . j a r ">
</ o b j e c t>
<prompt>
There a r e o n l y <v a l u e expr=" s i z e " />
p e r s o n s t o s e r v e b e f o r e you .
</ prompt>
<reprompt />
</ f i l l e d>
</ t r a n s f e r>
</ form>
Note, that this example would not really work, since the caller would be
disconnected and enqueued again, if the connection timeout expires. The rea-
son is the limitation of the <transfer> element in VoiceXML. A workaround

B3-22
4.3 Usability in Business Scenarios 4 VUI DESIGN PATTERNS

for VoiceXML is to dynamically create the audio le music.wav and synthe-
size the announcements to this le. Proprietary implementations with a CTI
connection to the telephony system do not have this limitation.

4.3.3 Context-aware call

Intent Provide more meaningful interaction to the users.

Context Requesting services and goods over the phone is a common part
of our lives. These voice applications are continuously applied everyday into
the most diverse purposes. From appointments and accessing bank services
to ordering a pizza or a taxi, spoken requests are an every day activity.
A certain amount of context information is often required for any request
in order to be meaningful. In voice interfaces, such information must be
provided by the user.

Problem How to minimize the overhead of requesting information to per-

form a request?

Forces
• The process of conveying directions and specications of what is being
asked can be time consuming when the amount of information is large

• A request cannot be fullled unless all the required information is avail-

able

• When a service must be repeatedly requested, providing the same in-

formation is time consuming

• Users do not feel annoyed, if they do not use the service frequently

• Users need feedback about the information which the system already
has, and temporal orientation

• A low speech recognizer performance makes that data entry more error
prone

• Context information is not available for third parties yet

Solution Context information can help voice interaction systems be more

responsive and better adapt their response to the users. A common source
of context information in voice applications is brought for instance in each
phone call by the caller ID service. Use this information to determine actions
and default values for data that the user has to provide to use the service.

B3-23
4.3 Usability in Business Scenarios 4 VUI DESIGN PATTERNS

Structure This is illustrated in the following gure. If contextual infor-

mation ctx is available, it is obtained in GetContext. If ctx is not available,
the user has to enter it manually in Enter before the information can be
processed in Process.
[ctx=available]
GetContext

Process

Enter
[ctx!=available]

Consequences
+ Personalized service. The Information about who's calling and poten-
tial needs and preferences is already available
+ Less mistakes on the overall process of attending a request. Elimination
of repetitive data entry favors accuracy
+ More ecient interaction between the user and the operator. Substan-
tially more calls can be attended in the same amount of time
+ Other planning and logistic systems can be integrated and use the
contextual information to schedule service according to other criteria
such as logistics or customer rate
- Cannot be applied for services that requires authentication, since a
caller ID might not be enough to identify the caller for critical appli-
cations

Known Uses A very popular application is the Memobox implemented by

communication providers, which uses the user ID in order to automatically
enable the access to the private recorded messages. In this case, the telephone
(either xed or mobile) becomes an identication (not authentication) token.
Another example is the case of a taxi request system available in Ar-
gentina (+54 221 427 4500), which by default uses the caller ID information
to determine the address where a Taxi should pick up its passenger, unless
otherwise instructed. When the call is made from mobile phone, this fact is
reected to the operator who in that case asks the customer if the pick up
location is the same as last time or should be found somewhere else. The use
of context information helps the taxi company improve its eciency keeping
the average customer call very short (8-12 secs), just enough to acknowledge
the existing address is correct and conrm the request.
The Israeli Electric company has started printing a Contract Number
eld on the electricity bills as a single handle that is typed when calling
their VUI system. This handle replaces a whole group of numeric entry
elds that were required to bill with a credit card.

B3-24
 5 SUMMARY

Related patterns In Form filling, context-aware call can help with

automated lling of elds with known information about the caller.

Sample code In a car inspection scenario, the worker has to get a list of
which repairs have to be done for the next car. This information can be
entered manually by reading the license plate to the system or by a location
system, that automatically detects that the worker is standing near to a
certain car.
<form i d=" g e t _ o r d e r ">
<o b j e c t name=" l o c a t i o n "
c l a s s i d=" method: // L o c a t o r / l o c a t e "
data=" h t t p : //www. example . com/ l o c a t i o n . j a r ">
<param name=" worker " expr=" i d " />
</ o b j e c t>

<b l o c k>
< i f cond=" l o c a t i o n ">
<submit next=" h t t p : //www. example . com/ r e a d . j s p "
n a m e l i s t=" l o c a t i o n " />
</ i f>
</ b l o c k>

< f i e l d name=" e n t e r _ l o c a t i o n ">

<grammar s r c=" o r d e r . grxml "
type=" a p p l i c a t i o n / s r g s+xml" />
<prompt>P l e a s e r e a d t h e l i c e n s e p l a t e</ prompt>
...
< f i l l e d>
<submit next=" h t t p : //www. example . com/ r e a d . j s p "
n a m e l i s t=" e n t e r _ l o c a t i o n " />
</ f i l l e d>
</ f i e l d>
...

</ form>

5 Summary
We have presented in this paper 8 new patterns in the area of Voice User
Interfaces (VUI). Several known guidelines for VUI design are covered. The
design for VUI applications has its roots in the one-dimensional, transient
and invisible nature of the audio medium, enhanced by technical limitations,
such as speech synthesis quality and speech recognition performance. These
three factors introduce a particular set of problems and requirements to the
application that must be addressed, and that we have documented in this
paper.

B3-25
REFERENCES REFERENCES

The design patterns we presented in this work aim to help the designer
of a VUI understand the nature of the problems, and successfully analyse
and solve these issues to provide a successful voice interface.
The new patterns consistently build on the previously mined VUI pat-
terns and show non-trivial design decisions in three dierent aspects of VUI
applications such as Dialog Strategy, System Response and Usage Scenarios.
Form Filling, Menu Hierarchy and Mixed Initiative are the fun-
damental decision of the dialog strategy that the designer follows in her
application.
Persona and Structured Audio help to design the system response.
Busy Waiting, Language Selector, and Context Aware Call
are some common usability issues in business scenarios.
These patterns are the continuation of a new pattern language, intro-
duced in [14]. We hope to continue growing it with the help of the VUI
community.

Acknowledgments
Thanks a lot to Amir Raveh who shepherded this paper for EuroPLoP 2006.
His comments were very useful and helped to develop this paper.We would
also thank Jussi Kangasharju for reviewing the paper and Jürgen Haas for
his comments from the developer's perspective.

References
[1] C. Alexander, S. Ishikawa, and M. Silverstein. A Pattern Language:
Towns, Buildings, Constructions. Oxford University Press, UK, 1977.

[2] Michael H. Cohen, James P. Giangola, and Jennifer Balogh. Voice User
Interface Design. Addison-Wesley, Boston, January 2004.

[3] Andy Dearden and Janet Finlay. Pattern Languages in HCI; A Critical
Review. Human-Computer Interaction, 21, 2006.

[4] Bryan Duggan. Revenue Opportunities in the Voice Enabled Web.

Technical report, School of Computing, Dublin Institute of Technology,
Kevin St. Dublin 8, Ireland, 2002.

[5] James A. Larson et. al. Ten Guidelines for Designing a Successful Voice
User Interface. Speech Technology Magazine, January 2005.

[6] Norman M. Frazer and G. Nigel Gilber. Simulating speech systems.

In Computer Speech and Language, volume 5. Academic Press Limited,
1991.

B3-26
View publication stats

REFERENCES REFERENCES

[7] Marti A. Hearst. Mixed-initiative interaction. IEEE Intelligent Systems,

pages 1416, September 1999.

[8] Speech Science Institute. Guidelines for Developing Voice User In-
terfaces. http://www.ssi-interactive.com/vui_guidelines1.htm,
2004.

[9] Frankie James. Representing Structured Information In Audio In-

terfaces: A Framework For Selecting Audio Marking Techniques To
Present Document Structures. PhD thesis, Stanford University, 1998.

[10] Jean-Claude Junqua. Robust Speech Recognition in Embedded System

and PC Applications. Kluwer Academic Publishers, Norwell, MA, USA,
2000.

[11] SUN Microsystems. Java Speech API Programmer's Guide. SUN Mi-
crosystems, 1998.

[12] George A. Miller. The magical number seven, plus or minus two: Some
limtis on our capacity for processing information. Psycological Review,
63:8197, 1956.

[13] Kent Norman. The Psychology of Menu Selection: Designing Cognitive

Control at the Human/Computer Interface. Ablex, Norwood, NJ, 1991.

[14] Dirk Schnelle, Fernando Lyardet, and Tao Wei. Audio Navigation Pat-
terns. In EuroPLoP 2005 Conference Proceedings, 2005.

[15] Ben Shneiderman. Designing the User Interface: Strategies for Eec-
tive Human-Computer Interaction. Addison-Wesley Longman Publish-
ing Co., Inc., Boston, MA, USA, 1986.

[16] Bernhard Suhm, Barbara Freeman, and David Getty. Curing the Menu
Blues in Touch-tone Voice Interfaces. In CHI '01: CHI '01 extended
abstracts on Human factors in computing systems, pages 131132, New
York, NY, USA, 2001. ACM Press.

[17] Jenifer Tidwell. Designing Interfaces. O'Reilly, 2005.

[18] VoiceXML. http://www.w3.org/TR/voicexml21/.

[19] W3C. Speech Synthesis Markup Language (SSML) Version 1.0. http:
//www.w3.org/TR/speech-synthesis/, September 2004.
[20] Nicole Yankelovich. How Do Users Know What to Say? ACM interac-
tions, 3(6), November 1996.

B3-27