Good examples of IVR, (Interactive voice response), Interaction Design Standards

16 Mar 2007 - 11:35am
7 years ago
19 replies
10384 reads
jrrogan
2005

I'm working on an IVR project and was wondering what were the best
Interaction Standards/ Guidelines which IxD'ers have used, to create
successful IVR solutions.

The IVR project I'm working on comprises many functions for multiple roles,
and is supposed follow standards and be very simple, forgiving and easy to
use, all with touch pad technology.

Others IVR project experience would be interesting to hear, no pun intended
;)

Thanks,

Rich

Comments

16 Mar 2007 - 12:11pm
Phillip Hunter
2006

Rich,

I've done that for a while. There aren't many really solid standards out
there, especially for a DTMF interface. I can give you specific pointers
off-list, but would need a better understanding of the purpose first.

Generally, I can tell you that many of the most widely agreed upon steps of
the design lifecycle will do you good as a foundation:
- really identify and analyze the business purpose and the intended audience
- find and analyze similar systems
- lay out and analyze task step sequences
- prototype multiple designs
- test early and often

There are some IVR-specific best practices for words to use, keys to line up
with, number of options presented at a time, etc. Again, I can help you
with that off-list

ph

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Rich
Rogan
Sent: Friday, March 16, 2007 12:35 PM
To: IXDA list
Subject: [IxDA Discuss] Good examples of IVR, (Interactive voice
response),Interaction Design Standards

I'm working on an IVR project and was wondering what were the best
Interaction Standards/ Guidelines which IxD'ers have used, to create
successful IVR solutions.

The IVR project I'm working on comprises many functions for multiple roles,
and is supposed follow standards and be very simple, forgiving and easy to
use, all with touch pad technology.

Others IVR project experience would be interesting to hear, no pun intended
;)

Thanks,

Rich
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

16 Mar 2007 - 12:28pm
Ari
2006

i worked with IVR systems at a past job and now that i'm moving back into
the product world, will be inheriting one.

i'd also add to phillip's list:

- make sure the options are clearly laid out (obvious but not always
followed)
- make sure that the voice talent used by the IVR system speaks clearly
- make sure that the voice talent is suited to your core audience - e.g.
male vs. female or variance in voice talent age can all have a psychological
impact on user responses to the system. users will have biases so you want
to choose the right voice for the task - e.g. reassuring voice for support,
friendly voice for customer service functions, etc.
- make sure you trap all conditions and give your users a graceful way out
of 'voice mail' hell

just my .002 cents.

On 3/16/07, Phillip Hunter <phillip at speechcycle.com> wrote:
>
> Rich,
>
> I've done that for a while. There aren't many really solid standards out
> there, especially for a DTMF interface. I can give you specific pointers
> off-list, but would need a better understanding of the purpose first.
>
> Generally, I can tell you that many of the most widely agreed upon steps
> of
> the design lifecycle will do you good as a foundation:
> - really identify and analyze the business purpose and the intended
> audience
> - find and analyze similar systems
> - lay out and analyze task step sequences
> - prototype multiple designs
> - test early and often
>
> There are some IVR-specific best practices for words to use, keys to line
> up
> with, number of options presented at a time, etc. Again, I can help you
> with that off-list
>
> ph
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Rich
> Rogan
> Sent: Friday, March 16, 2007 12:35 PM
> To: IXDA list
> Subject: [IxDA Discuss] Good examples of IVR, (Interactive voice
> response),Interaction Design Standards
>
> I'm working on an IVR project and was wondering what were the best
> Interaction Standards/ Guidelines which IxD'ers have used, to create
> successful IVR solutions.
>
> The IVR project I'm working on comprises many functions for multiple
> roles,
> and is supposed follow standards and be very simple, forgiving and easy to
> use, all with touch pad technology.
>
> Others IVR project experience would be interesting to hear, no pun
> intended
> ;)
>
> Thanks,
>
> Rich
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
----------------------------------------------------------------
http://www.flyingyogi.com

16 Mar 2007 - 12:52pm
Phillip Hunter
2006

Rich,

Those things and more are what I was going to get into off list. Definitely
important and I can expand them a bit more. Let me know.

ph

_____

From: Ari Feldman [mailto:ari1970 at gmail.com]
Sent: Friday, March 16, 2007 1:29 PM
To: phillip at speechcycle.com
Cc: Rich Rogan; IXDA list
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

i worked with IVR systems at a past job and now that i'm moving back into
the product world, will be inheriting one.

i'd also add to phillip's list:

- make sure the options are clearly laid out (obvious but not always
followed)
- make sure that the voice talent used by the IVR system speaks clearly
- make sure that the voice talent is suited to your core audience - e.g.
male vs. female or variance in voice talent age can all have a psychological
impact on user responses to the system. users will have biases so you want
to choose the right voice for the task - e.g. reassuring voice for support,
friendly voice for customer service functions, etc.
- make sure you trap all conditions and give your users a graceful way out
of 'voice mail' hell

just my .002 cents.

On 3/16/07, Phillip Hunter <phillip at speechcycle.com> wrote:

Rich,

I've done that for a while. There aren't many really solid standards out
there, especially for a DTMF interface. I can give you specific pointers
off-list, but would need a better understanding of the purpose first.

Generally, I can tell you that many of the most widely agreed upon steps of
the design lifecycle will do you good as a foundation:
- really identify and analyze the business purpose and the intended audience

- find and analyze similar systems
- lay out and analyze task step sequences
- prototype multiple designs
- test early and often

There are some IVR-specific best practices for words to use, keys to line up

with, number of options presented at a time, etc. Again, I can help you
with that off-list

ph

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Rich
Rogan
Sent: Friday, March 16, 2007 12:35 PM
To: IXDA list
Subject: [IxDA Discuss] Good examples of IVR, (Interactive voice
response),Interaction Design Standards

