Voice User Interface Design VUI

I normally get my fair share of laughs (and tears) from listening to user call recordings and their experiences while using automated systems. But a friend of mine just sent me one from a user interacting with a call center agent.

We all know that the use of jargon and technical terminology can cause confusion on the user’s mind, but this is one of those rare cases where the problem comes from the branding decisions the company made.

To be honest with you, at first I though it was a prank call, but then over the course of the call you can hear traffic noise on the background (the user seems to have been calling from a public phone), and even some side-speech towards the end, so I think this was indeed a real caller with real concerns and confusion.

Just a little bit of background first. The name of the company is Telcel, and they are one of the largest cell phone service providers in Mexico, and as most service providers in the US, they also provide pre-paid plan alternatives. Just like AT&T has branded such plans as ” GoPhone“, in this case they opted for the name “Amigo”, which when translated literally means “Friend”, and that’s where the confusion started…

Disclaimer: If you speak Spanish, I suggest listening to the whole call first. Otherwise, simply scroll down and read the a translated transcription of some interaction snippets that are a good testament of what can go wrong when you have confusing product names.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

Priceless conversation points:

[User] “When I want to make a call, it tells me that my Amigo’s balance has been used-up. But I want to know about my balance, not my friend’s balance”
[Agent] (you can almost hear her laughing her head off)
[User] “I’m not interested in knowing if my friend has a balance, I want to know mine”

At that point, the agent kindly explains to the user that if she’s consulting the balance from her phone, then that means the balance she is hearing belongs to her, and that “Amigo” is simply the name of the service.

Nevertheless, the user continues:

“It also tells me that I can add $30 of airtime with an Amigo. So, do I have to give $30 to my friend to do so?”

Amazing, isn’t it? Well, aside from the funny aspects of it, the other part that I noticed is that even though the agent understood the situation and could probably tell that this user is struggling with the concepts, she doesn’t adapt her conversation to the current situation and sticks to scripted messages, full of more branded terms and jargon such as “to make a deposit you’ll require an electronic record or re-charge card”, “you will need to visit a location to buy an Amigo card to enter it into your phone, scratching the access code and dialing *333″

In my last post I talked about the elements that all recovery strategies should have, but in this case, even though the agent explained the situation and provided a solution, I think she left the empathy out of the question, probably leaving our “Amiga” even more confused.

Error recovery strategies and the verbiage around them has always been a hot topic of debate. We’ve all heard the classical “I’m sorry I didn’t hear you.” and “I’m sorry I didn’t understand you.” messages that are normally implemented as global prefixes to further attempts to help users get back on track. Some other designers prefer to eliminate this generic approach and opt instead for a more context-sensitive alternative, where based on the possible cause of error, you could very well eliminate them completely and simply attempt to reprompt the user in a more natural way, with maybe a slight change in intonation to convey the meaning of “Hello, are you listening to me?” in a subtle way.

In regards to the content of the error messages themselves, we’ve all heard that they should not simply be repetitions of what the user has already heard, but rather slightly different variations based on the context and possible cause of the problem in the first place, so as to try to help them recover: is it due to a noisy environment? is the user providing me more information than I’m requesting? are they struggling to find it? do they need more time? are they getting confused by what I’m asking?, etc.

Of course, errors are nothing new and are particularly prevalent in the software and web world, where the value of the message and its ability to help users recover is very often dubious (or flat out ridiculous), resulting in bad user experiences. Some examples:

“Unknown Error -1″

“Keyboard error (press F1 to resume)”

“Wrong parameter”

“An unexpected error occurred, because an error of type – 110 occurred.”

“It is not necessary to dial 0 after the country code for this country.” (If they know that, why not simply recognize it, remove/ignore the 0 and move on?)

Some others here and here.

With that in mind, I have to say I found it very refreshing when my Firefox browser recently crashed and I was presented with the following message:

I found a few interesting things about it that made me think about my own error prompts:

1. It’s unexpected - talk about user expectations. You know having an error (or crashing in this case) is not fun. Yet the unexpected style distracts you and in my case made me feel a little better about the situation (ok, ok, I’ll admit it, it made me smile)
2. Even though it had a funny side, it was still useful. It clearly states what the problem was in terms I understand (my windows and tabs), plus it gives me a possible reason for the problem which might help me avoid the problem in the future (a recent web page)
3. It provides solutions on how to fix it

Reduce the negative impact of an error + clear description of error + clear explanation of the possible cause + alternatives to solve it. When was the last time your error messages achieved all these goals?

