Voice User Interface Design VUI

It seems one of the most frequent questions that come up when designing a new user interface is “how many options should appear on any given menu?” which depending on the answer is almost always followed by “how many levels down should the system have?”

And believe me, neither one has an easy or absolute response. As witnessed by some of the heated debates on the VUIDs list, the old standing guideline of “five options or less” was recently put to the test when Patrick Commarford and James Lewis from IBM published the article entitled “A Comparison of Broad Verses Deep Auditory Menu Structure” where the results seem to indicate that when comparing broad vs. deep menu designs, giving callers a single menu with many options (providing touchtone fallback) yields better results than using fewer options supported by submenus.

Aside from all the points, concerns, comments and objections raised by both the authors, the VUI community and other blogs, in my opinion I think it’s going to be really hard to reach a consensus if the main focus of the discussion if to agree on whether *5* is the right number of choices or not. The problem I see with trying to find that ‘ideal’ number is that a number by itself doesn’t mean anything. In this case, I think the devil is in the *context*.

In other words, any attempt to generalize what a good design should look like without taking into consideration the context of the application is not very responsible. We all know there are many factors that need to be taken into account when designing any system: caller’s age, demographics, type of application, caller’s objectives, business goals, etc.

Furthermore, when evaluating possible menu choices, the frequency with which each choice is needed and used by callers should not only drive their position within the menu but also the decision of whether or not the option should be in that menu in the first place (for example, if the top 3 choices on a menu are used 45%, 31% and 20% of the time respectively, then adding one more choices that’s only used 1% of the time should not be considered – in fact those calls are likely to be better handled by agents in the first place).
When all those factors are added to the mix, then an appropriate design *strategy* can be conceived.

For example, when thinking about the context of an application, imagine a system asking callers to choose a bird species – “And which type of bird is circling around you: dendrocygna, gelochelidon, herpethotheres, or tachycineta?”. In that scenario, unless you’re a birdwatcher, you’re likely to be overwhelmed even after hearing only 3 choices. The counterpart of course would be to ask for something so common and known that the number of choices in itself wouldn’t make a difference – “And which planet are you calling from: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune or Pluto?”

I definitively believe the industry should strive to find more answers to long standing questions, particularly when those responses can be backed up by real world data, but in this case, I think that unfortunately the answer to the question whether to go broad or deep on menus still is… it depends.

(I found this great article by Jared M. Spool) and decided to do an adaptation)

From observation and analysis, it seems teams who focus on the long term objectives of a project and an organization are far more likely to create designs that really pay off for the organization, whereas short-term vision teams end up not only not meeting the caller’s expectations, but often having to revisit the design and redo most of the work later on.

It is important to understand that the right approach to any Redesign involves turning the system into a living, breathing entity that evolves over time and grows with the caller’s and organization’s needs.

Here are seven essential long-term components to reach a successful phone system redesign project:

1. Make Sure You Have A Vision

This can be as simple as to look five or ten years into the future and ask the question, “What will calling our system be like on that date? What experience will the user have?” Team members from the best organizations have a consistent, clear idea what the user’s experience will be like in the future. Such a vision helps drive the design as well as any future changes/enhancements (“will this change get us closer to that vision?”).

It’s critical the vision not focus on future technology but instead on future experience. What are the steps in today’s process that makes things cumbersome or frustrating? How could the experience become more delightful?

2. Spend Time With Your Users

To successfully redesign (and to design for that matter), you need to be in close contact with the source – your users. You need to know who is using your system and what they are doing with it. You need to know what works and doesn’t work for them.

Based on the number of new implementations and changes happening out there, it seems many companies finally understand the importance of the telephone channel as a critical touch point with their customers. Unfortunately, even though some of those systems are getting major face lifts (heard any new “please listen carefully as our options have recently changed” recently?), most of the time decisions are made without even looking or listening to their users.

When preparing for a redesign of any system, teams should not only focus on what the new design should do but should also spend the same amount of time listening to real caller interactions with the existing design as well as sitting down with call center agents.

3. Reduce Risk By Working In Little Bits

Going back to thinking about design as a never-ending, always-improving process, the most successful teams keep their projects small. They don’t attempt to redesign everything in a single launch; instead, they work on one small section at a time.

Otherwise, you end up with complexity at all angles: the scope of functionality is larger, the number of stakeholders is larger (each with their own concerns), the number of archetypes the team is designing for is larger, more compromises are made, and the risk is much higher. If things don’t go as planned (as it often happens), it’s a huge problem for everyone, often with more visibility in the organization than the team would like.