I'm working on an IVR project and was wondering what were the best
Interaction Standards/ Guidelines which IxD'ers have used, to create
successful IVR solutions.

The IVR project I'm working on comprises many functions for multiple roles,
and is supposed follow standards and be very simple, forgiving and easy to
use, all with touch pad technology.

Others IVR project experience would be interesting to hear, no pun intended
;)

Thanks,

Rich
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

--
----------------------------------------------------------------
http://www.flyingyogi.com

16 Mar 2007 - 8:22pm
dszuc
2005

Hi Rich:

Some starter references:

* AS/NZS 4263:2003 : Interactive voice response systems - User-interface -
Dual tone multi frequency (DTMF) signaling. Standards Australia-
http://www.standards.com.au/catalogue/script/Details.asp?DocN=AS207098790467

Next 2 more for voice but some cross over principles:

* Voice Interaction Evaluation Checklist - http://tinyurl.com/ysqwdk

* Point, Counterpoint: What Three Experts Have to Say about Speech Usability
- http://tinyurl.com/28fjko

Rgds,

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

The Usability Toolkit - http://www.sitepoint.com/books/usability1/

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Rich
Rogan
Sent: Saturday, March 17, 2007 12:35 AM
To: IXDA list
Subject: [IxDA Discuss] Good examples of IVR, (Interactive voice
response),Interaction Design Standards

I'm working on an IVR project and was wondering what were the best
Interaction Standards/ Guidelines which IxD'ers have used, to create
successful IVR solutions.

The IVR project I'm working on comprises many functions for multiple roles,
and is supposed follow standards and be very simple, forgiving and easy to
use, all with touch pad technology.

Others IVR project experience would be interesting to hear, no pun intended
;)

Thanks,

Rich ________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/ (Un)Subscription
Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

19 Mar 2007 - 10:00am
DrWex
2006

I would agree with Ari's suggestions and add one more. In my
observations of tests on IVR, one of the most frequent complaints was
related to the time of performance. That is, people perceive IVRs as
being slow and resent having to wait for the system to stop speaking.

Therefore, if at all possible, have the system able to accept input as
fast as the person can provide it, including aborting prompts when the
person presses a key. Also, remove extraneous puffery. The phrase
"Your call is very important to us" seemed a particularly good way to
infuriate people, including one memorable test user who snarled "If my
call is so *bleeping* important why don't you hire a human to talk to
me?"

Best,
--Alan

On 3/16/07, Ari Feldman <ari1970 at gmail.com> wrote:
> i worked with IVR systems at a past job and now that i'm moving back into
> the product world, will be inheriting one.
>
> i'd also add to phillip's list:
>
> - make sure the options are clearly laid out (obvious but not always
> followed)
> - make sure that the voice talent used by the IVR system speaks clearly
> - make sure that the voice talent is suited to your core audience - e.g.
> male vs. female or variance in voice talent age can all have a psychological
> impact on user responses to the system. users will have biases so you want
> to choose the right voice for the task - e.g. reassuring voice for support,
> friendly voice for customer service functions, etc.
> - make sure you trap all conditions and give your users a graceful way out
> of 'voice mail' hell
>
> just my .002 cents.
>
> On 3/16/07, Phillip Hunter <phillip at speechcycle.com> wrote:
> >
> > Rich,
> >
> > I've done that for a while. There aren't many really solid standards out
> > there, especially for a DTMF interface. I can give you specific pointers
> > off-list, but would need a better understanding of the purpose first.
> >
> > Generally, I can tell you that many of the most widely agreed upon steps
> > of
> > the design lifecycle will do you good as a foundation:
> > - really identify and analyze the business purpose and the intended
> > audience
> > - find and analyze similar systems
> > - lay out and analyze task step sequences
> > - prototype multiple designs
> > - test early and often
> >
> > There are some IVR-specific best practices for words to use, keys to line
> > up
> > with, number of options presented at a time, etc. Again, I can help you
> > with that off-list
> >
> > ph
> >
> > -----Original Message-----
> > From: discuss-bounces at lists.interactiondesigners.com
> > [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Rich
> > Rogan
> > Sent: Friday, March 16, 2007 12:35 PM
> > To: IXDA list
> > Subject: [IxDA Discuss] Good examples of IVR, (Interactive voice
> > response),Interaction Design Standards
> >
> > I'm working on an IVR project and was wondering what were the best
> > Interaction Standards/ Guidelines which IxD'ers have used, to create
> > successful IVR solutions.
> >
> > The IVR project I'm working on comprises many functions for multiple
> > roles,
> > and is supposed follow standards and be very simple, forgiving and easy to
> > use, all with touch pad technology.
> >
> > Others IVR project experience would be interesting to hear, no pun
> > intended
> > ;)
> >
> > Thanks,
> >
> > Rich
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
>
>
>
> --
> ----------------------------------------------------------------
> http://www.flyingyogi.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
--Alan Wexelblat

19 Mar 2007 - 10:29am
Phillip Hunter
2006

Egads, yes. By all means use a state-of-the-art IVR platform that can
accept input at anytime.

And of course make every word meaningful. Which is not to say terse or
cold. But nothing extraneous or insincere and avoid redundancy when it's
not needed.

Also, Ari mentioned the voice talent. Stay away from talents who are 1)
robotic, 2) announcer-ish, or 3) amateurs. And I highly recommend picking
2-4 voices you think would work, then presenting them to the powers that be
for their selection. Do not send them a list of many talents and let them
choose. Talent selection is a design decision.

ph

-----Original Message-----
From: Alan Wexelblat [mailto:awexelblat at gmail.com]
Sent: Monday, March 19, 2007 11:00 AM
To: Ari Feldman
Cc: phillip at speechcycle.com; IXDA list
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

