Kortum P. (ed.) HCI Beyond the GUI. Design for Haptic, Speech, Olfactory, and Other Nontraditional Interfaces

Подождите немного. Документ загружается.

7.3

CURRENT IMPLEMENTATIONS

OF THE INTERFACE

Interactive voice response interfaces are ubiquitous. It is nearly impossible to call

a phone number without the likelihood of reaching an IVR. This bold statement is

true because voice mail is an IVR application, probably the most common of them

all. Every sizeable business seems to have an IVR call router that attempts to

direct your call to the proper person or department. Once your call has been

routed, it may go not to a person but to another IVR, such as an information ser-

vice that allows you to retrieve data—your bank balance, the status of an airline

flight, or movie show times, for example. There are also IVR systems that allow

you to perform actions. These vary from home automation IVRs that turn lights

on and off to a stock-trading system that allows a caller to place buy and sell

orders. The list goes on and on.

Users will grudgingly accept an IVR so long as the task they called for can

be completed nearly as well with the IVR as the user expects it would be by a

person. In many cases, however, IVRs offer better service than would otherwise

be available. They are typically available 24/7 and are not affected by weather, ill-

ness, strikes, or new movie releases. Balance-checking IVRs at banks are a great

example—bankers’ hours are not when most of us need to know if that last

deposit has been credited or not. Although online systems perform many of

the same functions as IVRs do, there are many times when and places where

people are without Internet access, although most carry a cell phone that can be

used to call anywhere, anytime.

In some cases, an IVR is preferred over a person. IVRs offer inherent privacy

(Tourangeau & Smith, 1996). When you use an IVR, no person is listening to your

Social Security number, your PIN, or your account number. The IVR will not rec-

ognize your voice or your name and will not talk over lunch about your medical

problems, financial issues, test results, or scandalous interests—and an IVR will

not complain that you should have written all this down when you call a second

or third time.

Creating an IVR can reduce the cost of offering a service, possibly resulting in

a cost savings passed on to the customer. The personal touch, however, is lost. No

automaton can replace a person who is genuinely happy or sad for you, and not

one of us puts much stock in the prerecorded “Please’s,” “Thank you’s,” and “We’re

sorry’s.”

7.3.1 Applications of the Interface to Accessibility

For a person with a speech production deficit—a person who has difficulty

speaking, difficulty being understood, or is completely unable to speak—IVRs

are a blessing. In this case, IVRs create a means for accomplishing a task that does

7 Interactive Voice Response Interfaces

232

not require speaking. Good points notwithstanding, IVRs tend to create more acces-

sibility problems than they solve. IVRs tend to increase the cognitive requirements

for completing a task when compared with a customer service representative.

For some users with cognitive deficits, the predictability of an IVR (“Dial this

number, press 1 and then 3”) may be easier than interacting with a person. How-

ever, short time-outs requiring quick responses and the inability to get additional

explanations may make IVRs more difficult for others.

In a very, very few cases, IVRs have been built that can interact with the

TTY/TDD machines used by the Deaf to communicate via phone. However, most

IVRs are unusable by people with severe or total hearing loss. IVRs also interact

poorly with TTY relay service and communications assistants (CAs), as the

time-outs on most IVRs are too short to allow the CA to type the text of the prompt

to the relay caller, receive a reply, and then press a key in response. TTY is a slow

means of communication, and in the United States, by law, CAs are required to

transcribe what they hear from the IVR verbatim.

It might be assumed that if a person can dial a phone, he can use the IVR

reached. While there are many dialing aids for people with motor disabilities, most

of these function as speed dialers and do not have the capability to stay online

after the call completes, and do not provide a faculty with which to perform

postdialing key presses. By and large, those using adaptive technology to dial

phone calls have difficulties with IVRs.

7.4

HUMAN FACTORS DESIGN OF THE INTERFACE

The human factors discipline is what makes the difference between an IVR that

people do not mind using and one they love to complain about. Advances in

IVR software have made it possible for people with low levels of skill in computer

