Piece in ASRNews....

A piece we wrote for the ASRNews newesletter came out earlier this week. Here it is reproduced. Please consider subscribing to the newsletter. It's chock full of must know information.

---

Back to the Future: Bleeding-edge IVR

Imagine this: every Saturday morning, the first thing you do even before you fully open your eyes is to reach for your cell phone, fling it open, press the "9" key, press the "Call" button, place the cell phone against your ear and engage an Interactive Voice Response (IVR) system as follows:

System: Hi there! The last four digits?
You: 0817.
System: Ok. Hang on. Your balance is $5,235 dollars and 23 cents. Anything else?
You: No.
System: Great. Goodbye.

At which point you would flip your cell phone shut and then rollback to sleep. The whole interaction would have taken you between 20 and 30 seconds, no more.

Compare this to getting your information from the web. If you are like us and you use a desktop at home, it means you would have had to get out of your bed, walk to the room where the desktop is, turn the computer's monitor on, click on the tab that points to your bank's login page, type the login credentials, and then navigate to where your checking balance is displayed. After that, you log out from the account and bring the browser down (to minimize any security risks), switch the desktop's monitor off, shuffle back to your bed, and finally get back to sleep. At the best, it would have taken you between 4 and 5 minutes.

What if you had a laptop? Well, maybe you would be able to shave a minute or so off, but only if you had the laptop nearby and it was connected to the Internet (which probably means that you have WIFI at home).

What if you had a PDA (Blackberry, Palm, iPhone, etc.)? You wouldn't have had to get up from your bed, right? Yes, but have you tried navigating the Internet with any of those devices? At best, it is less than a gratifying experience, but usually it is downright painful. The iPhone has made great strides over its other PDA competitors in the display of web pages, but it took a step backward in information entry: it is relatively easier to type with a Blackberry or a Palm than it is with an iPhone. "Relatively easier," because typing with the Blackberry or the Palm is no trivial skill to acquire.

So, then, it turns out that the most cutting edge technologies (desktops, laptops, PDAs) do not compare well at all with our humble phone when it comes to the simple task we described above.

What does it tell us? Simply that IVR technology is here to stay. It is here to stay because for certain tasks, it can do the job cheaper, more quickly, and require less effort on the part of the end user, than any of the most cutting edge communication technologies out there today.

But then you ask: so why do people hate IVRs? Why do they groan and shake their head in dismay when they realize that they are about to interact with a machine over the telephone?

The answer is simple: because most IVRs are atrociously designed. The interaction we described above is not your typical exchange between a user and an IVR system. Your typical IVR would have greeted you with some 30 seconds of chest-thumping messaging about the company, followed by some mindless instructions, such as, "For English, press 1," or "Please listen carefully as our menu options have changed;" would have listed a long menu of options, would have required you to select the "check balance" option, then the "checking account" option, then would have required you to enter your full checking account number, then, for security purposes, a pin, and only then would have finally given you the balance. A grueling 3 or 4 minutes would have gone by – and you would have had to get up from your bed and retrieve your checking book, unless you were so organized as to have the checkbook near by, or had committed to memory your 14-digit checking account number – etc!

So, what did it take to have the IVR system we described initially to behave as it did?

Here are the keys to its effectiveness: (1) it recognized who the caller was, (2) it knew that they were calling to retrieve their checking account balance, (3) it did not waste time talking, but said only what it needed to say, no more, and (4) it let the caller speak back their answers.

Can this interaction be implemented with today's technology? Absolutely. With the caller ID and the last four digits of the caller's checking account (easy to memorize, especially if you are calling once a week), the user can be identified and validated, and the checking account balance retrieved and spoken back to the user in a matter of seconds. With some intelligence in the back-end (a simple Naïve Bayesian algorithm would amply do), the system can quickly learn by itself that every Saturday morning, this particular customer will call to ask for their checking balance. With that knowledge, the system can adapt its interaction to shorten all of its verbal prompts to the bare minimum (e.g., "The last four digits" rather than "The last four digits of your checking account number"), ask only for the information needed to accomplish its task, and then execute that task. And with the current state of Speech recognition, letting the user speak back the last four digits of their account and say "No" are trivial tasks.

There is no reason, then, why every IVR system deployed out there today cannot be as effective as the one described above. Give the people a system that helps them, that solves their problem without wasting their time, and they will use it and love it every time.

Dr. Ahmed Bouzid heads the Partnerships program at Angel.com. Dr. Weiye Ma is an independent speech consultant. They are authors of the VUI Post blog at http://www.thevuipost.com/

