Voice User Interface Design VUI

Finally had a chance to look at this month’s cover article of the SpeechTEK magazine. What a joy! I was very pleased to see that once again, the topic of Translations (which I often refer to as “Transgressions”) comes up in an attempt to raise awareness about the implications of simply taking content in once language and doing a straight 1:1 translation without any consideration for cultural issues and linguistic nuances. As the author pointed out, translations are “a quick, cheap, lousy idea.” (well said!)

As the article points out, in the particular case of IVR systems there are various syntax and grammatical issues to consider as well as code implications and underlying logic divergences derived from those structural differences - it’s not just a matter of word order!

Furthermore, the author makes a really good point about the dual nature of IVR and Speech Recognition systems in the sense that we should not only be careful about what we say and how we say it (the outgoing activity) but also about the incoming activity – what callers say, how they say it, etc.

Along with the list of Tricks of the Trade provided, things such as the use of a native speaker for reviewing localized Dialog are of utmost importance.

Finally, one of the topics that often comes up when dealing with countries where more than one variety of the same language are spoken (for example, Spanish in the US), is the issue of which “version” of the language should be spoken so as to accommodate various countries of origin – normally referred to as “neutral Spanish”. I loved the definition they used because it captures the complexity of finding that middle ground while still taking into consideration the technical/financial implications and realities which we often face in our projects – “the neutral version of any accent is the version that offends the fewest people”

Happy Reading!

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 recently got a link from Amy Quinn pointing out an article entitled “101 Five-Minute Fixes to Incrementally Improve Your Web Site” provided by InsideCRM, and though it might be helpful to go over some of those points in the list and hence suggest “21 Quick Fixes” (granted they might take a little more than 5 minutes) that can be adapted and applied to Voice User Interfaces and Voice Applications:

Copywriting

1. Tell callers why they should perform a task. “People are trained to follow a request, as long as you give them a good reason to do it”. Therefore, put yourself in your caller’s shoes (or ears), and make sure you’re not only offering something of value to them, but that you’re clear in why they should go through it (e.g. shorter wait times, 24×7 availability, etc.)

2. Make the most highly trafficked menus easier to listen to. If your system contains menus that are too long and you can’t reduce the number of choices, think about grouping some of them or break the menu up so it’s easier to process in short term memory.

3. Make choices meaningful. Be sure to change any vague or cutesy menu options to something more up-front, meaningful, that callers can understand (no jargon please)

4. Stay consistent. Check your prompts and terminology for consistency, or else the experience will seem unstable, unprofessional or patchy.

5. Stay simple. You just can’t beat that. Granted some processes are complex by nature, that doesn’t mean they need to be complicated. Strive for clarity!

6. Avoid making hollow promises. Including those callers are taken for granted nowadays, such as pressing 0 and expecting to talk to an agent.

7. Be concise. ‘Nuff said.

8. Go with what works. And if you don’t know what works, ask your users – that’s why Usability was invented for in the first place!

Usability

9. Make navigation consistent. Listen to your users, understand how they think and what steps they need to follow to complete a task, and then stick to that flow.

10. Never ask for more information than you need. Related to #1, this includes only requesting relevant information at appropriate times (why ask for the last 4 of the SSN when all you want is the hours of operation?). “When you get greedy for data, you’ll turn off some visitors”.

11. Add a search box. Or in the case of VUI design, think about adding a SpeakFreely/SayAnything-type of implementation where callers can say what it is they need right at the beginning of the call.

12. Use plenty of contrast. In our case, we’re looking for ’sound contrast’. You’ll need to make sure you coach the voice talent properly so as to not only get a good sounding application but also intonations that convey the right message and elicit the right responses.

13. Test it on real users. Oh, if we could just make this a law…

Accessibility

14. Modify color. In our case, we’re looking for ’sound color’. This might include having multiple personas and voice ‘sets’ to account for playback speed and other traits that are necessary to support multiple caller’s ages, audible ranges, etc.

15. Identify the language. Explore the use of alternative DNIS numbers for each language so as to avoid requiring language menus (“For Spanish, press 2…”) in which case don’t forget to make one of them the default.