programming, in human factors, and in user interface design to quickly and easily

set up a terrible IVR and inflict it on the unsuspecting public. This section will

describe the human factors involved in designing an IVR. While much of this sec-

tion is based on 10 years of experience as a human factors engineer with AT&T,

many others have published on this topic, such as Gardner-Bonneau and Blanchard

(2007), Schwartz and Hardzinski (1993), Schumacher (1992), and Marics (1991).

I owe a great deal of what I know to those who have labored in this area before me.

7.4.1 When to Select an IVR Interface

Rarely, if ever, will the IVR be the only interface aimed at caring for the user’s

needs. Most commonly, IVRs share the burden with customer service representa-

tives (CSRs) with the goal of achieving some level of customer self-support

through the IVR, while the challenging, unusual, or nonstandard issues drop out

7.4 Human Factors Design of the Interface

233

of the IVR for the CSRs to handle. In these cases, it is also common to have a

website that is designed to fulfill the same goal—to enable customer self-service

to reduce the need for and cost of CSRs. Both the IVR and the website tend to cost

less than staffing a call center for the full load, 24/7. Full automation and 100

percent coverage of all issues is rarely a realistic goal, and in most cases not appro-

priate. This means that the IVR cannot be designed in a vacuum, but must be

considered as part of a system. Chapter 11 discusses in greater detail the human

factors of offering the same service over multiple interfaces.

Once it has been determined that users will want to call, the most common

trade-off to be considered is whether the phone interface should be an IVR or

a speech recognition system. Many people erroneously assume that “If only the

callers could talk to the system, it would be easier.” Although speech recognition

interfaces are the subject of Chapter 6, a few comments here would be appropri-

ate. In this author’s experience, there are three key factors to consider when

choosing between speech and IVR systems: accuracy, privacy, and the nature of

the menu content.

First, although it will be argued by every speech recognition vendor you

encounter, an IVR should be the default choice on the basis of accuracy. The

DTMF keys of an IVR are recognized with near-perfect accuracy; speech, on the

other hand, advertises recognition accuracies in the middle- to upper 90th percen-

tile. In practice, this level of accuracy is difficult to achieve—even granting it, this

level of accuracy pertains to the recognition of single utterances. The cumulative

chance for misrecognition grows with each utterance required to advance the user

through the menus to complete a task. The typical task of a caller requires several

menus to be traversed, and thus his or her success and satisfaction with the sys-

tem is dependent on multiple recognition events.

Given a theoretical speech recognition system with 99 percent recognition

accuracy for connected digits, the cumulative probability of collecting a 10-digit

phone number without a recognition error falls to 90 percent. If the application

needs a 16-digit credit card number to be spoken and a 9-digit Social Security num-

ber (SSN) for confirmation, the probability of an error-free attempt falls to 82 per-

cent. Error recovery is an important, difficult, and time-consuming part of

designing an IVR or a speech system, but given the higher probability of errors

in a speech system, more attention is required compared to an IVR.

This brings us to the second consideration—privacy. In the preceding exam-

ple, the user of a speech interface would have had to speak his credit card number

and SSN aloud. Frequently, calls to systems such as these are made from public

places such as coffee shops or airports where it would be unwise to speak aloud

personal and otherwise private data. IVRs are more secure in these cases, as it

is a challenge to determine from watching someone what the keys they are press-

ing mean, whereas phone numbers, SSNs, and credit card numbers each have a

unique cadence that when spoken makes them easy to identify. And while it

would be a challenge to unobtrusively attempt to watch a person enter key

7 Interactive Voice Response Interfaces

234

presses, it is often difficult not to hear the conversations of others whether one

wishes to eavesdrop or not. Give people a cell phone and they will talk loud. Give

them a speech system on a cell phone and they will talk louder still. Let the sys-

tem make an error and they will shout their SSN, loud and slow, so the “stupid”

system (and everyone else in the room) can clearly hear them. Good speech

designers will “fall back” to DTMF in these cases rather than require speech, cre-