I would agree with Ari's suggestions and add one more. In my
observations of tests on IVR, one of the most frequent complaints was
related to the time of performance. That is, people perceive IVRs as
being slow and resent having to wait for the system to stop speaking.

Therefore, if at all possible, have the system able to accept input as
fast as the person can provide it, including aborting prompts when the
person presses a key. Also, remove extraneous puffery. The phrase
"Your call is very important to us" seemed a particularly good way to
infuriate people, including one memorable test user who snarled "If my
call is so *bleeping* important why don't you hire a human to talk to
me?"

Best,
--Alan

19 Mar 2007 - 4:34pm
jrrogan
2005

Thanks to all,

Definitely this is a great help! For anyone interested in excerpts from some
of the resources send in these posts, I've created a short summary of
findings below:

IVR Best Practices and References:

________________________________________

Australian/NZ Standard for Interactive Voice response systems:

http://www.saiglobal.com/shop/script/Details.asp?DocN=AS207098790467

THE ISO VOICE MESSAGING STANDARDS:

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=22721&scopelist=ALL

________________________________________

IVR Best Practices:

Using a one-piece phone, where the keypad is integral with the headset,
makes it difficult for the user to simultaneously listen and press keys.
Therefore, adequate time needs to be given for the user to respond. Also,
the user should be able to request a repeat of the voice prompts.

Recommendations
Allow for users who need extra time to respond to prompts.
Provide a means of access to a human operator.
Provide a recovery route from error.
Provide different audio feedback for valid and invalid key presses.
Provide a consistent and predictable user interface.
Use consistent terminology.
Keep user IDs to no more than 8 digits.
Do not require that the same information is entered more than once.
Provide users with the facility to repeat the audio output.
Provide context-sensitive help.

_______________________________________________

Building User-Friendly Voice Systems, (exerpts from)
Author: Tim Noonan B.A. <tnoonan at softspeak.com.au>

TERMINOLOGY
Because the IVR industry is relatively new, the accepted terminology in use
is not always consistent. The Australian and New Zealand Interactive Voice
Response Standard assists to some extent here, however the following terms
will be defined since they are frequently used in this paper.

SYSTEM - An interactive voice application
APPLICATION - Any IVR system;
IVR - Interactive Voice Response;
INTERACTIVE VOICE RESPONSE - Any telephone-based application which
interactively takes input from callers and returns output in the form of
voice or auditory information;
CALLER - A caller to the system (often termed a user in computing contexts);

"VOICE" - the digitally recorded human voice used by the system to convey
messages and information to callers of the system;
ANNOUNCER - the person who records system messages into the system - the
human behind the system's "voice".

INTRODUCTION
The intent of this paper is to present human factors principles applicable
to IVR application design which can result in more intuitive, efficient and
pleasant telephonic interactions for your IVR customers.

The recently released updated Australian Standard (AS/NZS 4263) on the user
interface design of Interactive Voice Response (IVR) systems is a solid
basis for developing your applications.

Designing an IVR system which is easy and intuitive to use relies much more
on common sense than clever programming

Since IVR systems are developed to serve their callers, they need to be
optimized to human ways of thinking and responding. The best IVR systems are
sculptured to fit their users; in the long-run this extra effort is far
easier, affordable and successful than trying to mould your callers to a
cumbersome user interface.

DIFFERENCES BETWEEN AUDITORY AND VISUAL APPLICATIONS

A computer screen is two-dimensional. The user is able to look at any part
of the information displayed on the screen at will. Highlighting, fonts and
location convey structure and relative importance to different elements of
material on the screen. In contrast, an auditory interface is serial, rather
than two-dimensional. Only one word can be heard at a time, and the order in
which material is delivered is therefore very significant.

The following guidelines illustrate some of these differences:

1. Always announce the function, and then the key required to activate it.
This is almost universal in IVR systems and avoids confusion;
2. The most important or the most commonly selected items in a menu should
be presented first in a list, so that the caller does not need to listen for
too long, in order to find his/her desired choice;
3. Messages need to be kept short, and should include some prominent key
words. (verbal emphasis of key words replaces highlighting on a computer
screen);
4. Restrict the maximum number of specific items in a menu to between three
and five wherever possible. (Since the caller cannot just glance back to
review choices, this is all that can be held in the short-term memory of
most callers);
5. Use silence to convey structure to your callers. Short pauses between
menu items, slightly longer pauses between menus. Avoid long silences, as
these convey no useful information to callers and can lead to user concern;
6. Use careful wording, tone of voice, audible tones and logical sequencing
of information in order to convey context, errors, menu structure and the
relative importance of presented information. Prompt for spoken input with a
brief tone, use upward inflections for questions and the like. (In a
screen-based application, layout, colour and highlighting serve this role);
7. Use terms and metaphors which relate to the telephone and spoken
communications. (Remember that many IVR callers may not have ever used a
computer, so you should not assume a knowledge of computing concepts and
terms);
8. Confirm choices verbally so the person is confident about what is
happening and where they are being taken in the application. (Unlike a
computer application where status lines and layered windows remind the user
of their location in the application, the IVR system needs to convey this
information actively to a caller);
9. Avoid using two-dimensional data structures such as tables and
two-dimensional cursor movement through information. That is, avoid the
arrow-key metaphors. Instead, structure your information into items or
records that can be heard one-at-a-time. Allow the caller to move back to
the previous item, to hear the current item again, or skip to the next item
in the list. You might provide a shortened version of the item, and nominate
a key for further information on that item.
10. Your system should be self-documenting through well scripted prompts and
on-line help. Callers might not have a manual with them for the system, or
they may be doing something (such as driving) which means they cannot refer
to printed documentation. Because preparing help material can be tedious,
this also encourages designers to make the system more intuitive and less
complex. By keeping to the guidelines just listed, - your help scripts will
be more straight-forward.

