Voice User Interface Design VUI

A common problem we always face is how to deal with Menu Choices… How many menus do I need? In which order should they be presented? Are the labels I’m using clear? Should I concentrate on actions callers can perform or objects they are looking for?

In particular, one that’s pretty hard to solve is the number of choices that should be offered at any time. Some developers stick to certain Human-factor derived rules such as the “5 choices maximum”. Others prefer to split them into layers so that you only offer two or three at a time, followed by the familiar “more choices” menu which then takes you to a second (or even third) set of choices. At any rate, you’ll notice there’s a common theme among all these choices: “How can I add more choices without hurting my callers too much?” (even if we don’t like to accept that’s what’s going on)

But a very intriguing question I normally have when adding a new choice is: “Are we adding more than we’re subtracting?”

It was interesting to see I’m not the only one with these types of questions. Gerry McGovern recently shared similar concerns in relationship with the internet and web applications. We are very familiar with this concept, particularly every time we ‘upgrade’ our computers or a particular application software - we know where things are, we know how to get what we want out of them, and then once we move up to an upgrade version, chances are we’re going to be welcomed by a new myriad of choices, different menus, and sometimes even different terminology for the same concepts we were already familiar with. Taken to the extreme, we run into situations like the one MS Office 2007 users are facing where interfaces are so different than it requires users to learn the mental model of the developer.

Now, taking that back to our VUI world, I’ll take one of McGovern’s examples which I think helps answer the question about the real value a choice adds.

If we were to have 100 units of “attention” we could use and we listen to 5 menu choices, it means we can give 20 units to each choice. If we were to add a new option, it would be like taking 4 units away from each of the other choices, or else you force the caller to spend more time processing the information and increasing the likelihood of them making a mistake or running into an error.

In other words, “Every time you add, you subtract attention.” says McGovern. And I’ve seen that in action both in production systems and in Usability tests: when menu choices exceed the attention capacity of a caller, there’s a point where they simply stop listening or give up.

Unfortunately, businesses don’t think that way (which make our job harder, but at the same time more important). For them, if they have 4 choices covering 80% of the calls (let’s say that gives them a value of 80, so 20 points each), and we add a fifth option that has an intrinsic value of 5 (lets assume it’s the reason for another 5% of the calls), they would argue we added value to the solution, which went up from having a value of 80 to 85.

However, what happens if the caller is looking for one of the original 4 choices and becomes distracted or confused by the new one? That could cause them to choose the wrong one, to choose more than one or to mix-and-match the choices which would leave us with an ambiguous result. So going back to our example that would mean that we would get the value of 5, but in return we lost the 20 we would have gained if they had chosen one of the original menu choices. And not only that, but the likelihood of them having to find a way to go back, running into errors or getting transferred just went up because they would not find what they were looking for.

Bottom line, any choice should add value to the caller and not waste their time. “Value IS what the impatient caller values.”

There was recently a very interesting discussion on the VUIDs board regarding timeouts and their guidelines, so I decided to share with you the ones I use for “inter-word timeouts” (also known as ep.EndSeconds in the Nuance platform, or as incompletetimeout in the VXML world).

By inter-word timeouts I’m referring to how much silence takes place “mid-speech” before we assume the caller has stopped talking. This parameter is important because there are certain types of information (and therefore responses) that generate natural pauses. Therefore we need to allow for an appropriate amount of time within the response (e.g. someone saying their telephone number and pausing between the area code and the phone number), while at the same making sure it is not too large since that same timeout will have to expire in order for us to consider the caller is done.

One more thing to keep in mind is that these are not really guidelines but rather baseline recommendations you can use, which then need to be reviewed and adapted based on the context of the application, your audience (age and language play a role here) and the type of prompt. Once these suggestions are implemented and rolled out, they can be optimized based on Usability tests and actual Pilot data.

• Single, short word responses (Yes/No questions included): 0.75 sec
• Short word Menus (e.g. “Checking”): 1.0 sec
• Long word/sentence Menus (e.g. “Get my account balance”): 1.5 sec
• Number/Amount capture (e.g. check amounts, rates, etc.): 1.0 sec
  • NOTE: You may want to go up to 1.5 sec for really long amounts such as a mortgage loan
• String sequences (e.g. account numbers): 2.0 sec
  • NOTE: Depending on the number length and its natural pauses, you can tweak this number. For example, use 1.5 sec for 4-digit PINs, 2.0 sec for 9-10 digit numbers such as a phone or fax, and even 2.5 sec for long numbers such as a 16-digit credit card number.