16. Supplement navigational aids. Explore the use of professionally generated earcons that not only serve as branding elements but also have an impact on application usability (for example, a quick tone preceding the playback of a confirmation number).

17. Define shortcuts. Take advantage of any Usability and Tuning findings you discover that might involve real users employing certain keywords/phrases as shortcuts often enough to justify adding them as ‘hidden shortcuts’

Design

18. Place important information “above the fold”. In our case, either at the beginning of a certain task (e.g. providing account balance before attempting a transfer), or at the end of a sentence so as to facility short term memory recall, particularly if the information provided is new to the caller. (e.g. “Your due date is May 15th.”)

19. Reduce choices. If your system contains menus with too many choices, reduce the number of choices to the very minimum necessary for callers to accomplish their task and maybe add a “something else” choice for everything else.

20. Nix banners. Which in our case might also include unwanted advertisements and legal disclaimers (“This call may be recorded for quality purposes.”) whenever possible.

21. Stay consistent. Check to make sure the design and prompt recordings are not only consistent throughout the entire experience but also consistent with the system persona and user profiles.

As if not enough discussion has been generated over this particular UI design tool on the VUIDs group, it seems the 37 signals post about how they don’t use Personas stirred yet another round of arguments on both their own site as well as in some other UI-related blogs such as Good Experience and The User Experience Soapbox.

I think they all provide a very interesting perspective and valid points both for and against the use of Personas (or Personae) as a design tool.

But for me, aside from it being just one more tool in our UI toolbox, the added extra business value that I find in them (which I didn’t see being brought up on those discussions) is how effective it is to help business owners and other business-side team members move away from thinking about “the user” in an abstract way.

In general, if you’re in the same room with five different people and you mention you want to do something to help improve the experience of their “users”, chances are each and every one of them will have a very different image in their head and idea of who this “user” is and what this “user” needs.

On the other hand, once all the information has been gathered and the right process has been followed to define a User Persona (or Archetype) for your system, then any future discussion takes a very different direction. You’ll notice how now new design decisions and arguments can be centered on your Persona.

It doesn’t have to be too complicated nor time consuming. For example, something as simple as defining a Natalie archetype might be enough: “Natalie is a real estate investor and has an ABC bank customer for about six years. She often calls her branch to get up to date information about interest rates and mortgage products. She normally calls from her home-office, so she’s in a quiet environment. She considers herself tech-savvy, so she likes automation, but time is precious to her, so if things aren’t working fast, she’d rather just talk to someone who can help her quickly.”

With this in hand, you’ll see how asking regular questions such as “how will the user be able to get her balance?” or “will the user need more information after a transaction?” turn into very relevant, in-context discussion starters such as “what’s the best way to offer Natalie the most up to date interest rates?” or “what information will Natalie need after choosing one of our mortgage products to make an investment decision?” respectively.

I understand the concern about using personas to replace talking to real people, but I like to think that they are not just the output of talking to real people, but a way for those people to keep “talking” for the duration of a project. So tell me, what do your users think?