ating a hybrid interface. At a certain point one has to ask how much, in what way,

and at what cost is speech recognition helping the user?

Hopefully, the honest answer to the above question is that speech is allowing

your interface to do something well that an IVR cannot. This is the third consider-

ation—the nature of the menu content. IVR menus do best with things that are

natural ordered lists, and preferably lists with fewer than 10 items. A good exam-

ple would be choosing a day of the week: “For Monday, press 1. For Tuesday,

press 2,” and so on through 7 for Sunday. IVRs also do okay with short menus that

can be ordered, although no natural order exists: “For vanilla, press 1; for choco-

late, press 2; for strawberry, press 3.” IVRs fall down when the categories are

large, creating an artificial need to break them into multiple menus.

One could imagine having to select one of the 50 U.S. states from an IVR. How

many times would you have to “press 9 for more options” to get to the menu that

would let you select Texas? What would the order on the menu be? Should it be

alphabetical, or would it make more sense to order by size, population, or fre-

quency of selection? It sounds awful—and it would be, in an IVR. Choosing a state

is the perfect task for a speech recognition system. The vocabulary is clearly

defined and bounded, but is too large to be easily done in an IVR. If your design

need is one that will cause the user to make choices from large, difficult-to-

organize groups, speech should be considered. If the need can be completed with

tasks that are limited to menus that are short and can be sensibly organized

numerically, an IVR should be considered.

The preceding is not meant to scare designers away from speech recognition

systems, as they have their place; rather, it is meant to allow for a reasoned choice

when speech is inevitably presented as the cure-all that will make users happier

and more successful than a stodgy old IVR. Newer and flashier almost always

means more expensive, and “better” can only really be judged by users.

7.4.2 What Data Should Be Collected

to Design an IVR

The single most important thing to know is that you are not representative of the

users of your IVR. You will have to find out who the users are and as much as you

can about them. Why did they call the number that got them connected to the

IVR? What goals do they have and what tasks are they hoping to complete? What

do they know? Have they done this before? What level of functional vocabulary

7.4 Human Factors Design of the Interface

235

might they possess? When you begin to look really hard at the answers to these

questions, the implications can be staggering.

Who are the users of voice mail? There are two kinds of voice mail users: the

subscriber who is retrieving messages, and callers who leave messages for the sub-

scriber. There are not many good assumptions you can make about either user.

Both could be of nearly any age, 6 to 106, of any vocabulary level, and neither may

speak the primary language of your area. A useful trick is to use grammar checkers

available on the Web or in many word processors to give you the reading level

of your prompt script. In Microsoft Word, go to Tools > Options > Spelling &

Grammar, and place check marks in the boxes for “Check grammar with spelling,”

and “Show readability statistics.” In most cases, for general telephony applications

we have found that prompts written at the

third-grade level

or lower perform well

in usability testing. The subscriber could have received some materials from you

such as a user guide—and they may or may not have read them.

Voice mail illustrates two broad categories of IVRs: subscribed to and “walk-

up-and-use.” In a subscribed-to interface, the user may have received training

materials, and is likely to use the IVR repeatedly with some learning. In a walk-

up-and-use interface, the user may have no idea why they are hearing a recording,

no training, no experience, and no desire to participate in what is being asked of

them. For these reasons, the user interface design bar is much higher for a

walk-up-and-use interface.

In most IVR designs, there will more than one set of users, so you must be

certain that the user interface gets designed for the real users. For example, con-

sider an IVR built for the accounting department that keeps track of the hours that

employees work and then feeds those data to a payroll system. Without consider-

ing the large number of employees who will have to use the system to enter time,

the IVR will get designed by and for the few payroll personnel who need to use it

to pull reports. It will contain jargon and acronyms specific to accountants that

will be unfamiliar to the majority of users. The process of entering time will be

constructed around the database used to store time data, not the way a “normal”

person thinks of the work week.

It is paramount to understand that your IVR will likely have more than one type

