Voice User Interface Design VUI

How many times have we heard that we should focus on our users (customers), that systems should be easy to navigate and callers should be able to find what they are looking for… as long as we include the things a current system is doing, what the website offers, and what the marketing department wants to let caller know the company offers as well.

Sounds familiar?

It is the continuous battle between companies’ interests and serving the customer. Between more features and improving the basics. Between simplicity and complexity.

The argument of course is that with more companies offering some sort of self-service solution, most companies believe the only way to differentiate themselves is to throw in more features/services/products than the competition. But then reality kicks in when those callers attempt to use the system…

Furthermore, as Gerry McGovern points out, there are a lot of pressures to create a complex system. “Designers like a complex challenge, complicated technology keeps
IT busy, and your boss may be impressed with all this extra smart stuff. The initial impression of customers might even be that they love these clever, cool features.”

On top of that, we have the user. We are all users of something, right? And if you’re honest with yourself, you’ll find that the last time you purchased something (new cell phone, plasma TV, car, etc.), chances are you found yourself comparing ‘features’ side-by-side to help you decide which one to pick (and no, I wasn’t standing behind you

But then, once you had a chance to use that product, weren’t you satisfied with the simpler version, the one that worked out of the box, the one that didn’t need a PhD to turn it on?

And we are not alone in this. According to a study released by Smith School of Business at the University of Maryland, it’s an effect called “Feature Fatigue” in which consumers/users first “give more weight to a product’s capability benefits and less weight to a product’s usability before they use the product than after they use the product-despite the fact that a product’s usability strongly influences their satisfaction with the product.”

So how do you deal with a user that claims to want more simplicity, yes it sold on more complexity?

I would say the real question should be: “Do you want to be a one-time wonder, or would you rather be the one that gains market share and consistently and systematically deliver a good experience that makes happy and returning users?”

VUI Designers need to balance first impressions against long-term satisfaction. Even though simplicity is hard to sell in the short-term, it is in the use of that thing that simplicity shines. Tools such as Usability and Live Call Monitoring allow us to show our designs in action and should be enough to convince higher management to let us focus more on improving the basics, which will result in a better investment of time and money for everyone.

That’s what Kathy Sierra blogs about, and in particular, she had some very interesting remarks in her speech at this week’s “South by Southwest” (SXSW) conference.

Some of the ones that I feel include the Voice User Interface community and challenge us to think outside the box include:

• “How can we make our apps feel more human (without the smell part)?”
• “What can a human do with another human that they can’t do with a computer?” (or phone in our case)
• “By choosing help, aren’t users letting us know already they are confused?”
• “There’s nothing wrong with Help and FAQs, they are nice reference documents,… but we need something different.”

Kathy has been working for a long time in game development and seems to understand that there are many interaction elements (such as facial expressions or asking questions) that just can’t be properly interpreted and acted upon by an artificial entity with which the user is interacting. Therefore, in order to compensate for those limitations, we have to give our applications a way to know that our user is confused… in other words, we move beyond a bad application that a caller hates (what she calls the “suck threshold“) into one where the user starts to feel passionate about because systems are supporting them in what they are trying to do.

In particular, on the subject of “Help”, she explains (and I agree with her) that when people choose “Help”, a designers conception on what the user might be feeling (casual user, relaxed, no pressure) is very different from what they are really feeling… they don’t want to hear yet another navigational maze anymore than they want to hear a voice from India if they’re calling a customer service line from Arizona.

One suggested alternative is to maybe create a special question, narrow down the user choices, and then present a list of choices that’s much more context-sensitive.

I ran across a very interesting entry regarding user control vs. user happiness. Just like with everything else, we’re always struggling to find that delicate balance between giving users too much control (sometimes setting up the wrong expectations or not being able to deliver), or too little, making users suffer or worse, leaving them trap in an IVR jail.

Furthermore, how do we deal with customers expectations: on one hand we suffer from “featuritis” (expecting to do/get/have more with the same) which tends to cause stress (as addressed in The Paradox of Choice book, by Barry Schwartz) while on the other we ask for simplicity (a topic I covered on my last SpeechTEK Presentation)

The note in particular that I think captured this dichotomy perfectly was “The big problem is that we make our beginning users suffer just so our advanced users can tweak and tune their configurations, workflow, and output.”

Finally, the author’s simple rule: “The amount of pain and effort should match the user’s perceived payoff.” makes you wonder… how can we VUI Designers get better at setting up the right payoff expectations? Is the amount of pain and suffering we’re causing justifiable?

I would like to propose my own rule as a challenge to spark your creativity: “The amount of pain and effort should be inversely proportional to the user’s perceived payoff.”

…and if you think that’s impossible, here’s an example: When the internet first started, we knew that the amount of time it took to download files matched the number of users attempting to do the same at the same time; therefore with more users, the web became slower (common sense, right?). But then P2P (peer-to-peer) networks were developed, so now that relationship not only became less relevant but was actually reversed (by removing the centralized limitation): with an increase in the number of users attempting to download a file, the speed with which it can be downloaded increases!

(Adaptation from Gerry McGovern’s New Thinking column)

Marketing and legal messages, as well as reference to “visit our website” are the curse of the Phone. Those intrusive messages reflect a company way of thinking that’s centered around what the company wants to tell a caller, and not on why the caller is picking up the phone in the first place. On the phone, we need simplicity.

Every time I pick up a phone and get the traditional “Your call may be recorded for quality purposes”, “Your call is important to us” or even “You can visit our website at …”, I can’t help but feel bad for those VUI designers that *I’m sure* did everything they could to avoid cluttering their designs with messages like these.

I understand the intention of those messages but this is the phone. I really don’t care much about a company’s quality initiative or marketing efforts to drive more traffic to the web: “I’m in a hurry and I want to complete a task.”

The user experience is not really going to change if you tell them how important they are, even if the voice comes from a perfect Persona. But if you solve their problem fast and efficiently - either through an automated system or a live agent - then that tacit message becomes very clear to them.

Otherwise, your company and your service scream “We don’t care about your time. We took this legal disclaimer/corporate mandate/marketing initiative, recorded it and put it on our phone because we wanted it.”

What’s even worse, if someone calls you it means that you have already got their attention. Your website, brochure, statement, or whatever other form of communication or marketing you used, has worked. The worst thing you can do now is keep using tactics for getting the attention of someone whose attention you already have. For example, if I go to a website and cannot complete a task, I look for their contact information and call them directly. Therefore what experience do you think that company delivers when the first message I hear advertises the website which failed me in the first place.

We need to think about the purpose of the messages we’re creating. What is its job? What is it meant to achieve? What do our callers need to do and how will this content help them do it? Too many companies create messages without asking themselves these questions.

Banning the use of disclaimers, legal and marketing messages (or at the very list, making them optional for customers to listen to - similar to how software and websites work which give you the option to read it) will dramatically improve the ability of your callers to complete tasks quickly and simply.

As an added bonus for all those VUI Designers out there, I want to add one more guideline for handling errors when designing Voice User Interfaces:

Guideline #6: Be relevant

Throughout the system, any good design should strive to obtain as much information as possible from user profiles, back ends or any other sources of information so that the customer experience is as personalized as possible.

At a minimum, the only options that should be presented to a caller are those that are relevant to them and what they are trying to accomplish in the system – in other words, cross-selling, advertising and marketing efforts should only be employed if the caller requests them or are relevant in the current context, without interfering with the task.

Furthermore, the interaction should reflect the status and events that occurred during that interaction. For example, if a caller is taken back to a “main menu” after successfully completing a transaction, then the system should now offer as part of the choices the option to hang-up. Furthermore, if the data shows a strong correlation between certain choices (e.g. one being used after another one), then that choices should be presented to the caller first, and if possible and if the caller had already declined to repeat the same successful task again (e.g. said no to performing another money transfer), then that task choice should be moved towards the end of the list.

Other articles on this series: [1], [2], [3], [4] and [5]

Wrapping up the series, here’s the fifth guideline for handling errors when designing Voice User Interfaces:

Guideline #5: No need for help

This is another controversial guideline in which VUI designers again advocate either its use or its avoidance, without any clear consensus.

The idea of “help” (specific error prompt normally played a caller says “help” which is part of the VoiceXML specification) was developed in order to provide context-sensitive assistance to callers struggling with a system.

Furthermore, some production systems have help messages that are everything but helpful in the sense that the do not add any information or clarification from what the previous prompts presented.

In terms of actual data, most pilot analysis data has shown that at least from an English-caller perspective (Disclaimer: foreign language pilot analysis shows user requesting ‘help’ much more often than their English counterparts), it isn’t very natural for someone to request “help” from a system.

Even when help is requested, most of the time what those callers are really looking for is an option to exit the system and talk to a live representative, or in the case of menus, they are looking for options that are not available at that particular point.

Instead of using generic help, the suggested strategy includes:

• Employ usability research to identify choices callers may be looking for or expecting in certain place of the application that are not available by design
• If options cannot be added to an application (not possible to implement), then consider adding a “something else” category which would then transfer the call to an agent. The end result is the same as erroring out, but it gives callers confidence that the system is working and that they are moving on successfully
• Include instructions on how to talk to someone on the second-level error prompt

Other articles on this series: [1], [2], [3], [4] and [extra]

Getting close to the end of the series, here’s the fourth guideline for handling errors when designing Voice User Interfaces:

Guideline #4: Second-level errors should be relevant and informative

Even though this sounds obvious, most applications out in the market tend to use a second-level error strategy which boils down to either a repetition of the first error message played or the help message, prefixed by “I’m sorry, I still didn’t get that.”

Therefore, the intent of the second-level error message should be to try to get the user back on track in a final attempt while addressing most of the reasons why they ended up in that situation in the first place.

Some of the suggested strategies include:

• More detailed explanation of each one of the choices (e.g. from “transfer funds” to “transfer funds between your account”, from “get your balance” to “get your latest account balance”, etc.)
• “Sneak preview” of other choices available, transfer options, and ‘hidden shortcuts’. If a menu contains a “more choices” or “something else” category, this message can give an idea of the choices contained under them (e.g. “or if you want to do X, Y or Z, you can say ‘more choices’.”) or provide secondary/hidden shortcuts not presented on the previous prompts (e.g. “or to start the transfer over”, “you can also say help for more information”, “or to talk to someone about this problem”, etc.)

Other articles on this series: [1], [2], [3], [5] and [extra]

Continuing the series, here’s the third guideline for handling errors when designing Voice User Interfaces:

Guideline #3: Avoid the use of delayed help

This is a controversial guideline in which VUI designers don’t seem to have found a consensus on whether the benefits justify the difficulty of implementing it properly.

The idea of “delayed help” (additional information played following an initial prompt after a predetermined amount of time) was developed in order to serve both expert and novice users at the same time: the former could respond and move on after listening to the initial prompt, while the later could get a little extra piece of information that would help them choose the right option on the first attempt.

Unfortunately most pilot analysis results have shown that even though this approach might have a place on the Design toolbox, most of the time the risks and implementation complexity associated with the pausing denies any potential benefits.

The top two issues are related to the fact that the time of the pause in between prompts is very hard to determine since there are multiple factors affecting it such as context, state of mind, complexity of initial prompt (since users need to understand the choices they just heard and make a decision), caller base demographics, etc.

Aside from trial and error there isn’t an easy way to determine what the ideal length should be, and the frequent turn taking issues that arise once an error occurs (caller takes too long to respond so they speak while the delayed help is being played, which causes a barge-in and tends to lead callers to stop talking in the middle of their response).

Other articles on this series: [1], [2], [4], [5] and [extra]

Continuing the series, here’s the second guideline for handling errors when designing Voice User Interfaces:

Guideline #2: Maximum of two errors - of any kind!

Most systems keep track of error events using individual counters for each error event (no speech and no match), which could potentially be reset if the interaction is part of a complex tasks that requires multiple interactions (e.g. A user validation that requires a combination of account number and password).

Therefore, it is possible that a caller would need to error more than two times before the system transfers the call to an operator (e.g. a no match followed by a no speech timeout), in some cases leading to infinite loops from which users cannot recover (e.g. user enters an account number and PIN which don’t match, so for security we ask them to reenter them again which in return resets individual error counters for each individual piece.)

In order to avoid that situation, custom counters should be implemented to account for cumulative errors that could encompass multiple error types, multiple states, or even multiple tasks in a single call.

For example, a system could be developed to only allow a total of two consecutive errors anywhere in an application (no matter the error type), two consecutive retries (e.g. validating a user, performing a money transfer, etc.), or a fixed number of total errors on a single call.

Other articles on this series: [1], [3], [4], [5] and [extra]

As part of an ongoing series, I thought I would share with you some of the error handling guidelines I follow when designing Voice User Interfaces. As you may have noticed, even though there are a few ‘guidelines’ out there, there isn’t a real industry consensus around when should each guideline be used, their pros and cons, or data to support a particular strategy.

So here it is, a list of what I consider the Top 5:

Guideline #1: First errors as retries - the power of intent

When an event is thrown – either by a no speech or no match event – most speech applications tend to have a single prompt that attempts to help the caller recover.
Unfortunately, both of those scenarios – a caller not responding, saying something the system wasn’t expecting, or triggering barge-in – are consequences of different intents.

From Pilot analysis we have observed that most callers tend to react positively to “retry” strategies that attempt to address both of those scenarios while at the same time avoid making it obvious to the caller than an actual error has occurred.

There are two main strategies that can be used independently or combined to implement such a strategy:

a) Repeat the same question with a different intonation.
Just as people behave naturally on their day to day interactions with someone else, we ask a question and then if the respondent stays silent, we simply repeat the same question with different rising intonation that conveys a natural repetition.
For example, if someone is going through the identification process and we were to ask “What’s your ACCOUNT number?” as an initial prompt and an error is triggered, we would repeat the same question with rising intonation that ends up a little higher than the original one (e.g. “What’s your account NUMBER??”)

b) Rephrase the question while keeping it simple and direct.
To help callers that may not have understood the question in the first place or that triggered a barge-in event earlier enough to where they couldn’t hear the question in the first place, we simply rephrase the question without adding more detail to it.
For example, if someone completes a transaction and we want to decide whether to complete the call or offer them more choices, we could ask “Is there anything else I can help you with?”, using use as a first error prompt: “Would you like to do something else?”

Other articles on this series: [2], [3], [4], [5] and [extra]