The Black List....

Someone at the VUI Designers Yahoogroups discussion board asked about why deployed VUIs out there continue to include the tired phase of, "Please listen carefully as our options have changed." As some in the discussion pointed out, the phrase is either passively included (like all bad practices, people are doing it because other people are doing it), or actively added because someone in the design committee is afraid that power users will not listen to the options offered and will press the wrong old key and then get lost....

I suggest that next time you find yourself in a position of having to explain why you do not agree to including the prompt, simply explain your position as follows: Power users do not listen to prompts, and will certainly not notice the white noise language of "Please listen carefully as our options have changed" -- especially if it is played every time they call. The only way they will learn that an option has changed is for them to get lost once or twice. If there was indeed a drastic menu change and you desperately needed your callers to notice it, use something far more attention grabbing than some language signal the change (a double dings sound followed by an announcement that menu options had changed) -- and use it only when something has really changed, and for a limited period of time. And if you were really smart and cared about your callers, you would remember who has already listened to the menu change notification and so does not need to be bothered with it every time they called.

Here a few more expressions that I propose should be banned from a VUI design:

• "Your call is very important to us"
• "You can interrupt me at any time"
• "For English, press one"
• "Press X, NOW!" ("Now" being the thing to ban, especially in the context of listing a list of options to press)
• "Please select from the following menu options"

Let me know if you can think of more....

Tips for effective menu design: Part III

9. Avoid mixing voice and DTMF menu choices

If your application is voice enabled, avoid cramming your menu prompts with instructions on how to pick menu items by voice and by DTMF. Avoid, for instance, wordings such as, “You can say ‘check balance’ or press 1, ‘open account’ or press 2, or ‘transfer funds’ or press 3.” Instead, first offer the leaner voice-only menu, “You can say, ‘check balance’, ‘open account’, or ‘transfer funds’,” and only if the users seems to have trouble with it, revert to the mixed prompt, “You can say ‘check balance’ or press 1, ‘open account’ or press 2, or ‘transfer funds’ or press 3.”

10. Use the same part of speech/clausal form when listing menu options

Bad prompt:

System: You can say, “Balance,” “Open,” or “Transfer.”

Good prompt:

System: You can say, “Check balance,” “Open account,” or “Transfer funds.”

11. Keep you menus consistent with one another

For example: in the opening menu, you ask the user to indicate whether or not they are a registered customer and then you branch off accordingly. Make sure that after the user indicates that they are a registered customer, none of the sub-menus offers options that apply only to non-registered customers (e.g., “To speak with one of our agents about becoming a registered customer, press “3”).

12. Let users ask, “What are my choices?”

At any point in the call, the user should be able to ask, “What are my choices.” In response, the system should respond by, first, positioning the user in the menu tree, and then listing the menu items that the user can select from.

User: What are my choices?

System: We were transferring funds. I need to know which account you would like to transfer funds from? You can say, “Checking,” “Savings,” or “Money Market.”

Tips for effective menu design: Part II

4. Use the construct, “You can say….”

If your application is speech-enabled, use the construct, “You can say….” to list the menu options.

Example:

System: You can say, “Books,” “Magazines,” or “Newspapers.”

5. Avoid the construct, “For X, say X, for Y, say Y, For Z, say Z.”

Simply rewrite the menu prompt as, “You can say, X, Y, or Z”. In cases where you can’t find the X, Y, or Z wordings that will accurately convey the meaning of the options, then use the construct “To A, say X, To B, say Y, To C, say Z,” whet “To A” would briefly explain what the option means.

Example:

System: To get your current balance, say, “Check balance,” to open a new account, say, “Open account,” to transfer funds from one account to another, say, “Transfer funds.”

6. Don’t use, “Please select from the following options”

A tired phrase that needs to be retired.

7. Never allow holes in your DTMF choices

We say that a menu has a hole if the options presented are not sequential. A menu that offers the user the option to press “1,” “2,” or “4,” has a hole. A menu that offers the options, “1,” “2,” and “3,” does not.

8. Mark position in the menu tree

A simple, “Main menu,” played prior to listing the menu items will reduce user confusion as to “where” they are in the dialog. The menu position marking becomes even more important as the user is led deeper into the menu tree. When you are leading a user down a menu path, list a menu header whenever you traverse a path and then list the sub-menu options. In case of a no-input or a no-match, then list the full path prior to replaying the menu prompt.