of user, and that each type has differing goals and characteristics. If one group of

users controls the design, there is a high risk that while their needs will be consid-

ered, the needs of any other user population will be left unconsidered, or poorly

cared for in the design. The typical end result is a system that “functions,” that is,

the task can be completed using the IVR, but with high training costs, low success,

high error rates, and low satisfaction. Recognizing that there are multiple user types

and allowing for their needs in the design will lead to a more successful design.

Even an IVR that is designed to simply route callers to an appropriate person

or department requires human factors techniques to succeed. Determining what

to call items on a menu, and what subitems fall under each menu heading,

should be a human factors exercise, not simply what the designer thinks will

7 Interactive Voice Response Interfaces

236

work. Card sort techniques are quite useful here for determining menu terminol-

ogy and mapping. We once had an incoming call router in one of our regions that

was intended to allow callers to reach a person in one of our departments who

could solve the caller’s problem. The original call router had been developed with-

out the aid of human factors, and had been created from the company’s and not

the customers’ point of view. The main menu offered choices of Departments A,

B, and C. Customers frequently had difficulty determining which of our depart-

ments should handle their problem; they made a choice but reached the wrong

department. The CSR they reached had to determine the nature of the problem,

the correct department, and then manually transfer the call. Everyone was frus-

trated: the customer, the CSR, and the corporation because of the wasted time.

Staff in our human factors group sampled approximately 20,000 calls to deter-

mine the “reason for calling.” We brought in participants and asked them to sort

the 30 or so most common reasons for calling into groups. We did not specify

the number of groups, just that there be at least two. We then analyzed the group-

ings for common patterns and found a set of three groups that appeared to fit most

participants’ view of how to organize the reasons for calling. A second group was

brought in to view the groups and the reasons in them and to provide suggested

names for the groups. A third group was then brought in to validate both the

names and the groupings. Given a reason for calling and the names of the three

groups, we asked the participants to tell us under which group name they would

expect to find each reason for calling.

This process may be repeated until a satisfactory result is obtained—that is,

that a group of naı

ve users can reliably select a named menu option that will solve

their given problem. The menu for this call router was recorded using the names

resulting from the study in the form of “For a problem of type 1, press 1; for a

problem of type 2, press 2; or for a problem of type 3, press 3.” No new technology

was applied; the routing did not even have to be changed. The improvement in

efficiency resulted in a recurring $29 million annual cost savings. The cost to

achieve this savings? About 6 to 8 weeks of time for one human factors engineer,

and less than $10,000 in recruiting and incentives for participants. Customers

were less frustrated—they routed themselves correctly more often. The CSRs

were happy—they got credit for serving more customers rather than spending

time transferring misdirected calls. The corporation was pleased to have happy

customers and happy employees, and to have improved efficiency.

7.4.3 How to Specify an IVR

Small IVRs can be specified in a text outline or as a page or two of pseudocode.

These methods are sufficient for a one- to two-level–deep menu. An example

might be a small company call router where you have three departments and

one to five employees in each department. For anything larger or more complex,

flowcharting or state diagramming will be required to fully describe the desired

7.4 Human Factors Design of the Interface

237

behavior of the IVR. There are many different styles and conventions for how to

lay out the diagrams that describe a user’s progress through an IVR. Consider

using a format that completely describes only one menu per page. Formats that

spread logic across multiple pages often make it challenging to understand what

the desired behavior is.

7.4.4 What the Flowchart Should Show

What is the phone number that must be dialed to reach the IVR? How many times

will it ring before the IVR comes on the line? As soon as the IVR answers, what is

the first prompt to be played? Typically, the first prompt identifies the organiza-

tion that you have called: “Welcome to AAA Plumbing.” Immediately following

the first prompt is usually a choice of some type. In order to fully describe the