Teams that only focus on a small portion of the application at a time reduce all those factors and risks while being able to concentrate on those critical areas that will make or break the design. Plus of course, reducing scope and concentrating on the most used features yield much better ROI numbers and timeframes.

4. Have the Right Skills Internally

Here recommendations might slightly different from what a regular web project might require. Even though on the web the best teams are less likely to hire outsiders to do their designs, building the right speech and VUI skills in-house is not only hard and too specialized, but may get in the way of a successful redesign. Nevertheless, since the idea is to have a design that evolved over time, it is up to the company to maintain, change, update and enhance the application as user’s needs change.

Therefore here the suggestion would be to have a dedicated in-house team that would work side-by-side with someone with experience in these types of systems so they can learn not only the intricacies of the design but also the reasoning and the strategy behind it (which will also help them become advocates of it and defenders of the user experience). That way, external resources can be later on used as mentors or as a way to make larger changes faster.

5. Think ‘Standards’

The VoiceXML and SRGS standards are the successful teams’ best friends. Careful application of the standards can dramatically shorten the time it takes to make changes down the road, as well as to simplify the integration of third party components and technologies.

Even if an original application didn’t start out as standard-compliant system, it’s worth the effort of slowly converting it. As functions/modules/flows are redesigned (in little bits, remember), changing them over to be standards-compliant is an effective approach. Every new redesigned area helps improve the team’s skills in using standards, thereby making the next section even easier to convert over.

6. Have a Plan for Change

Aside from having clear implementation and maintenance plans in place (system architecture, internal processes, etc.), it is critical to also plan for how the users will experience the change. Will they just call in one day to find an entire new experience or will the change slowly happen over time, almost imperceptibly? Will they be notified in advance of what the new system is prepared to do for them? Are all other contact points (web, branches, etc.) ready to support the cross-channel interactions that will be generated by the new system? Will the agents be prepared to handle the temporary increase in the number of questions and issues that often arise as soon as a new system is implemented? (and no, asking callers to “please listen carefully as our options have recently changed” doesn’t count as a plan)

For example, one interesting approach some companies take on the web is to slowly convert users over to a new version of a system by offering the new options while still allowing users to continue to use the old functionality/version for a while (this may be particularly critical for caller populations with a wide gap between infrequent callers and expert users, specially if moving from a DTMF system to speech). That way companies can assess the risk of changing the functionality out from under these users versus the cost of supporting both interfaces.

7. Understand the Internal Processes

Unfortunately, just as it happens on the web, many teams approach the redesign process much like they’d approach the design of a brochure or a monthly statement. Designing either one has the advantage that, at some point, it is printed and delivered. Once that happens, it can’t be changed — it’s done. The only thing is to start over with a new one.

The problem of course is that if you think you can think about a new design, implement it, then pay attention to other business, not giving the system any further attention, you’ll be in trouble.

The most successful teams consider, in the planning stages of the project, what the long-term internal processes will be for updating/enhancing the system after the design changes (due to new user’s needs or business requirements). How will they add new functionality? When do they remove low usage flows? Who will edit prompts before they go live? Who will review changes? Who will decide about changes to the user’s experience?

Understanding how the organization will handle the ongoing system changes shortens the time it takes to make improvements, reducing the need for a risky major relaunches (or sometimes even worse – pulling out the new system and bringing back the old one).

Conclusion

Careful consideration of long-term factors dramatically increases the odds a team will produce ongoing results that have considerable business impact. Teams ignoring these long-term components may get a new design launched, but will likely find themselves reliving the difficult experience again in just a few months.

I had a very interesting experience recently. I was at a customer’s site performing some on-site multi-modal usability testing that involved participants who could perform some of their day-to-day operations via a palm-based device using the keyboard, the device keys, the stylus, or of course, good old speech recognition.

But where things got really interesting was when we just arrived to the city. We were staying close to the city’s downtown but were totally new to the area. After driving around for about half an hour, we were really hungry, it was getting late, and we were supposed to have a meeting in an hour to finalize the details for the next day’s sessions.

Therefore we each pulled out or cell phones/palm devices and attempted to find a restaurant close by… the testers became participants themselves…

First of all, we attempted to use the web browser capabilities of one device, went to the mobile version of Google maps and searched for an Italian restaurant around the city’s downtown. After a couple of minutes of painfully slow interactions, we found out that the interface wasn’t particularly intuitive, the search results started to appear all the way down the page making it seem as if the results page was empty, some of the links ended up in 404 error pages, and at the end of the day, all we were able to get was a collection of restaurants with an address but no phone numbers. So, for someone who’s driving around, you can imagine that having a physical address is not particularly useful.