Example:

System: Main menu: you can say, “Check balance,” “Withdraw funds,” or “Transfer funds.”

User: Transfer funds.

System: Transferring funds. Which account do you want to transfer funds from? You can say, “Checking,” “Savings,” or “Money Market.”

User: Savings.

System: Transferring funds from Savings.

9. Avoid mixing voice and DTMF menu choices

If your application is voice enabled, avoid cramming your menu prompts with instructions on how to pick menu items by voice and by DTMF. Avoid, for instance, wordings such as, “You can say ‘check balance’ or press 1, ‘open account’ or press 2, or ‘transfer funds’ or press 3.” Instead, first offer the leaner voice-only menu, “You can say, ‘check balance’, ‘open account’, or ‘transfer funds’,” and only if the users seems to have trouble with it, revert to the mixed prompt, “You can say ‘check balance’ or press 1, ‘open account’ or press 2, or ‘transfer funds’ or press 3.”

Tips for effective menu design: Part I

Primitive a mechanism as they may be, menus remain the most effective way to elicit information from users. The system offers a list of options, the user picks what they want, and the system moves on to the next step. Nothing could be more straightforward. And yet, one can easily design a difficult to use menu unless some basic principles are observed.

In the next few posts, I list 16 guidelines that should help you design usable menus.

***

1. Present the most requested items first

Not all menu items are created equal. If you know which items are requested most frequently, place those items at the head of the menu list.

2. Keep the menu list to 4 items or less

Because of the invisible nature of VUIs, try to keep your menus to four items or less. In case you need to present the user with more than four items, split the list into two, with the first list presenting the user with the items they are most likely to request, and access to the second list offered as the last option.

3 Keep the menu depth to 3 or less

People hate deep menus. They are exasperated by them. And the deeper the menu, the stronger the feeling that they are being led into a blind alley, with little hope to get to where they want to go. If you can’t keep your men depth to 3 or less, go back to the drawing board and see if you can’t consolidate some of those tree branches.

On Silence: Part II

3. Between categories of options

In our example, the system plays to the user three possible stock-related commands to choose from, and then plays one more option for transferring to a manager. Since the fourth option is not a stock-related command, a one second pause should be inserted between the last stock command option and the announcement for the next command, "You can also say..."

SYSTEM: What would you like to do next? You can say,
[SILENCE]
"Get quotes,"
[SILENCE]
"Buy stock," or
[SILENCE]
"Sell stock."
[SILENCE]
You can also say,
[SILENCE]
"Speak to a manager."

4. When interacting with power-users

Most of the users to the stock-management application we are using for this example are going to be repeat users – that is, power-users who will not want to listen to all the menu options every time they call. In such heavy power-user applications, use silences prior to listing menu options. In this case, add a two-second pause after, "What would you like to do next?"

SYSTEM: What would you like to do next?
[SILENCE]
You can say,
[SILENCE]
"Get quotes,"
[SILENCE]
"Buy stock," or
[SILENCE]
"Sell stock."
[SILENCE]
You can also say,
[SILENCE]
"Speak to a manager."

5. After echoing

A brief echo from the system of the option selected by the user can serve as a reassuring confirmation that the system understood what the user said, or, in case of misrecognition, as a quick indication of error. In either case, insert a brief silence after the echo. In case of correct recognition, the silence will prepare the user for the next prompt, while in case of misrecognition, it will give the user an opportunity to barge-in with a correction. (Of course, you will need to configure an error strategy that can elegantly recover from such an error.)

SYSTEM: What would you like to do next?
[SILENCE]
You can say,
[SILENCE]
"Get quotes,"
[SILENCE]
"Buy stock," or
[SILENCE]
"Sell stock."
[SILENCE]
You can also say,
[SILENCE]
"Speak to a manager."

User: Get quotes.

SYSTEM: Getting quotes.
[SILENCE]
As of 10:25 am…

6. Before and after TTS prompts

As we have mentioned in a previous newsletter, avoid mixing recorded prompts with computerized, TTS prompts. Mixed prompts make for an unpleasant audio experience and should be avoided whenever possible. In cases where you have no choice but to mix human-recorded and computer-generated prompts, insert a pause between the recorded prompts and the TTS prompts. The silence will alleviate the jarring transition and will increase the level of listener comprehension.