Designing a system which is not reliant on printed information also means
that your system is fully useable by people who are unable to read print
including people who are blind, or those with other print disabilities. In
addition, many people from a non English-speaking background may be able to
speak and understand English, but may be unable to read English comfortably.

LEARNING ABOUT YOUR CUSTOMERS BEFORE YOU BEGIN

In the same way that a good public speaker finds out about her or his
audience before making a presentation, a good IVR designer needs to know
about her or his callers before designing an IVR system.

The user interface of your system needs to cater well for the majority of
your callers while still being useable by all callers.

It is sometimes possible to develop a simple prototype system without all
the functionality of the final product. You can then bring in some sample
callers to give it a try.

If you have a large number of callers (many at different levels of ability)
then having different prompting levels may also be desirable. Novices may
not be offered all choices while advanced callers should be allowed to move
about a relatively complex menu structure rapidly with very brief prompts.
Always allow users to make selections without having to listen to all
messages. This allows experienced users to move through the system quickly
and saves you resources.

IVR systems usually need to be relatively simple in design if there are a
large number of diverse callers. The best place to start when scoping the
features and complexity of the IVR service is by identifying those
information requests which are simple, but which take up a large percentage
of your staff resources.

Quite complex systems can be developed if your caller group is clearly
targeted and you can make assumptions about their abilities. Be careful
here, though, as there may be pressure at a later date to make the system
available to a wider range of callers.

CUSTOMER SUPPORT AND HUMAN FACTORS SPECIALISTS SHOULD BE PART OF YOUR TEAM

Developing IVR applications is much more about understanding your customers,
your business and the way callers use telephones than it is about
programming computers.

THE AUSTRALIAN AND NEW ZEALAND INTERACTIVE VOICE RESPONSE STANDARD

It is possible for your system to comply to the latest revision of the
Australian and New Zealand Standard (AS/NZS 4263) and still retain a unique
identity which clearly differentiates it from other products on the market.

WRITING SUPERIOR SCRIPTS

Good scripts are brief and clear.

Entering your script and structure into a flow charting program often shows
up uneven distribution of system functions across branches of the menu
structure. A balanced menu structure is easier for you and callers to
understand and memorise.

There should be a person (preferably not one of the programmers or systems
analysts) who is primarily responsible for writing the script for the
system. Once this person has written wordings for all the messages in the
system, it is often useful for them to work with one or two others to
fine-tune difficult or uncomfortable wording.

The only way to get the wordings in scripts "just right" is to read and
re-read the wording of the script as you write it and get people to speak
phrases to you so you can hear what they sound like. Ask colleagues in the
IVR industry, as well as people with no IVR experience, to give you feedback
on the script. It is not unusual to spend half an hour or more to get the
wording for a tricky menu choice just right; but it is well worth it in the
long-run.

There are often a few small changes in wording required during the recording
stage, but these should be minimal. If something in the script just does not
sound quite right to you, then the chances are that it won't sound right to
your callers either. Remember that they will have to listen to the grating
wording again and again each time they call the system.

The caller's first interaction with the system is critical. Welcome the
caller and put him or her at ease through clear uncomplicated instructions.
The wording should not be too familiar at this point, and should convey a
clear message to callers that they are interacting with a computer and not a
human. Try to pre-empt every conceivable thing a caller could do when first
connecting to your system and be as supportive as possible. Remember that
any call to your system could be from a caller using an IVR system for the
very first time.

A few things to keep in mind when scripting include:

1. Keep messages brief and to the point, but avoid terseness
2. Terminology must be used in a consistent manner throughout the whole
system. Always use the preferred terminology included in the Standard. E.g.
Press for single key input, Enter for field input and so on.
3. Tell users early how to navigate around the system and how to get help,
and ensure that navigation keys and help are available at all points in the
system.
4. When a caller enters incorrect or unexpected responses, politely tell
them this and provide more information about what is required by the system.

5. The system should always tell the caller if they are being transferred to
an operator, and in most cases they should be given the choice of whether
they want to talk to a human or not. Experience has shown that half the
callers to an IVR system at one site hung up when a human answered during
system down time. 6. Clearly, once accustomed to the system, these callers
wanted to interact with a machine rather than a human for these financial
transactions.

SHAPING YOUR SYSTEM'S IDENTITY
If your system is to stand out from the pack, then it needs to have an
identity of its own. Your callers need to enjoy interacting with it and
should feel comfortable moving around within it. The "voice" your system
uses is the most influential aspect of the system, so you should take the
time to get it just right. The "voice" can make or break a system as well as
directly affecting the mood of your callers, and possibly their attitude
toward your products and company.

To begin with, you need to decide whether you want your system to have a
male or female "voice". Who will your callers be? Which would they relate to
best? Either way select people with strong clear voices that are not
high-pitched. Experience on radio has demonstrated that people prefer voices
which are not too deep or too high. The telephone system is optimised for
average pitched voices, cutting off highs and lows from the signal. In
contrast to radio (which is still very male-dominated) many IVR systems now
use contralto female announcers, possibly because female voices are often
perceived to be more helpful and less authoritarian.

If your system includes a combination of synthetic speech and recorded
speech, then a male voice will probably blend in better, since most of the
better synthetic speech currently available is male, because the vocal
characteristics of the male voice are less complex and therefore easier to
synthesise.

How warm, friendly or relaxed sounding you want your system to be is the
next decision. There is nothing worse than calling an IVR system where the
"voice" is dull or bored sounding! The announcer needs to have some life and
tonality in her or his voice. Tone and expression are the cues to your
callers of what is expected of them, where they are in the system and how
they are going. If you want your users to move through the system promptly,
then you should select an announcer who speaks confidently rather than an
announcer who is too friendly and relaxed.