Finally, regarding age, I’ve found out that you tend to need longer pauses for higher age ranges, specially if it’s information they need to read back (e.g. from a statement) or write down (e.g. a confirmation number).
Language wise, some languages are more synthetic than others (e.g. English is very synthetic), so I’ve found that in more explicit languages (such as Spanish and French) your grammars need to be more robust which in return may require longer pauses.

Any others I might have missed?

I was reading an article this morning about things we can learn from Social Design. In particular, what I liked was the fact that they weren’t trying to analyze the typical examples - Facebook, YouTube, SecondLife, etc. - but rather learn from the mistakes of other less-known ventures.

In particular, there were four “Lessons Learned” that Joshua points out that I think apply to Voice User Interface design and any type of self-service application:

1. Not attracting enough users (aka. not retaining enough users or having them choose other service alternatives such as a live agent)

If you design and develop a great self-service system and nobody uses it (or opts out), you have this problem. What’s even worse, some companies think that they way to solve it is to make it hard for callers to talk to an operator, add more options, or spend more money marketing the system, which is the wrong move. Good applications (like social sites) build value one user at a time. As Joshua points out, “If one user finds value, then they’re much more likely to tell others or invite their friends.” Therefore, one-size fits all systems aren’t the answer. Instead designers (and businesses) should focus on succeeding on a smaller level, focusing on individual users and their needs. One very interesting point I loved was “One strategy in particular is to design for your friends, get the system working well for them, and then release it to a broader audience”. What would happen if we started to design our apps for our friends and families instead?

2. Trying to do many things at once

Too many times I’ve heard the casual customer request: “The system should provide the same functionality the old system had, plus the new features the website offers, along with some new initiatives we’ve been thinking about.” (I can already feel the goose bumps). Since any new design (or redesign) is considered an opportunity to ‘upgrade’, it is hard for businesses to understand that ‘enhancing’ it not necessarily a function of adding things but maybe removing things. Unless you focus on those things that customers really care about and need to be successful, callers will continue to hate the systems we design - no matter how ‘useful’ we consider them to be.

3. Lack of Sustained Execution

Most systems tend to be developed, rolled out, and then become static pieces of art - aside from the casual updates (e.g. changes in the hours of operation) or sporadic tunings (which tend to happen once a year). On the other hand, what makes Social Web applications so successful is the fact that they are in a continuous state of evolution, they keep changing and never stop getting better. As Joshua points out, “It’s too easy to fall into the desktop software mindset of build, release, and wait for the next cycle.”, but I truly agree with his comment about this being a mindset issue - “If you see it as an opportunity for continual improvement, your outlook will be more positive.”

4. Pointing the Finger when Missteps Happen

It may not be that apparent considering the current state of the speech industry, but reactions such as the SNL sketches, the Citi Simplicity campaign (”press 0″) and the GetHuman movements, provide hints that the consumers are starting to become much more vocal regarding their experiences and expectations regarding self-service ad automation in general. Therefore, we as “manager of these communities” must act accordingly, accept responsibility for our caller base and earn their trust and respect.

Any others I might have missed?

NPR has a very interesting that explores how human behavior isn’t limited to real world interactions but actually extends to others types of interactions, including virtual worlds such as Second Life.

Which makes me wonder… if it’s in our nature to balance things such as personal distance and eye contact in both the real and virtual world, what other ‘rules’ are we bringing in into our day to day interactions with the phone?

I know similar topics have been discussed previously in articles and books such as Clifford Nass’ “The Media Equation” , but it was fascinating to me to realize that those same behaviors aren’t exclusive to people-to-computer interactions but that also affect virtual representations of ourselves.

This of course explains why callers sometimes have such gut reactions to some of the designs and interactions out there - reactions that are hardwired in their systems or have been socially learned. And why when we violate some of those interaction conventions and real-world rules, it makes it psychologically uncomfortable for our callers.

Let’s just keep that in mind (and let’s remind our customers) the next time we model systems around real-world interactions.

It is very interesting to see how this new Web2.0 wave allows apparently disparate technologies to be merged together and implemented in radical new ways.

Robert Scoble recently covered how Nexidia is using phonetic search to index video and audio content which then can be searched. And not only that, but by having a textual representation of the content along with some indexing information (such as the position of a certain phrase within a video), they can seamlessly integrate Google AdWords into a viewer and present relevant ads based on the what’s currently being played or listened to.

