Keeping the User in Control
At SpeechTEK West in San Francisco last spring, a group of voice user interface designers participated in a workshop directed by James Larson of Larson Technical Services and Lizanne Kaiser of Genesys Telecommunications Laboratories. Participants developed recommendations for handling error messages in speech applications from four perspectives. This is the first in a series of four articles summarizing the recommendations reached by these experts. Contributors to this article were:
• Adam Elman, Tellme Networks, a Microsoft subsidiary;
• Matt Klee, Tellme Networks;
• Peter Leppik, Vocal Laboratories; and
• Matt Shomphe, Countrywide Home Loans.
Little in life is more frustrating than feeling out of control. Unfortunately, this sense is all too common when interacting with an interactive voice response (IVR) system. As voice user interface (VUI) designers, we seek a balance between supporting a caller’s need to accomplish some purpose or task and a business’ need to reduce the amount of time human agents spend on the phone helping callers. Many IVRs fail to maintain this balance, and the user feels as though she is being forced down an unwanted path.
This lack of perceived control can be seen clearly in the all-too-familiar term "Voicemail Jail." To overcome this, we should design systems that allow the users to establish control from the beginning of the call, and maintain that control until the end.
To feel in control, the user should perceive at every point in the interaction:
• that the system understands his intention (not simply what he says, but what he means);
• that the system is taking the correct steps to respond to his intentions and provide the expected level of service; and
• that when the system is not responding appropriately, he can change directions to get back on track.
Unless these conditions are met, the caller will feel out of control and will be much less likely to play along with the system. Rather, he will be spending his time looking for a way to escape.
Here are four basic design guidelines to give users a sense of control over an IVR application.
1. Get the user’s intention first.
Many IVRs attempt to authenticate a user or collect other information, such as customer type, before asking the user why he’s calling. If a user is calling a bank to find the nearest ATM, he knows that the bank doesn’t really need him to provide an account number. Forcing the user to provide unnecessary information not only wastes his time, it makes him feel that the system is controlling the interaction.
Instead, the early stages of the interaction should focus on understanding the caller’s intention. Once that has been established, the system can then request any necessary information in the context of responding to the caller’s intent.
2. Be clear about where the call is and where it is going.
The judicious use of landmarking and confirmation prompts gives the user a sense of context. For example, if the caller requests an agent, let her know that she will be transferred to a human, even if the application then attempts to partially automate the call. It can include a prompt like: OK. Before I transfer you to an agent, I just need a little more information to get you to the right place.
3. Don’t waste the caller’s time.
One of the main reasons users dislike interacting with automated systems is that they feel their time is wasted. They are forced to listen to lengthy prompts with lots of information that is irrelevant to the context of the call. Worse, callers anticipate that they will have to answer the same questions again when a human agent comes on the line.
For the former problem, the answer is simply to be succinct. Avoid unnecessary verbosity, in particular around landmarking and confirmations.
For the latter, IVRs should only ask for information that is absolutely necessary for the specific interaction. If a question doesn’t need an answer, either don’t ask it or at least let the user skip it.
Whenever possible, ensure that the infrastructure supports persisting data from the telephony environment to the agent, like a computer telephony interface (CTI) screen pop. If you don’t have CTI, look at other creative ways of persisting data. If you can’t, at least warn the caller that he might be asked to repeat some information later.
4. When bad stuff happens, fix it.
Inevitably, even the best VUI will have problem calls. Keeping the user in control when a problem occurs means first recognizing the miscue, and then resynchronizing the conversation so the system understands the user’s intention and communicates that to him.
Nothing makes a system seem more stupid than an apparently infinite loop of errors. The VUI can detect a disconnect between the user’s intention and system understanding using recognition-error counts, repeated disconfirmations, or even keywords indicating frustration. Once this is detected, the system must break the error cycle and provide an alternate path to the user.
Occasionally, the alternative path is straightforward, as in breaking a complex recognition into several simpler recognitions, or falling back from speech to touchtone input.
Sometimes, however, it might be better to offer an explicit escape hatch to resynchronize the conversation. There are three universal escape hatches that could be appropriate to offer in an error reprompt or after a disconfirmation:
• Go back: If the current interaction is a multistep process, the user could need to back up only a step or two to resynchronize. We have found that the Go back prompt is a very natural and effective command for this purpose.
• Start over: If the interaction is simple, or if the user finds herself down a bad path, the simplest solution might be to just start over from scratch, using Start over (or, in some cases, Main menu).
• Operator, for a quick opt-out to an agent: If the user hits a wall, the best thing to do is let him transfer to a live agent as quickly as possible. Once a user has reached a certain level of frustration, the likelihood that he will be satisfied through automation is virtually zero, so there’s no reason not to offer him an explicit opt-out.
In some cases, a context-sensitive escape hatch might be more appropriate. For example, after collecting data, a summary confirmation step can allow the user to change a specific piece of information, or everything, as in the dialogue presented below:
System: Great. To confirm, that’s two people from San Francisco, California, to New York’s Kennedy Airport leaving Monday, June 14th, and returning Saturday, June 20th. Is that right? Say yes or no.
User: No.
System: What do you want to change? You can say departure city, destination city, departure date, return date, or number of people.
User: It’s all wrong.
System: Sorry, I didn’t get that. Please say departure city, destination city, departure date, or number of people. You can also say all, or none.
Often, in an effort to lower costs by steering callers away from live agents, companies will insist on VUI designs that take control away from callers and force them through a particular path. Research has shown that forcing callers to use self-service dramatically increases their dissatisfaction and does little to reduce the likelihood that they will eventually talk to a human being.
By contrast, maintaining the users’ sense of control throughout an interaction will drastically reduce the most common frustrations with IVR systems and might actually encourage them to stay in self-service long enough to accomplish their goals.
Editor’s Note: In the next installment of this series, to be presented in the April issue, another team of VUI designers provides suggestions for moving the dialogue beyond the simple I’m sorry, I didn’t get that, noting that reprompts should correspond to the types of errors being generated.