Give thought to an appropriate balance of friendliness and efficiency in the
system's "voice". You want your system to be welcoming and supportive, but
you also need to ensure that the caller immediately knows they are
interacting with a computer and not a human. You don't want your callers to
have unrealistic expectations of the system, but you also don't want to
alienate them with a cold unfriendly voice.

The human voice is a very powerful tool. Your system's "voice" should be
able to encourage callers when they get lost in the system or when they are
not responding quickly enough. Tone and wording need to help a caller who
has made an error remedy the situation without appearing to chastise or to
punish the caller, and without discouraging them from using the system.

EXPANDING AN EXISTING IVR SYSTEM

During initial system planning you should give as much thought as possible
to potential future expansion. The types of menus, the way that you number
choices and the terminology you use will all give you less or more potential
to add in new modules at a later date. If you need to totally redesign the
system when making extensions to it, you will definitely alienate many
existing callers even if you add a lot more functionality in the process.
Your investment in training and documentation will be incorrect and callers
will make more errors as they try using the system in the old ways.

19 Mar 2007 - 3:21pm
psachs2 at aol.com
2007

Just adding a few notes to Philip's great suggestions:

The interrupt feature should be used, but carefully controlled. There are times you want a caller to hear the interface's instructions completely. Each page of the IVR (i.e., each interaction) should be separately considered and assigned appropriate properties, including interupt.

The script should indeed avoid unnecessary words, or a robotic feeling.. It's hard sometimes to convey meaning quickly with words. Long ago, I developed a vocabulary of sounds that help speed up the interface. Sort of like widgets on a GUI. You might not need tones, but there should be some way to compensate for the uni-dimensional quality of telephone systems. Also, whether a VUI sounds 'robotic' can have a lot to do with how the tech people handle the IVR. A good techie can even make synthesized speech sound warm and friendly.

I agree with the good advice Phillip gave about selecting voice talent. I would add that it's often a plus to have the client present for the actual recording, to be sure the pronunciations, inflections, speed, etc are exactly as the client envisioned.

I am new to this list. Great to have voice matters discussed here.

Pat

-----Original Message-----
From: phillip at speechcycle.com
To: discuss at ixda.org
Sent: Mon, 19 Mar 2007 11:29 AM
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice response), Interaction Design Standards

Egads, yes. By all means use a state-of-the-art IVR platform that can
accept input at anytime.

And of course make every word meaningful. Which is not to say terse or
cold. But nothing extraneous or insincere and avoid redundancy when it's
not needed.

Also, Ari mentioned the voice talent. Stay away from talents who are 1)
robotic, 2) announcer-ish, or 3) amateurs. And I highly recommend picking
2-4 voices you think would work, then presenting them to the powers that be
for their selection. Do not send them a list of many talents and let them
choose. Talent selection is a design decision.

ph

-----Original Message-----
From: Alan Wexelblat [mailto:awexelblat at gmail.com]
Sent: Monday, March 19, 2007 11:00 AM
To: Ari Feldman
Cc: phillip at speechcycle.com; IXDA list
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

I would agree with Ari's suggestions and add one more. In my
observations of tests on IVR, one of the most frequent complaints was
related to the time of performance. That is, people perceive IVRs as
being slow and resent having to wait for the system to stop speaking.

Therefore, if at all possible, have the system able to accept input as
fast as the person can provide it, including aborting prompts when the
person presses a key. Also, remove extraneous puffery. The phrase
"Your call is very important to us" seemed a particularly good way to
infuriate people, including one memorable test user who snarled "If my
call is so *bleeping* important why don't you hire a human to talk to
me?"

Best,
--Alan

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org
________________________________________________________________________
AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.

20 Mar 2007 - 7:42am
Phillip Hunter
2006

Pat,

Welcome! Not that I want to be disagreeable with your first post, but
actually in my experience clients know very little about proper prompt
delivery. My design teams have been responsible for knowing how language is
to be conveyed, whether written or spoken. Also, I can in no way endorse
TTS as a replacement for pre-recorded prompts. Sometimes it's necessary for
highly dynamic and varied data, but that's its only place in my opinion.

As to the use of tones and other non-verbal audio, a colleague and I were
just discussing their potential helpfulness in the same context of adding a
dimension to the interaction. What positive impact have you seen?

Phillip

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
psachs2 at aol.com
Sent: Monday, March 19, 2007 4:21 PM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

Just adding a few notes to Philip's great suggestions:

The interrupt feature should be used, but carefully controlled. There are
times you want a caller to hear the interface's instructions completely.
Each page of the IVR (i.e., each interaction) should be separately
considered and assigned appropriate properties, including interupt.

The script should indeed avoid unnecessary words, or a robotic feeling..
It's hard sometimes to convey meaning quickly with words. Long ago, I
developed a vocabulary of sounds that help speed up the interface. Sort of
like widgets on a GUI. You might not need tones, but there should be some
way to compensate for the uni-dimensional quality of telephone systems.
Also, whether a VUI sounds 'robotic' can have a lot to do with how the tech
people handle the IVR. A good techie can even make synthesized speech sound
warm and friendly.

I agree with the good advice Phillip gave about selecting voice talent. I
would add that it's often a plus to have the client present for the actual
recording, to be sure the pronunciations, inflections, speed, etc are
exactly as the client envisioned.

I am new to this list. Great to have voice matters discussed here.

Pat

20 Mar 2007 - 10:26am
mtumi
2004

One thing I found when I was doing some work in this area was the
resources I read did not address different usage scenarios very
well. They were in favor of natural language use, and the examples
fit very well for ordering tickets with an airline (a common
example), but not well for other situations (including mine,
unfortunately). I read carefully, followed the principles, and then
ended up slashing a lot of the text in the review. So I'd keep that
in mind as you review the resources.