You can either watch the video interviews provided by Scoble or play with the demo provided b Nexidia.

Now, if there are technologies that allow things such as this to happen, why hasn’t anybody explore its use in the field of self-service? Imagine this. You call into a company’s self service solution and can either be asked an open-ended questions (How may I help you?) or with a directed dialog interaction (Here’s what you can do…). In either instance, and without the need for Statistical Language Models (SLMs) or other advanced recognition techniques, you could be ‘listening’ in real time to what your callers are saying or requesting. Then, based on a pre-defined piece of text, keywords or concepts, you could in real-time drive the interaction by either using those phases as shortcuts, by offering intelligent menu choices based on what they say (not on what you’re offering), and being able to make your system a lot more dynamic by maybe integrating it with a live FAQ back-end or support system that based on things that are taking place in other contact points (fax, email, web, blogs, podcasts, video, etc.) can offer new content/solution over the phone.

Wouldn’t that be sweet?

In most conferences, events and training classes, one common argument is that Self-Service Systems and IVR would be much better if we as an industry were able to craft a set of best practices everyone would follow.

In fact, the “GetHuman” movement and its standard is an attempt to dictate how customer service phone systems and support should work.

I think we all agree on this, but I always like to hear other opinions about similar topics, I found an intriguing response in Shaun Smith’s entry on Best Practices and Customer Experience.

He points out that even though we always look at those companies that have great service and provide great experiences (Disney, Southwest Airlines, Ritz-Carlton) in an attempt to learn how they do it so we can do it too, that ‘me too’ strategy is pretty dangerous.

And I’ll argue that the same danger can be present in our industry and in VUI Design in general.

Think about it. When a new customer engages us into creating a new self-service solution, one of the main business drivers is to differentiate from the competition. “Strategy is about making a choice; of what to do, but event more importantly, what not to do. To attempt to copy other organizations runs the risk of your being second rate, at best and totally inappropriate at worst.”

If you look at the last great VUI design you came across, the one that left a memorable experience that maybe even made you recommend it to someone else, chances are it belonged to an organization that has a strong brand, offers distinctive experiences, attract enthusiastic users, and… has their own unique way of doing things.

These companies found that their approach to business is not the norm, they do unusual things that defy conventional wisdom.

I think the secret is that they didn’t focus on complying with certain standards or best practices, but they rather focused on differentiation and meeting the needs of their users (customers). Some CEO’s even said their success started the day they stopped following the market leader and started following their customers.

Wouldn’t it be refreshing to think about good VUI design in terms on how well it creates value for our users, on how it ensures that callers are successful, and not on how many multi-slot entries we have, on how clever our menu choices seem to be, or on how easy it is to talk to someone (when in fact, sometimes that’s not what our callers want)?

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.

A friend of mine sent me this, and I thought it was really funny. It seems IVRs are entering prime time television not only in the US (as seen in the “Saturday Night Live” sketches of Julie) but in other countries too. It is interesting how even though we all speak different languages, we always somehow manage to repeat the same mistakes in any language, don’t you think?

Unfortunately, the interaction isn’t that far off from some of the actual live calls I’ve heard from systems our there in productions - specially trying to avoid transferring the caller, but we’re all working on fixing that, right?

You can watch the video below, and if you don’t speak French, here’s a brief transcript of the interaction so you can read and weep:

• “Lady” calls in but person isn’t available (gets voicemail message)
• Attempts to leave voice message but system interrupts with “If you’re satisfied with your message, press 1.”
• Caller says she isn’t satisfied and again is interrupted by “To record it again, press 2.”
• Caller presses 2… and the advanced dialog begins… the system says “You’ve pressed 2. If you’re satisfied with choosing 2, press 1.”
• Caller presses 1, system says “You’ve pressed 1. Press 3 if you’ve chosen 1 because you’re satisifed with your message. Or 4 if you’ve chosen 1 because you’re satisfied with pressing 2 because you’re not satisfied with your message.”
• Caller hesitates to system helps with “Press 5 if you want 10 more seconds to press 3 because you want 2, or press 6 for 10 seconds to press 4 because you want 1 because you would like 2. Press 7 to start over. 8 to hear this again. Or 9 to not hear it anymore.”
• Caller presses 7 so system asks “Was that 9?”
• You get the picture…

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!