actions on a menu, each of the 12 DTMF keys (0, 1 to 9, * and #) must be assigned

a function or path. A value for how long the system will wait for a response (5 to

6 seconds is good) before “timing out” and doing something for the user is needed,

as well as the action to be performed on a time-out. What the system should do if

the user hangs up at this point in the process must be described as well.

In the example of Figure 7.2, the user has made a selection on the main menu

indicating that she wishes to change her language selection (currently English).

Upon entry, the error count is set to zero and the menu is played. The IVR then

waits for a key press (hopefully 0, 1, 2, 3, or *). If the user presses * (star), she

is given a status message that the language selection has not changed and then

returned to the main menu. Upon pressing 1, the flow continues to another page

where the language will be changed to English. Upon pressing 2, the flow

continues to another page where the language will be changed to Spanish. Upon

pressing 3, the flow continues to another page where the language will

be changed to bilingual, which will allow a caller to choose either English or Span-

ish when she calls. If the user presses a key with no function (4, 5, 6, 7, 8, 9, or #),

she is informed that the key she pressed is not one of the options. The error count

is then incremented.

On the first error, the user is returned to the menu to try again. On the second

and third errors, the user is played a context-specific help prompt before being

returned to the menu to try again. On the fourth error, the user receives a status

report that the language settings have not been changed and the call is discon-

nected. Calls are disconnected after multiple errors to protect the IVR platform

from being overloaded by calls that are not able to use the system. Most of these

calls are from autodialers trying to make sales calls, fax machines, or hang-up

calls. It is the responsibility of the IVR designer to ensure that it is easy enough

to use that few of the disconnected calls are real users who are frustrated. If the

user presses 0 (zero) or times out with no response after 5 seconds, the error

count is incremented and error handling follows. This illustrates how a “simple”

three-choice menu is more complicated to specify than one might expect.

7 Interactive Voice Response Interfaces

238

LANGUAGE

ANN 949) Language Menu:

• To use English only, press 1.

• To use Spanish only, press 2.

• For you and your callers to have the choice

between English and Spanish on each call,

press 3.

• For help, press 0.

• To go back to the main menu without

making any changes, press star.

NIA 951)

Your language

settings have not

been changed.

MAIN MENU

ENGLISH

SPANISH

BILINGUAL

DISCONNECT

ANN 950) Language

Help Menu:

From this menu you can

change the language that

both you and your callers

will hear. To keep the

setting you have now,

press star.

NIA 099)

The [DTMF] key is not

one of the choices.

NIA 951)

Your language

settings have not

been changed.

Error count = 0

FLUSH

BUFFER

DTMF 0

for help?

Increment

error count

0 or 5 sec Time-out

4-9, or #

123

0, 1,

2, 3,

Error #1

Error #

Error #4

Ye s

Error #2,

FIGURE

7.2

Example of a flowchart for a three-choice IVR menu.

The user has made a selection on the main menu indicating a desire to change the

language selection (currently English).

7.4 Human Factors Design of the Interface

239

7.4.5 Recorded Prompts

By the time the hard work of designing the logic of the IVR is complete, prototyp-

ing has been done, it has passed usability testing, and people are ready to get the

IVR out the door. Consequently, one of the most important aspects of an IVR—the

recorded prompts—is often given very little consideration. The prompts will have

been “word-smithed” during usability testing, so that

what

is said works well.

How

it is said, though, is of equal importance. It is not uncommon for the task of

recording the prompts to fall to someone on the development team, the secretary

who answers the phones in the office, or the technician installing the hardware.

Only occasionally does this result in good recordings.

The person reading the prompt script, your “voice talent” need not be a

professional, but his or her voice must be pleasant, friendly, warm, engaging, rel-

atively free from accents, and should give your callers the impression of your

company or organization that you desire. Irritating voices; bored or haughty

voices; speech impediments; and gum smacking ought to be avoided. The charac-

ter of the voice should match your application. A chirpy, gushing cheerleader

voice is probably not the best choice for a somber application like a hospital,

church, or bank.

On the other hand, the voice talent for a health club, car dealer, or dance club

may need to be engaging and upbeat. If your IVR may change over time, select

a voice talent who is likely to be available in the future for additional recordings.