I'd be interested in viewing any resources that take a broad range of
scenarios into account, if people know of any.

I was also surprised to find how vehemently many people were opposed
to the system "pretending to be a person". People really got mad
about it! :-)

Michael

On Mar 20, 2007, at 8:42 AM, Phillip Hunter wrote:

> Pat,
>
> Welcome! Not that I want to be disagreeable with your first post, but
> actually in my experience clients know very little about proper prompt
> delivery. My design teams have been responsible for knowing how
> language is
> to be conveyed, whether written or spoken. Also, I can in no way
> endorse
> TTS as a replacement for pre-recorded prompts. Sometimes it's
> necessary for
> highly dynamic and varied data, but that's its only place in my
> opinion.
>
> As to the use of tones and other non-verbal audio, a colleague and
> I were
> just discussing their potential helpfulness in the same context of
> adding a
> dimension to the interaction. What positive impact have you seen?
>
> Phillip
>

20 Mar 2007 - 11:16am
psachs2 at aol.com
2007

MT,

Yes many people dislike the voice system that pretends to be a person, or that gets too familiar. Sometimes I feel that Starwar's R2D2 was the ideal format for an interface; intelligent interactions, but always with awareness that the speaker is a machine ...
Pat

-----Original Message-----
From: mt at motiontek.com
To: phillip at speechcycle.com
Cc: discuss at ixda.org
Sent: Tue, 20 Mar 2007 11:26 AM
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice response), Interaction Design Standards

One thing I found when I was doing some work in this area was the
resources I read did not address different usage scenarios very
well. They were in favor of natural language use, and the examples
fit very well for ordering tickets with an airline (a common
example), but not well for other situations (including mine,
unfortunately). I read carefully, followed the principles, and then
ended up slashing a lot of the text in the review. So I'd keep that
in mind as you review the resources.

I'd be interested in viewing any resources that take a broad range of
scenarios into account, if people know of any.

I was also surprised to find how vehemently many people were opposed
to the system "pretending to be a person". People really got mad
about it! :-)

Michael

On Mar 20, 2007, at 8:42 AM, Phillip Hunter wrote:

> Pat,
>
> Welcome! Not that I want to be disagreeable with your first post, but
> actually in my experience clients know very little about proper prompt
> delivery. My design teams have been responsible for knowing how
> language is
> to be conveyed, whether written or spoken. Also, I can in no way
> endorse
> TTS as a replacement for pre-recorded prompts. Sometimes it's
> necessary for
> highly dynamic and varied data, but that's its only place in my
> opinion.
>
> As to the use of tones and other non-verbal audio, a colleague and
> I were
> just discussing their potential helpfulness in the same context of
> adding a
> dimension to the interaction. What positive impact have you seen?
>
> Phillip
>

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org
________________________________________________________________________
AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.

20 Mar 2007 - 11:12am
psachs2 at aol.com
2007

Phillip,

Disagreement is good; gets us all thinking and often new ideas are born. So please do not apologize. I'll just answer the points you made:

When used as part of the dialogue, audible tones help speed the conversation and enhance meaning (as facial expression enhances understanding in a face-to-face conversation, or as widgets help the user navigate a screen). I develop a tone vocabulary for an interface, and use it consistently. The repeat user will be empowered to speed through an interface, without interfering with the need of novice users to listen to verbal prompts. Tones also aid user satisfaction.

On the other hand, very subtle background tones can create a more lifelike experience, and to some extent, could be used to help the user navigate the VUI. I like subtle tones because they add friendliness, and remove the feeling of 'an interrogation' that I get testing some interfaces.

Either way, I take care deciding the type of tones to be used for a client (natural, mechanical, musical, etc.), and for legal reasons, I like to have tones uniquely created for a client. In any case, from my point of view, anything that reduces frustration, helps navigation and speeds up completion of tasks, is good.

You made some other excellent points. Just to clarify my meaning, I rarely need the presence of a client in the recording session. The times when it has been advantageous to have the client present for recording are, e.g., when there are pronunciations he might best decide, when there is a company phrase that should sound a particular way, when there is a foreign or regional script portion to the script that the designer might not be qualified to handle, when the information the client provided is in some way ambiguous, etc. Or, sometimes, just because there is a difficult client and his presence ensures the recording process will not be amended later.

I also agree with you that TTS is no replacement for recorded prompts. I was just trying to make the role of the technical team members clear, that a techie can even enhance TTS interchanges; I agree that in an ideal world, every word would be recorded. (But sometimes, there are budget or time constraints, or the need for some particular effect, hence the use of tts).

Thanks so much for responding.

Pat

-----Original Message-----
From: phillip at speechcycle.com
To: discuss at ixda.org
Sent: Tue, 20 Mar 2007 8:42 AM
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice response), Interaction Design Standards

Pat,

Welcome! Not that I want to be disagreeable with your first post, but
actually in my experience clients know very little about proper prompt
delivery. My design teams have been responsible for knowing how language is
to be conveyed, whether written or spoken. Also, I can in no way endorse
TTS as a replacement for pre-recorded prompts. Sometimes it's necessary for
highly dynamic and varied data, but that's its only place in my opinion.

As to the use of tones and other non-verbal audio, a colleague and I were
just discussing their potential helpfulness in the same context of adding a
dimension to the interaction. What positive impact have you seen?

Phillip

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
psachs2 at aol.com
Sent: Monday, March 19, 2007 4:21 PM
To: discuss at ixda.org
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

Just adding a few notes to Philip's great suggestions:

The interrupt feature should be used, but carefully controlled. There are
times you want a caller to hear the interface's instructions completely.
Each page of the IVR (i.e., each interaction) should be separately
considered and assigned appropriate properties, including interupt.

