The Characters You Meet in VUI Design
As VUI designers, sometimes we hear snickers that we just don't do our jobs well. Sure, we realize applications that are difficult to navigate, flout conversational norms, blatantly disregard best practices, and show a lack of polite service behavior abound. But is this really the result of a clueless VUI designer or did the VUI designer find herself out-maneuvered, out-gunned, and out-politicked when it came time for stakeholder buy-in? Do we really not know how to design interfaces, or are we just lacking the skills to convince others that we know what were doing?
In a perfect world with a knowledgeable sales team, successful kick-off meetings, appropriate expectations, and a consensus among stakeholders, we could sit in a peaceful office somewhere, happily cranking out dialogue that is friendly, elegant, and customer-centric. But in the real world, we find ourselves dragged into meeting after meeting with concepts that we hold dear consistently up for debate by stakeholders, sales reps, engineers, project managers, and the person who makes the coffee all with profoundly strong and forcefully asserted opinions. In the face of multiple attackers, we are left to defend the customer experience with only a sharpened turn of phrase echoing in the breeze.
It doesn't have to be that way. Its time to stop lying awake every night haunted by the fact that countless hours of our work have resulted in a poor user experience, with only the disappointed echo of the customer made me do it as our justification. Its time to become our own best advocates, adopt new negotiation tactics, and help our development colleagues get on our bus. Its time we step up and demand better.
Project after project, were running into the same people, all with different job titles, control issues, and motivations. Knowing what makes them tick means we can use specific strategies to help us become more successful. Creating a VUI design is only the beginning of our work. The real skill is getting others to accept what we've created. Like dialogue design itself, acceptance is a matter of knowing with whom you're communicating, what their motivations are, and adjusting your strategy accordingly.
We've created eight personas that describe our favorite naysayers. Well introduce each and provide our best strategies for bringing them around to a more user-centric point of view.
¦ The Verbal Nitpicker edits dialogue with a free hand, demanding word changes often without any reason other than, "I think this sounds better." Without regard for the careful balance between information, pace, context, or user goals, he scrutinizes every syllable and word choice. He is often insistent with criticism, until the dialogue looks like a high school English teacher hatcheted it with a red pen. He may be a minimalist, and want to edit out filler phrases like first, next, and finally. Dialogue markers are seen as a waste of precious time. Or, he might be more of a poet and think the dialogue isn't caretaking enough: a quick and easy before I transfer you may become a rambling I promise I will get you to an operator soon, but before I do, I just need to collect three more pieces of information. It should be quick, so bear with me.
Strategies for dealing with the Verbal Nitpicker :
Explain the strategy behind the dialogue. Start early and make sure that he understands that the overall approach to the dialogue is more important than every word. People don't remember the specific details of a conversation, only the gist of it, even immediately afterward. Not breaking expectations about politeness is far more important than a microfocus on every word.
Don't give him the words on paper. Focus on tone and delivery, and use audio clips when possible. Present your dialogue in a carefully controlled setting, preferably through system-user conversations that show how the dialogue will work for specific callers. Explain that since a speech interface is auditory, he can provide more valuable feedback hearing the system and commenting on what stands out.
He wants to be involved. Often he does not feel like he is doing his job if he doesn't force you to change some things. Have acceptable alternate wording available, and then offer a choice. This allows him a feeling of power, decision-making responsibility, and ownership.
Leave your ego at the door. If Shakespeare had to get the VNs buy-in on Hamlet, our beloved Melancholy Dane would be That Sad Guy From Denmark.
¦ The Legal Eagle is the one to thank for Your call may be monitored or recorded for quality assurance. He is the natural predator of straightforward, to-the-point prompts that assertively state facts. Hes trained to see random lawsuits and protect the bottom line. After he has exercised his verbal acrobatics on your dialogue, something as simple as There are no open recalls on your vehicle becomes a shifty According to the information YOU provided, the current records accessed by the database indicate there are no active recalls at this time . Meaning is lost and time is wasted, all in an effort to avoid the slightest potential for litigation.
Strategies for dealing with the Legal Eagle:
He will often give you a marked-up script. Read it out loud at a meeting. We recommend you try to do it in one breath the comic relief of your struggle may flush out a potential ally, the person who laughs and says, "Well, THAT obviously wont work." Humor is useful, and LEs are an easy target.
Conduct usability testing and make sure you carefully collect user comprehension and perception data on unwieldy passages of Legalese. Present your findings to the project stakeholders and let them tell the legal department that only people who've blown 10 years of salary in law school have any clue what this IVR is saying. Executives can be your best allies.
Find out what the human operators say. Chances are, its straightforward. Suggest that if the agent can say it, so can you.
¦ The Legacy DTMFer has been with the company for 20 years. Most of his design comments begin with, "Well, Ive been doing this for 23 years, and." He will insist that callers prefer pressing buttons and will want long, detailed prompts inappropriate for speech systems. Hes skeptical about speech technology in general and insists that you have to slowly explain to users how to use a system. Instead of your simple high-level billing , hell spin around to the rest of the table and claim passionately that customers wont know to choose that unless it says Billing issues, such as payments, transfers, questions about your bill, or to speak to a billing specialist, press or say 1 . At some point he will suggest the compromise of press or say as a viable option on top-level dialogues. Most people around the table will think thats an amazingly intuitive idea. He also leans toward the terse and gruff approach to phrasing press this now , so trying to discuss issues of linguistic tone and helpfulness as an important component of customer service is a waste of time. When he pauses for breath and searches his pockets for an antacid, you will be slinking in the corner wondering what to do.
Strategies for dealing with the Legacy DTMFer:
Create comparative use cases to show alternative versions of the same interaction, rendered as DTMF and speech. Show the differences in wording, time to task completion, and tone, then let him decide which approach is more in line with the customer-service strategy. Usually its the one you wanted.
Remember that you are encroaching on his turf. Uttering the phrase "best practice" when hes 10 years out of date will only incur another round of "Ive been doing this for 30 years." Don't try to win the war of explanation; you've already lost if you re engaged in the battle.
Know all the reasons why press or say is problematic in top-level menus, but focus on it as an strategy. Agree to DTMF fall back but lead with speech prompts. You already know its a good practice and were planning on it anyway, but let the Legacy DTMFer think he invented this idea, and let him know that you admire his experience, and think its a great compromise.
¦ The Mindreader discards all scientific and usability study data as inapplicable to her customers. It doesn't matter if years of cognitive psychology studies show human beings can remember three, four, or six pieces of information; she will insist her customers are smarter and can recall 15 to 20. If you explain that hearing a plug for a Web site immediately after the greeting tends to annoy people, she will reply, "Oh, I know my customers, and they love to hear detailed, upfront messages about how they can save time by using a Web site." The Mindreader often takes lunch with the Legacy DTMFer and they both complain about hiring young people like you who clearly don't know anything about technology.
Strategies for dealing with the Mindreader:
Engage marketing and/or executives by showing them how the disputed dialogue will sound with and without the undesirable messaging. If the Mindreader thinks she knows the user group, then hopefully someone in marketing will have real market data that counters her assumptions. Better yet, let her sit in on a Q&A with call center reps.
Theres got to be someone else on the project whom the Mindreader trusts. Its your job to get that person to advocate for you. He can help convince the Mindreader that you need to conduct usability testing, reinforce the importance of your findings, and recommended design changes. Mindreaders usually trust the technical expert the most, so you need to make him your ally.
When a project descends into a he-said-she-said battle of opinions, the only way to resolve it is to collect real data from real people who don't know anything about the project, the back-end technology, or the internal politics of the company. Get usability testing done, even if its just a few people doing a couple of tasks, and make sure everyone knows the results. Even two to three well-chosen pieces of usability data can work wonders.
And lastly, try to avoid looking smug when the data support your point of view.
¦ The Technical Expert doesn't understand that designing a user-friendly, workable dialogue doesn't always follow the form interpretation algorithm. In his mind, the call flow should be scribbled down to minimize database dips, coding begins in earnest, and a couple of weeks before deployment, any chimpanzee should just write some prompts and plug in the recordings using the toolkit. He refuses to believe that dialogue and call flow are inextricably linked to human behavior and will want the dialogue designed to fit the code, rather than the code designed to run the dialogue. When pushed, he will start randomly flinging phrases like reusable assets, call routing matrices, and T1 lines to confuse the issue. When he gets a hold of your dialogue specification, hell want to know why every single transfer message isnt worded exactly the same, where the interdigittimeout is specified, and why you have a typo on page 162. If he gets really ticked, he might ask you to recite the latest VXML spec and, if you didn't happen to commit all 800 pages to memory, you'll hear a choking noise as he ambles back to his cube to read up on new approaches to database management.
Strategies for dealing with the Technical Expert:
Show no fear. Just remember that he respects expertise, and you need to demonstrate yours calmly and clearly. Help him see differences in dialogue design strategies and use cases are effective here and appeal to existing knowledge in linguistics and psychology to help bolster your perspective. Give him something fun to read, like any of Donald Normans books. You might just make a new friend.
If theres another thing he respects, its numbers. Make sure you have numbers to back up your design decisions. Better yet, give him numbers AND a video of people using (or not using) the application. You'd be surprised at how many TEs start singing with the choir when they see the real outcomes of their work.
Be willing to compromise, but also show how the dialogue design poses a technical challenge. Sure, your design might be harder to code than his simpler alternative, but thats why you have a Technical Expert of his caliber on this team. He got his reputation by being able to solve technical problems, so let him.
¦ The Human Factors Wannabe is a bookish, somewhat disempowered observer who feels maligned that his excellent, user-centered ideas are not trumpeted around the company. He knows all the latest jargon, tends to name-drop, and wants to be heralded as the person who saves the world from the horrible existing IVR. He is likely to send you a revision of the never-used IVR that he created in 1997. He usually has just enough out-of-date knowledge to challenge your every move, scoff loudly in meetings, and claim you re simply not doing enough for the customer experience. Hell want to debate phrasing issues with you and create mountains out of molehills, yet, hes likely to miss bigger, more pressing issues, like the fact that the companys entire approach to automated customer service is archaic and impossible to use. If you re lucky, he might have read a book on VUI design, but it probably came out in 1998.
Strategies for dealing with the Human Factors Wannabe:
HFWs have pretty good ideas, but lack the communication skills, position, or power to execute them. Engage this person, listen to what he has to say, and determine if his perspective supports yours. If so, encourage his voice in team meetings.
Let him help. Let him have his way on small issues of phrasing, even request he write some of the prompts if he wants to. You need to focus on the bigger, more critical issues like flow and overall organization of the interface.
He tends to respond better to "feeling" words, so tie in phrases that refer to the callers emotional state when explaining design decisions.
He wants to be recognized by the team as an expert. Have him do things on the project, then mention his accomplishments publicly. A little positive reinforcement goes a long way.
¦ The Speech Victim is usually a high-ranking executive who is not involved in the day-to-day aspects of the project. His version of testing goes something like this: How may I help you? You can say things like make a payment or check my bill , to which he flippantly
replies, "Purple basketballs." When he gets the appropriate no-match prompt, a resounding "AHA!" can be heard throughout the halls. You might even see a vein bulge on his neck as he exclaims, "I KNEW this speech stuff doesn't work! Call my directors!" You are then dragged into a meeting, where you are regaled with tales of all the times these talking systems did not work. These invariably involve a call when he was driving 60 miles an hour through freeway traffic with the windows rolled down and the radio on full blast, next to the airport, with a screaming baby in the backseat and his beloved, barking Schnauzer riding shotgun.
Strategies for dealing with the Speech Victim:
Always assume this person will surface at some point. Set up a plan ahead of time with the Technical Expert and your project manager.
Get the real audio data from his call. Understand that you may never have contact with him yourself, so prepare an easy-to-follow PowerPoint presentation that contrasts his 60-miles-an-hour-on-the-freeway-airport-radio-blasting audio to a typical utterance with a nice articulate person speaking on a quiet landline. In your presentation, explain that an agent receiving the same response to the same question would probably follow up with Pardon, what was that again? By playing the appropriate retry prompt, the system is doing exactly what a person would. And people have just as hard a time deciphering what a person is yelling into a cell phone on the freeway as the machine does.
Consider pre-empting him. Early on, create use cases that show errors made by the caller, the associated no-match or no-input message that followed, and an appropriate recovery strategy.
¦ The Bottom Liner wants to know what its going to cost and what the monetary benefits are. Phrases like "increased usability" and "better user experience" fall on deaf ears. At best, hell dismiss you as a hippie who deals in fluffy, subjective words and feelings instead of tangibles measured in dollars and cents. At worst, hell view you as a glorified business analyst using up budget and time on a less-than-optimally-efficient project, as someone who doesn't know anything about money.
Strategies for dealing with the Bottom Liner:
Only one: you absolutely MUST speak his language. If theres a debate over dialogue strategies, write use cases using both and show which one results in the shortest call duration, thereby resulting in cost savings. Multiply cost savings per call by the total number of calls to the application to really make him salivate. Know your stats, like the cost of keeping customers versus getting new ones; the cost of transferring people and savings provided by self-service, and target retention numbers, and be prepared to use them.
Of course, we all have our own personality quirks, and are probably more effective at negotiating with some of these folks than with others. Just as we adapt our dialogue strategy, manner, and intention in our systems, we need to do the same with our team communication skills. Inherent in our job description is negotiation, compromise, and goal-oriented conversation. The ability to connect with people, to show understanding and empathy, to adapt our language to deal with others desires and overcome their fearsapplied in our designs and to our team communicationswill allow us to deploy systems that we wont be embarrassed to say we created. The real benefit will be to our clients and everyone who uses a phone.
Alexandra Auckland and Melanie Polkosky are experienced VUI designers and consultants, having worked with numerous Fortune 500 clients to sell, design, build, and implement IVR applications. Prior to working in VUI design, Auckland was a professional voice coach, and Polkosky was a clinical speech-language pathologist.