(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.

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?

One very interesting trend that came up a handful of times during this year’s SpeechTEK East Conference was the use of Alternative A/B Call Flow designs, pushed by companies such as SpeechCycle and Google.

The basic premises of A/B Call Flow Design are that designs shouldn’t use a single path for all interactions, and that those paths should be driven by actual data.

And it definitively makes sense. Think about it. When you’re designing a call flow path, you’re basically implementing a version of all the assumptions that took place during the Context Gathering phase of your project. You gathered data, considered business requirements and user needs, monitored calls, and drafted what you considered to be the ideal design for that organization (which you hopefully also usability tested).

Unfortunately, those types of designs rely on data that could be coming from disparate systems, from existing designs (which we cannot guarantee are an accurate reflection of user’s behaviors), or sometimes are flat out missing. So what can we do?

The process is pretty straight forward. You create two or more alternate versions of a design (A and B), each using slight variants of prompting and/or call flow, which implement a metric tracking system that follows a call and assesses whether a certain call was successful or not (based on criteria such as caller-generated transfers, call length, etc.). Then, a randomization script receives all calls and routes callers through the alternate paths. Finally, the VUI designer analyzes the data and is able to conclude (with actual data and statistics) which of the various alternatives yields the best results… taking some of the faith out of the design phase.

For example, imagine you have a “Say Anything” or “Speak Freely” type of system in place (which uses Statistical Language Modeling - SLMs - to accurately route callers to specific destinations) and you’re wondering whether prefacing it with just a “How can I help you?” prompt will be enough for callers to understand what’s expected of them. Other alternatives of course include expanding that prompt to include a set of examples (sample phrases callers can say), a set of choices (options callers can choose from) or a combination of both. And on top of that, we could also be wondering what should be the appropriate number of examples and/or choices that we should be presenting. Pretty tough, right?

This type of strategy is also very helpful when dealing with Main Menus. Sometimes the Information Architecture of a system is pretty obvious, but sometimes it allows for alternate designs. For example, on a financial application, some callers think about their institutions in terms of the products they offer (checking, savings, loans, credit cards, etc.), while some others think about them in terms of the services they offer (getting balances, making payments, executing transfers, etc.). So again, we could implement two alternate versions of a main menu (each using a different focus) so that we could track the performance of each type in real time and then we would be able to identify the one that yields the best results (completion rates, call lengths, transfer volumes, etc.)

Up until now, most designs followed a “me too” strategy simply replicating what other systems out in the field were doing, and then having to wait until a full pilot analysis was completed before being able to assess the state of the system. But now, with A/B designs, systems themselves can provide the data we need to make those decisions, and in a way, even learn by themselves and self-tune the interaction using reinforced learning.

Have you tried something similar before? If so, have you find other types of uses for it? And what were your results?

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?

A common problem we always face is how to deal with Menu Choices… How many menus do I need? In which order should they be presented? Are the labels I’m using clear? Should I concentrate on actions callers can perform or objects they are looking for?

In particular, one that’s pretty hard to solve is the number of choices that should be offered at any time. Some developers stick to certain Human-factor derived rules such as the “5 choices maximum”. Others prefer to split them into layers so that you only offer two or three at a time, followed by the familiar “more choices” menu which then takes you to a second (or even third) set of choices. At any rate, you’ll notice there’s a common theme among all these choices: “How can I add more choices without hurting my callers too much?” (even if we don’t like to accept that’s what’s going on)

But a very intriguing question I normally have when adding a new choice is: “Are we adding more than we’re subtracting?”

It was interesting to see I’m not the only one with these types of questions. Gerry McGovern recently shared similar concerns in relationship with the internet and web applications. We are very familiar with this concept, particularly every time we ‘upgrade’ our computers or a particular application software - we know where things are, we know how to get what we want out of them, and then once we move up to an upgrade version, chances are we’re going to be welcomed by a new myriad of choices, different menus, and sometimes even different terminology for the same concepts we were already familiar with. Taken to the extreme, we run into situations like the one MS Office 2007 users are facing where interfaces are so different than it requires users to learn the mental model of the developer.

Now, taking that back to our VUI world, I’ll take one of McGovern’s examples which I think helps answer the question about the real value a choice adds.

If we were to have 100 units of “attention” we could use and we listen to 5 menu choices, it means we can give 20 units to each choice. If we were to add a new option, it would be like taking 4 units away from each of the other choices, or else you force the caller to spend more time processing the information and increasing the likelihood of them making a mistake or running into an error.

In other words, “Every time you add, you subtract attention.” says McGovern. And I’ve seen that in action both in production systems and in Usability tests: when menu choices exceed the attention capacity of a caller, there’s a point where they simply stop listening or give up.

Unfortunately, businesses don’t think that way (which make our job harder, but at the same time more important). For them, if they have 4 choices covering 80% of the calls (let’s say that gives them a value of 80, so 20 points each), and we add a fifth option that has an intrinsic value of 5 (lets assume it’s the reason for another 5% of the calls), they would argue we added value to the solution, which went up from having a value of 80 to 85.

However, what happens if