The script should indeed avoid unnecessary words, or a robotic feeling..
It's hard sometimes to convey meaning quickly with words. Long ago, I
developed a vocabulary of sounds that help speed up the interface. Sort of
like widgets on a GUI. You might not need tones, but there should be some
way to compensate for the uni-dimensional quality of telephone systems.
Also, whether a VUI sounds 'robotic' can have a lot to do with how the tech
people handle the IVR. A good techie can even make synthesized speech sound
warm and friendly.

I agree with the good advice Phillip gave about selecting voice talent. I
would add that it's often a plus to have the client present for the actual
recording, to be sure the pronunciations, inflections, speed, etc are
exactly as the client envisioned.

I am new to this list. Great to have voice matters discussed here.

Pat

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org
________________________________________________________________________
AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.

21 Mar 2007 - 9:26am
Phillip Hunter
2006

Michael,

That's a really good point about resource limitations. The resources tend
to address the classic IVR system types: banks, travel, call steering.
There are many specialized needs, which is where strong design skills and a
knack for the spoken language are so important.

And yes, it's not nice to try to fool people. With speech reco especially,
sometimes we even have to work to make sure the caller explicitly knows it's
an automated system. There is a way, though, to be natural and not try to
fool callers. "Natural" is one of our confused design words, right up there
with "intuitive" and "friendly".

ph

-----Original Message-----
From: Michael Tuminello [mailto:mt at motiontek.com]
Sent: Tuesday, March 20, 2007 11:27 AM
To: phillip at speechcycle.com
Cc: 'IXDA list'
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

One thing I found when I was doing some work in this area was the
resources I read did not address different usage scenarios very
well. They were in favor of natural language use, and the examples
fit very well for ordering tickets with an airline (a common
example), but not well for other situations (including mine,
unfortunately). I read carefully, followed the principles, and then
ended up slashing a lot of the text in the review. So I'd keep that
in mind as you review the resources.

I'd be interested in viewing any resources that take a broad range of
scenarios into account, if people know of any.

I was also surprised to find how vehemently many people were opposed
to the system "pretending to be a person". People really got mad
about it! :-)

Michael

21 Mar 2007 - 9:31am
Phillip Hunter
2006

Pat,

Thanks for the clarifications. So, are there specific scenarios you can
discuss where a tone enhanced a previously under-performing section of
design?

ph

_____

From: psachs2 at aol.com [mailto:psachs2 at aol.com]
Sent: Tuesday, March 20, 2007 12:13 PM
To: discuss at ixda.org
Cc: phillip at speechcycle.com
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

Phillip,

Disagreement is good; gets us all thinking and often new ideas are born. So
please do not apologize. I'll just answer the points you made:

When used as part of the dialogue, audible tones help speed the conversation
and enhance meaning (as facial expression enhances understanding in a
face-to-face conversation, or as widgets help the user navigate a screen).
I develop a tone vocabulary for an interface, and use it consistently. The
repeat user will be empowered to speed through an interface, without
interfering with the need of novice users to listen to verbal prompts.
Tones also aid user satisfaction.

On the other hand, very subtle background tones can create a more lifelike
experience, and to some extent, could be used to help the user navigate the
VUI. I like subtle tones because they add friendliness, and remove the
feeling of 'an interrogation' that I get testing some interfaces.

Either way, I take care deciding the type of tones to be used for a client
(natural, mechanical, musical, etc.), and for legal reasons, I like to have
tones uniquely created for a client. In any case, from my point of view,
anything that reduces frustration, helps navigation and speeds up completion
of tasks, is good.

You made some other excellent points. Just to clarify my meaning, I rarely
need the presence of a client in the recording session. The times when it
has been advantageous to have the client present for recording are, e.g.,
when there are pronunciations he might best decide, when there is a company
phrase that should sound a particular way, when there is a foreign or
regional script portion to the script that the designer might not be
qualified to handle, when the information the client provided is in some way
ambiguous, etc. Or, sometimes, just because there is a difficult client and
his presence ensures the recording process will not be amended later.

I also agree with you that TTS is no replacement for recorded prompts. I
was just trying to make the role of the technical team members clear, that a
techie can even enhance TTS interchanges; I agree that in an ideal world,
every word would be recorded. (But sometimes, there are budget or time
constraints, or the need for some particular effect, hence the use of tts).

Thanks so much for responding.

Pat

21 Mar 2007 - 4:24pm
psachs2 at aol.com
2007

PH,

???

Excuse me, I'm confused by your question. Where do tones enhance an IVR? That's similar to asking how does color enhance a web site, or how do visuals enhance a presentation. In B2C, the answer is just about anywhere. In B2B, it's a judgment call by the designer, knowing the characteristics of the client. Either way, if tones are used, again, be careful in selection and consistent is use.

Regards,

Pat

-----Original Message-----
From: phillip at speechcycle.com
To: psachs2 at aol.com; discuss at ixda.org
Sent: Wed, 21 Mar 2007 10:31 AM
Subject: RE: [IxDA Discuss] Good examples of IVR, (Interactive voice response), Interaction Design Standards

Pat,

Thanks for the clarifications. So, are there specific scenarios you can discuss where a tone enhanced a previously under-performing section of design?

ph

From: psachs2 at aol.com [mailto:psachs2 at aol.com]
Sent: Tuesday, March 20, 2007 12:13 PM
To: discuss at ixda.org
Cc: phillip at speechcycle.com
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice response), Interaction Design Standards

Phillip,

Disagreement is good; gets us all thinking and often new ideas are born. So please do not apologize. I'll just answer the points you made:

When used as part of the dialogue, audible tones help speed the conversation and enhance meaning (as facial expression enhances understanding in a face-to-face conversation, or as widgets help the user navigate a screen). I develop a tone vocabulary for an interface, and use it consistently. The repeat user will be empowered to speed through an interface, without interfering with the need of novice users to listen to verbal prompts. Tones also aid user satisfaction.