It is best to have the entire IVR recorded by a single voice talent (Christodoulou,

1996). If you cannot use the previous talent again, you may incur the expense

of rerecording the entire script to effect a simple addition or change. In some

cases, the voice talent becomes a large part of the “brand” by creating a “persona”

that comes to represent the company or organization that the IVR serves. Many

celebrities lend their voices to corporations hoping to influence users of their IVRs

through familiarity, recognition, and associations with the voice talent. Verizon

has used James Earl Jones’s distinctive voice (the voice of

Star Wars’

Darth Vader)

primarily in advertising, but also in some of their IVRs. When creating a persona,

it is important that the persona reinforces, rather than challenges, the politics and

culture of the organization it is intended to represent.

One area that is particularly challenging for IVRs is handling bilingual or mul-

tilingual needs. Designers often flippantly suggest that “we’ll just translate it and

record the script in two, three, or ten languages, and then

all

of our customers will

be able to use it.” There are several fallacious points in the preceding statement.

Even high-quality translations do not often result in usable IVRs. One issue is that

concepts and metaphors that work in one language are not always appropriate

in another. If English is the original language of the IVR, translations often result

in longer prompts, in some cases exceeding limitations that were not a problem in

English. Without usability testing of the translated script, how it will perform is

unknown. The pool of human factors professionals is small to begin with; fewer

7 Interactive Voice Response Interfaces

240

still are able to perform testing in multiple languages. Suddenly our “easy” task is

becoming more complicated.

The hardest part of a multilingual interface is simply getting users to stay with

it long enough to use it. In order to tell the IVR the language that you want to use,

you must wait until you hear—in a language you understand—the instruction to

choose a language and the key to press to select it. A nice graduate thesis could

be built around answering the question of how many options for a language a user

will listen to in a language they do not speak before hanging up. It is therefore

important to understand the expected user population before reaching for a mul-

tilingual solution. Be careful to evaluate your decision based on the number of

non-native speakers rather than on ethnicity.

Experience tells us that most voice talents are female. For better or worse, our

old cultural stereotypes are still with us. Unpublished research from our lab sug-

gests that female voice talents are perceived as “friendlier” than male voices, while

male voices are more “credible” than female voices. In one study, we varied the

gender of the voice talent across two types of recordings: menus that offered

choices and responses that provided information. Not surprisingly, the IVR that

subjects in the study had the most confidence in and rated as the friendliest had

a female voice talent offering choices and a male talent providing the information

that the user was trying to retrieve. What was surprising was this—almost all

subjects reported hearing only a single voice talent!

The script that the talent will follow to record your prompts is an important

tool for increasing the quality of the IVR. In many cases, a simple list of phrases

is provided to the voice talent. While this will get the job done, there is no con-

text—that is, no means for the voice talent to try to understand what is happening

or how he can make it easier for the user to understand by pausing or pacing the

prose. It can help to provide some side notes to the talent, such as “This ‘hello’ is a

statement of greeting, while this ‘hello’ is a question—are you there?” Scripts often

break prompts into short phrases, and it is often not obvious to the voice talent

how phrases will be combined. Without this knowledge, the combined phrase

may sound awkward when played in sequence. If possible, it is productive to have

someone from the design team who is intimately familiar with the flow and

prompts of the application sit with the voice talent to coach her as prompts are

recorded.

Regardless of the methods used to procure the prompts, it is necessary to per-

form a full test of the complete application to ensure that the right prompt plays at

the right time, sounds good, and contains the correct verbiage. When producing a

script, best practice is to spell out numbers as you want them read. Instead of “20,”

write out “twenty” or “two-zero” or “two-oh.” In the United States, the number 0 is

usually read as “zero” and in some cases as “oh,” while in other countries it may be

read as “zed.” U.S. convention for the # key is “pound,” and the * key is read as

“star.” There are international differences in these conventions. You must not

only know your users so that a correct specification can be created, but with

7.4 Human Factors Design of the Interface

241