Wow, I didn’t realize how long it’s been since my last post. I guess the good news is that it has been because I’ve been really busy, which for you means new and very interesting stuff is coming soon with regards to VUI design in even wider (and more recent) contexts such as vehicles, multimodality, iPhones, Blackberries, etc.

It’s great to be back!

As you know, I enjoy looking at other fields that might have design elements that could be leveraged in a speech and multimodal world.

My latest discovery was the film “Objectified” by Gary Hustwit. Even though the documentary is centered around the topic of Industrial Design and the process by which well known products are designed, created and injected into the marketplace, there are some great quotes by various designers that I couldn’t help but feel compelled to share with you and analyze in an attempt to find a way to apply them to our field. With so many quotes, I though this might be better off divided in parts so people can add comments and share their own insights and experiences. Let’s get started:

“What we really need to do to design is look at the extremes – the weakest, with arthritis, the athlete, the strongest, the fastest – because if we understand what the extremes are, the middle will take care of itself.” — Dan Formosa, Design and Research, Smart Design

Wow, what a way to start this topic! After readings this one, I couldn’t help but feel a little guilty about perpetuating the common design approach of the 80-20 rule. We try to capture what 20% of the population which will use 80% of the features might do, add support for a few other common “corner cases”, and ignore the really obscure and unlikely scenarios altogether. This point definitively made me wonder what if… what if we were to do it backwards, design by looking at those extremes - the distracted caller, the multitasking mom, the user that requires extra time to process the information or respond - and letting the middle take care of itself.

Case in point, the creation of the Oxo kitchenware, a peeler originally designed for people with arthritis that turned out to be more comfortable and easier to use for everyone!

“What we’re really always looking for whenever we design are ways we can improve the way people do things or improve their daily life… without them really even knowing, ever thinking about it.” — Davin Stowell, CEO & Founder, Smart Design

Another quote from Smart Design, but this time addressing the reasons behind our designs. How often are we really looking for ways in which we can improve how people do things or improve their lives? How often can we articulate this need and help evaluate it in the context of other seemingly more important needs such as completion rates, retention and automation? Can we really tell we designed something that not only solved someone’s issue or allowed them to complete their task but that in fact had a positive impact on them without them even knowing? Quite a challenge (and intrinsic motivator for me)!

“Good design should be innovative. Good design should make a product useful. Good design is aesthetic design. Good design will make a product understandable. Good design is honest. Good design is unobtrusive. Good design is long-lived. Good design is consistent in every detail. Good design is environmentally friendly. Good design is as little design as possible.” — Dieter Rams, Former Design Director, Braun

I think Mr. Rams said it perfectly. Seeing what goes on inside the minds of product creators behind brands like Braun and their philosophy definitively makes me appreciate the responsibility of a designer.

That’s it for part 1. Stay tuned for more quotes and nuggets of wisdom. And if you get a chance, watch the movie, you won’t regret it (and your users will appreciate it)!

During any Requirement’s Gathering process, one of the hardest yet most critical steps involves finding out the features that will be offered to the users. Figuring out the final set normally involves talking to agents, listening to the different business units, looking at statistics, etc.

Furthermore, if the customer is migrating from an existing system to a new one, part of the process also involves reevaluating the set of features currently being offered to determine which ones should be migrated and which ones should be eliminated for good (which very often becomes a challenge by itself since customers tend to feel that by doing so, they are “loosing” functionality)

Some of the tools available to us include performing a Usability test on an existing system, doing a benchmark analysis to compare features offered by competitors, looking at usage data to determine the frequency of usage of each existing feature, or setting up focus groups or customer surveys to explore the likely usage of new features.

So yes, there are way to figure out how often they might use a certain feature or what they might think about it, but how do you gauge how deeply your users care about those features?

Well, while watching a recent Burger King stunt (an interesting mix of market research and marketing) in which they made one of their US branches a “Whooper Free Zone”, and recorded via hidden cameras the reactions of their customers upon being told that they were no longer serving Whooper sandwiches (see video below).

This stunt made me think about a tool that designers don’t use very often: Subtraction.

By that I mean that very often we run complex studies and champion-challenger scenarios (aka A-B designs) to figure out what the best combination of items might be, or what the impact of adding one more choice will have on a user base. But how often do you test the impact of removing a choice both from a performance as well as from an emotional perspective? (and no, I’m not talking about those bad designs where options are so buried down or words are so poorly chosen that it’s almost impossible for users to find what they need or realize what they need is in front of their eyes (or ears).

So, next time you’re thinking about your users and the options they need, consider subtraction as one more tool in your ever-growing UI toolkit. And if you’ve used before, I’d be very interested in knowing what your results were.