On the other hand, very subtle background tones can create a more lifelike experience, and to some extent, could be used to help the user navigate the VUI. I like subtle tones because they add friendliness, and remove the feeling of 'an interrogation' that I get testing some interfaces.

Either way, I take care deciding the type of tones to be used for a client (natural, mechanical, musical, etc.), and for legal reasons, I like to have tones uniquely created for a client. In any case, from my point of view, anything that reduces frustration, helps navigation and speeds up completion of tasks, is good.

You made some other excellent points. Just to clarify my meaning, I rarely need the presence of a client in the recording session. The times when it has been advantageous to have the client present for recording are, e.g., when there are pronunciations he might best decide, when there is a company phrase that should sound a particular way, when there is a foreign or regional script portion to the script that the designer might not be qualified to handle, when the information the client provided is in some way ambiguous, etc. Or, sometimes, just because there is a difficult client and his presence ensures the recording process will not be amended later.

I also agree with you that TTS is no replacement for recorded prompts. I was just trying to make the role of the technical team members clear, that a techie can even enhance TTS interchanges; I agree that in an ideal world, every word would be recorded. (But sometimes, there are budget or time constraints, or the need for some particular effect, hence the use of tts).

Thanks so much for responding.

Pat

________________________________________________________________________
AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.

21 Mar 2007 - 5:54pm
Phillip Hunter
2006

Pat,

I do understand all that. What I meant is, are there times you have seen
the use of a tone work better than a prompt for effective interaction?

Phillip

_____

From: psachs2 at aol.com [mailto:psachs2 at aol.com]
Sent: Wednesday, March 21, 2007 5:24 PM
To: phillip at speechcycle.com; discuss at ixda.org
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

PH,

???

Excuse me, I'm confused by your question. Where do tones enhance an IVR?
That's similar to asking how does color enhance a web site, or how do
visuals enhance a presentation. In B2C, the answer is just about anywhere.
In B2B, it's a judgment call by the designer, knowing the characteristics of
the client. Either way, if tones are used, again, be careful in selection
and consistent is use.

Regards,

Pat

-----Original Message-----
From: phillip at speechcycle.com
To: psachs2 at aol.com; discuss at ixda.org
Sent: Wed, 21 Mar 2007 10:31 AM
Subject: RE: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

Pat,

Thanks for the clarifications. So, are there specific scenarios you can
discuss where a tone enhanced a previously under-performing section of
design?

ph

_____

From: psachs2 at aol.com <javascript:parent.ComposeTo(>
[mailto:psachs2 at aol.com <javascript:parent.ComposeTo(> ]
Sent: Tuesday, March 20, 2007 12:13 PM
To: discuss at ixda.org <javascript:parent.ComposeTo(>
Cc: phillip at speechcycle.com <javascript:parent.ComposeTo(>
Subject: Re: [IxDA Discuss] Good examples of IVR, (Interactive voice
response), Interaction Design Standards

Phillip,

Disagreement is good; gets us all thinking and often new ideas are born. So
please do not apologize. I'll just answer the points you made:

When used as part of the dialogue, audible tones help speed the conversation
and enhance meaning (as facial expression enhances understanding in a
face-to-face conversation, or as widgets help the user navigate a screen).
I develop a tone vocabulary for an interface, and use it consistently. The
repeat user will be empowered to speed through an interface, without
interfering with the need of novice users to listen to verbal prompts.
Tones also aid user satisfaction.

On the other hand, very subtle background tones can create a more lifelike
experience, and to some extent, could be used to help the user navigate the
VUI. I like subtle tones because they add friendliness, and remove the
feeling of 'an interrogation' that I get testing some interfaces.

Either way, I take care deciding the type of tones to be used for a client
(natural, mechanical, musical, etc.), and for legal reasons, I like to have
tones uniquely created for a client. In any case, from my point of view,
anything that reduces frustration, helps navigation and speeds up completion
of tasks, is good.

You made some other excellent points. Just to clarify my meaning, I rarely
need the presence of a client in the recording session. The times when it
has been advantageous to have the client present for recording are, e.g.,
when there are pronunciations he might best decide, when there is a company
phrase that should sound a particular way, when there is a foreign or
regional script portion to the script that the designer might not be
qualified to handle, when the information the client provided is in some way
ambiguous, etc. Or, sometimes, just because there is a difficult client and
his presence ensures the recording process will not be amended later.

I also agree with you that TTS is no replacement for recorded prompts. I
was just trying to make the role of the technical team members clear, that a
techie can even enhance TTS interchanges; I agree that in an ideal world,
every word would be recorded. (But sometimes, there are budget or time
constraints, or the need for some particular effect, hence the use of tts).

Thanks so much for responding.

Pat

_____

AOL now offers free email to everyone. Find out more about what's free from
AOL at
<http://pr.atwola.com/promoclk/1615326657x4311227241x4298082137/aol?redir=ht
tp://www.aol.com> AOL.com.

11 Jul 2007 - 8:59am
Jayakrishnan K
2007

Does http://www.xtendtech.com/ivr measure up? It has a free Developer Edition for download that works under Windows 2000/xp/2003 using the multimedia interface. The Developer Edition also includes a free 1-port IVR runtime that works with Dialogic, Diva Server, Ai-Logix, Opal and Skype.

5 Jul 2007 - 2:23pm
Lyn Bain
2007

Does anyone have a good IVR prototyping tool? In the old days, we used TFLX and Watson (that\'s going WAY back), but they seem to be long gone.

Thanks.

15 Jul 2007 - 10:30pm
Lyn Bain
2007

That looks interesting. I\'ll give it a try. Thanks!

Syndicate content Get the feed