SYSTEM: Getting quotes.
[SILENCE]
As of 10:25 am.
[SILENCE]
IBM is trading at
[SILENCE]
eighty two dollars and thirty five cents
[SILENCE]
MicroStrategy at
[SILENCE]
one hundred and three dollars and twenty four cents
[SILENCE]
and Google at
[SILENCE]
three hundred seventy four dollars and thirteen cents

Here is the entire interaction, with all silences inserted:

SYSTEM: What would you like to do next?
[SILENCE]
You can say,
[SILENCE]
"Get quotes,"
[SILENCE]
"Buy stock," or
[SILENCE]
"Sell stock."
[SILENCE]
You can also say,
[SILENCE]
"Speak to a manager."

User: Get quotes.

SYSTEM: Getting quotes.
[SILENCE]
As of 10:25 am
[SILENCE]
IBM is trading at
[SILENCE]
eighty two dollars and thirty five cents
[SILENCE]
MicroStrategy at
[SILENCE]
one hundred and three dollars and twenty four cents
[SILENCE]
and Google at
[SILENCE]
three hundred seventy four dollars and thirteen cents

On Silence: Part I

Silence is for VUI design what the number zero is for algebra. As a concept and a tool, it is at the same time essential, ubiquitous, and taken for granted. In this post, I highlight the main cases where the use of silences and pauses can contribute to a smoother, more usable VUI.

Take the following brief interaction between an IVR stock management application and a human user.

System: What would you like to do next? You can say, "Get quotes," "Buy stock,” or "Sell stock." You can also say, "Speak to a manager."

User: Get quotes.

System: Getting quotes. As of 10:25 am, IBM is trading at eighty two dollars and thirty five cents, MicroStrategy at one hundred three dollars and twenty four cents, and Google at three hundred seventy four dollars and thirteen cents.

Let's pinpoint where silences can enhance the usability of the voice interface. I will list three points in the dialog where silences are needed. I will list more in the next post.

1. Prior to listing menu options

When the system is about to provide the user with a list of options, a brief, half-second pause should be inserted between the announcement prompt and the first option that is played to the listener.

System: What would you like to do next? You can say,
[SILENCE]
"Get quotes," "Buy stock," or "Sell stock."
You can also say,
[SILENCE]
"Speak to a manager."

2. Between options in a menu list

When listing options for the user to choose from, separate consecutive options with half-second silences. The pauses will give the listener time to decide whether to select the option or wait for the next option.

System: What would you like to do next? You can say,
[SILENCE]
"Get quotes,"
[SILENCE]
"Buy stock," or
[SILENCE]
"Sell stock." You can also say,
[SILENCE]
"Speak to a manager."

Why I prefer automation when I prefer automation

Here are 5 scenarios where I find myself preferring automation over human service. Now mind you, I am someone who loves to self check out in the supermarket even when I have a cart full of stuff -- including produce that needs to be weighed.

1. I don't have to wait a long time to get what I want done by using self-service

2. I suspect that the human who will try to help me is not going to be well trained

3. It would take longer to get what I need done with a human, even if I didn't have to wait

4. I don't want to spend the emotional energy needed to interact with a human

5. I suspect that the human will try to sell me something and I'm not in a mood to listen to a pitch

Bruce Balentine's new book

Just started reading Bruce Balentine's new book, "It's Better to Be a Good Machine Than a Bad Person," and from the few pages I have read so far, it promises to be a very good and useful book.
Here is a quick nugget:

So speech as a business has been driven by enterprise buyers that deploy the technology for end users who have no say in the matter. In other words, IVR. (Emphases are his.) (p. 197)

Then he goes on to make the following provocative statement:

End users do not value ASR highly. Nor are they likely to do so--at least in very large numbers--at any time in the future. (Emphasis is his.) (p. 197)

Now, before you rush to dump your Nuance stock, Balentine is quick to qualify his statement with, "this book is not at all negative about speech technology" and "certain speech market niches--for example, IVR--are so important from a business perspective that their value is unquestionable (and oddly, not yet very well-mined)".

Balentine's aim seems to be to want to shock us into lowering the prevailing unreasonable "Jetsonian" expectations about ASR and to settle down to solving real-problems in the real world. Or as he puts it quite well:

The key to solving the business problem of speech technologies is to let go of the future and to start working on the present. (p. 199)

Amen!

As for what "Jetsonian" means:

Jetsonian thinking goes like this: 'No problem is so great that we can't overcome it with technology. And no task is so trivial that it's not worth automating. The future is open-ended, and advancement has no cost. It is our manifest destiny to create new and complicated things in the name of progress, and even in the absence of needs.' (p. 109)