After that, we decided to drop the web and attempt to use speech recognition. For that, I attempted to use the “Restaurants” feature of Tellme, but after getting to the main menu and saying “Restaurants”, it took me to the Restaurant Reviews section of their portal - which sounded promising if I could find a restaurant close by as well as some sort of review of it. From there, it asked me for a city and state which I provided, but then was presented with a message saying they were only collection reviews for the Bay Area.

At that point, we had lost another 20 minutes trying to find a restaurant using mobile applications with very little success, which really made me thought about the importance of understanding how will callers use our designs and the context in which they will be making their calls. On top of that, it also made me think about some of the reasons why mobile applications may not be gaining the acceptance we would expect, and why simply providing mobile access to the web may not be the real solution for on-the-road self-service solutions.

But don’t worry, we actually managed to get a good Italian meal and still made it on time for our meeting. We simply opted for Plan C… stop and ask for directions.

How many times have you been frustrated with a telephone or customer service experience? Some people opt for making their feelings public, and hence we often find videos and recordings of those experiences out in the media. Some others (myself included) like to keep them as “war-stories” that can then be shared during parties or presented at conferences.

But we know that even if those experiences make it back to the companies, chances are improving them is not one of their priorities, and if they are, sometimes any *fixes* are implemented based on their interpretation of what the problem is and what the solution might be (“Please listen careful as our options have recently changed…”).

So here’s an idea. I found out about a Dutch web site called RedesignMe that is applying the concept of “crowdsourcing” to refine and revise product designs of mass-produced consumer goods. They believe that most products can always benefit from at least a little bit of improvement. So what I’m suggesting is expanding that concept to include not only products but services as well.

They propose submitting a photo or video of a product along with a description of what the frustrated user thinks needs redesigning. So for our exercise, I would love to expand that to include submitting a recording of a bad self-service interaction or customer service experience along with any design suggestions for redesigning and improving the experience.

Users and VUI designers could then rate each other’s submissions and add other comments or suggestions, and why not, involve the companies affected which could in return sponsor these efforts and offer award prizes for the best (and sound) design suggestions.

Hey, if companies are using crowdsourcing to solve problems and do corporate R&D, I definitively think our industry could benefit from a similar practice. What do you think?

Considering the latest advancements and the impact of social media in our environment, I think it would make sense to borrow a page from social design and re-think who should be the center or “pivot” of our designs.

As Joshua points out in his blog, social software has changed the focus of most web applications from a thread-centered approach (the way Usenet was setup and how most Forums work so that each new thread was assigned a specific topic under which the discussion took place) to a people-centered design (the way MySpace, Ryze, LinkedIn, Friendster, and others work where the individual becomes the focal point of all interactions which then spread throughout that individual’s network of friends.

From a VUI perspective, I think there are some lessons that can be learned and applied to application design. In particular I think the point about how if we live our daily lives with ourselves as the center it would also make sense for the applications around us to behave the same way makes total sense in the context of self-service.

We all know the drill: design tends to be driven by all sorts of requirements which tend to yield solutions that are business-rule-driven, ROI-driven, containment-driven, call-length-driven and from time to time, user-driven (even though I’m glad to report that tendency seems to be changing).

But to me, user-driven is not the same as people-centered. On one hand, applications can certainly be designed around user’s needs and offer things that most users want. But on the other hand, in a true step towards personalization, designs could certainly be centered on people: who they are, what they like, how they interact, what they need, etc. at a very individual level in some areas, but yet connected to that individual’s network of friends, peers, family, and acquaintances.

And as we know, once a different “pivot” is selected during the definition of an organizational scheme, the entire interaction, steps needed and flow are likely to change dramatically.

For example, what would a financial system sound like with people as the pivot point? Is there a “shared object“ in our systems around which people would like to connect?

As promised, here’s a copy of my presentation from this year’s SpeechTEK in New York: “Customers Request the Darndest Things - 10 Challenges for VUI Designers”

Description: Business owners have business goals, objectives, and requirements. Designers bring experience and advocate user needs throughout the design process. So how can we create outstanding experiences when objectives may seem to clash or customers have preconceptions about “how the system should work”? Explore some common challenges, understand the real issues behind resistance, and discover how to focus instead on successful systems.

Thoughts?

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?

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)?