Voice User Interface Designers Learn to Cope with Rejection
They are called in as experts in one portion of the application development process, to fill a crucial void that determines whether a project succeeds or fails.
Voice user interface (VUI) designers are hired guns whose work lets consumers initiate a service or complete a process using an IVR system. If a VUI leads to a poor experience, callers quickly ditch the system and form long-lasting negative impressions of the company. On the other hand, if customers have a good experience, they are more likely to reuse the VUI and, perhaps more important, be forgiving if they experience future system problems.
Despite their obvious impact, VUI designers regularly find themselves in a precarious situation. "For a variety of reasons, clients do not always follow our recommendations," admits Eduardo Olvera, senior user interface designer at Nuance Communications. Sometimes, the designer is brought into the project after key decisions about the user interface design have been made. In other cases, conflicting project goals, such as reducing expenses or driving additional sales, override design considerations.
So where can designers turn when their advice is ignored? First, they need to understand their place. Rarely do VUI designers drive the project; they usually complement it. "In the end, the customer gets what the customer wants. After all, they are paying the bills," explains Susan Hura, a principal at consulting firm SpeechUsability. However, identifying conflict early in development makes it more likely that differing opinions can be bridged.
In extreme cases, designers need to document what is happening so that if the project goes off the rails because the customer is dogmatic (and wrong), the designer will not get thrown under the bus.
Missing a Key Requirement
Problems can crop up as soon as a project kicks off. The first step is the requirements phase, which identifies the necessary attributes, capabilities, characteristics, and qualities the system must support to deliver the value and functionality desired by the user. A company broadly maps out how the IVR interacts with the user. This phase is divided into requirements elicitation (gathering, understanding, reviewing, and articulating the needs of the stakeholders), analysis (checking for consistency and completeness), specification (documenting requirements), and validation (ensuring the specified requirements are correct).
The designer might be excluded in this phase, and that can create problems. The team of business analysts putting together the requirements document might have only a cursory understanding of IVR system capabilities. To close the deal, salespeople sometimes gloss over system limitations. In certain cases, the designer is viewed simply as a conduit, someone brought in later to map and translate the requirements list into the finished application.
Consequently, a gap appears between what the customers expect and what designers can produce. "Sometimes, the industry sets unrealistic expectations for what capabilities speech systems can deliver," says Rex Stringham, president and CEO at consultancy Enterprise Integration Group (EIG). "When we meet customers initially, we often work to scale back their expectations so everyone can focus on delivering a reasonable set of system enhancements."
Checking the Wish List
In such cases, the VUI designer frequently acts as a sanity check and clarifies what is possible and what is not. While this step is necessary, it can produce hurt feelings. "The customer may begin with 50 items on a wish list but be told that only half are realistic," Nuance's Olvera says. "After that discussion, they will often feel cheated, which is not the ideal way to begin a project."
Traditionally, companies went through the requirements phase without VUI designer input, and gaps between expectations and deliverables usually emerged. But recently, the process has been changing. "Increasingly, designers are being involved right at the start of the requirements-gathering phase," says Melanie Polkosky, a human factors psychologist at IBM. Companies have come to appreciate the role that they play and solicit their input more aggressively than they did in the past.
Also, operating in this fashion is more cost-effective than the old approach. The customer must spend a lot more money to fix a problem late in the application development process than early in it. Estimates run from a tenfold to a one-hundredfold difference in expenses, depending on the scope of the project and when the change is made.
Stringham goes a step further, advising VUI designers also to get involved in the later phases, such as testing, where traditionally they have been out of the loop.
Dealing with Change
However, having the VUI designer more fully involved in the project is not a panacea. "Change is inevitable," Polkosky says. "Once we create a design, we know that there will be some alterations." Sometimes, they are minor; other times they are major. They can occur at the start of the project or arise near the end.
These changes often are caused by differing vantage points. A project team consists of individuals with different backgrounds, experiences, and ideas. The infrastructure team will focus on the modularity of the system and its compatibility with the existing infrastructure. The VUI designer concentrates on the end user's perspective, focusing on the interface's usability, intuitiveness, naturalness, simplicity, effectiveness, and robustness. The marketing group is interested in promoting key messages and driving sales opportunities. Sometimes, individuals focus largely on their own areas of interest to the exclusion of the other elements, and these different viewpoints often lead to conflict.
Stay Off My Turf
Another hurdle to clear is the inevitable turf wars. "As an outsider, it can be difficult to determine what political factors are in play with each project," Polkosky notes. Companies operate like families. Theoretically, everyone should get along, but friction happens frequently. In some cases, a business unit might try to impede or even torpedo a project to enhance its own position.
Another problem can occur when a project progresses smoothly until a senior manager intervenes to demand dramatic and inappropriate design changes. "One senior executive wanted the voice changed because it sounded like his ex-wife," Stringham notes. In those cases, the executive is typically a senior manager, largely out of the development loop, who becomes involved only as the project nears the finish line. Such late-game changes are costly and all too common.
Identifying possible communication problems is easy, but solving them is much more difficult. As trite as it might sound, communication is key. The designer needs to ensure that everyone understands how and why the project is moving in a certain direction.
Yours to Review
One way to improve communication is to hold periodic design reviews. "Having regular meetings where stakeholders can comment on the design helps to ensure that the final product will eventually look like what everyone envisioned," Nuance's Olvera says.
While there is no timetable for holding these meetings, the more involved users are, the less likely it becomes that problems will arise.
Programming technology has evolved so it is possible for a designer to develop prototypes quickly that illustrate where the project is headed. As a result, designs can be reviewed every few weeks or every month, rather than at multimonth milestones.
However, taking this step creates challenges. Communicating more with stakeholders could invoke more questions and invite unnecessary, maybe even harmful, changes from people who aren't VUI experts. "It can be difficult to sort through the wishes of 50 people who have wildly diverging opinions about how a prompt should be designed," Polkosky says. So, the design reviews can slow development time and delay delivery. Consequently, the designer must clearly outline what is happening, why the extra steps are necessary, and the potential impact of additional meetings on cost and delivery date.
Forcing Calls to the IVR
Problems also arise when the stakeholders have strong, intuitive opinions about how the system should be designed. One often hotly contested point is whether to force callers to the IVR. Typically, VUI designers lobby for a "customer first" approach, which gives each caller a choice of starting with the IVR or an agent. "Managers' focus is on using the system to cut costs, which means offloading calls from agents to the IVR," Hura says.
For example, a well-known mobile phone company publishes a number for customers who have questions on their bills, but those customers are not given the option of transferring the call to an agent to discuss the problem.
In such cases, the customer must be convinced to change his outlook. "It is very important that VUI designers do more than present opinions; they need to have empirical data that backs up their position," Olvera says.
To collect that information, designers must conduct usability tests at various points during development. The designers can rely on post-call surveys and questionnaires to collect data on callers' views about a VUI.
While frequently viewed as "fuzzy" subjective metrics, the reports can be validated if a designer asks the right questions of a statistically significant number of properly chosen individuals. Typically, the tests start with ease-of-use. This characteristic is composed of many measurements, including navigation, intelligibility, effectiveness, error recovery, the IVR's ability to satisfy callers' needs, and the availability of support help.
From such studies, VUI designers have determined that forcing users to the IVR is not the best service option. Doing so does not significantly increase the IVR utilization rate because customers who do not like self-service find a way to reach agents no matter how difficult companies make it for them. Consumers might start screaming the word "agent&" repeatedly or uttering nastier words to get the system's attention.
In addition, this design approach often produces customer dissatisfaction that can damage the company. The root of this problem is a faulty starting point.
Managers need to understand that the IVR was designed to maximize automation, not to provide outstanding customer experiences. These systems work best in two areas: laying options to route calls to the best agent group and self-service to a closed group of frequent callers. Automating beyond this level often can be counterproductive, leading to poor customer service and less-than-expected uptake. It also can be a prime reason that so many customers hate IVRs.
The Price You Pay
Facing such facts, management teams are starting to accept that they no longer can get away with poorly designed IVRs. However, proper design involves trade-offs, with costs as the central one.
In some cases, an IVR makes the customer do too much work, such as entering a 12- to 18-digit account number and then repeating it again to an agent. But fixing the problem can require a lot of integration.
"The customer data may be stored in a database but, unfortunately, not in the way that the IVR system can understand and work with it," Stringham says.
In addition to translating the information, the system might need to be enhanced, for instance by connecting the VUI application to other systems using computer telephony integration software. This requires an up-front investment that a company might not be able to make, especially in the current economic climate.
Another area in which business units and VUI designers might clash is options offered. Companies should not build their scripts based on corporate priorities; development should rely on an assessment of customer needs and wants. The marketing department might want to give customers many options to increase the chances of upselling, but experience has shown that excessive choice confuses and frustrates customers, who usually do not remember all of the possibilities and quickly default to agents. Consequently, designers recommend that companies limit the options to three or four, even if that means that all of the possibilities cannot be presented via the IVR.
The same adage holds true for nesting. Conventional wisdom says it should be limited to two or, at most, three levels within an application. Again, that might mean a company will not be able to offer all the options, but it increases the chances that the options given will be used.
Clearly, communicating research findings does not always eliminate contention. There are times when the sides will simply disagree. Here, delivering the message becomes tricky. "Companies do not like being told that their design will not work," Hura says.
The same holds true for VUI designers, whose hard work frequently is spurned. While it is the designer's responsibility to inform clients of the potential damage of design flaws to the business, the customer ultimately has the choice to either accept or reject the advice.
Please Show Me the Door
So, how can designers protect themselves if a disagreement arises? "In a couple of cases, I've told clients that they should fire me: 'Why pay me when you are not going to listen to anything that I say?'" Stringham says. In those cases, the candor caught the attention of the customer, who changed his outlook and started listening to him.
But the blunt approach does not always work. When it doesn't, designers could draft a document stating that the client is going against their advice. "Email is a great way of establishing an audit trail," Olvera says. "In some cases, the customer may think twice before hitting the Send button and acknowledging that they are not following your advice."
In addition to documenting the disagreement, Olvera often continues to develop his own version of the VUI. "If the client interface bombs, say in the testing phase, I can quickly provide them with an alternative," he says.
But if the designer is eventually proven right, there is no reason to gloat. "Even when the designer is proven right, so what?" Stringham asks. "The end goal is not to win a game of right versus wrong but to help the client build the most effective user interface possible. If that occurs, everybody wins."
Paul Korzeniowski is a freelance writer who specializes in technology issues. His work has appeared in numerous publications, including The Boston Business Journal, Entrepreneur, and Newsweek. He is based in Sudbury, Mass., and can be reached at paulkorzen@aol.com.