Voice User Interface Design VUI

It seems the current issue of BusinessWeek is focusing on Customer Service Champs in 2008 and “Consumer Vigilantes“.

Therefore it isn’t surprising to seem them cover a little bit of the history of the GetHuman movement and its evolution from a simple IVR cheatsheet into a full movement with the goal of “convincing enterprises that providing high quality customer service and having satisfied customers costs much less than providing low quality customer service and having unsatisfied customers.”

Even though the tone of the article seems to be a little gloomy and critical about how “page views on the site have dwindled”, I would argue that page views and sign-ups for an audio icon are not necessarily a reflection of the level of interest or impact GetHuman and the standards they’ve proposed have had so far.

I think that even though the approach to promote the standards might not have been the best one, it definitively has had an impact on how designers think about customer interactions, how companies are much more aware of the impact of caller experience in automated systems, and has paved the way to get the worlds of consumers, businesses and designers talk the same language and agree on long-term goals.

The part where I think the standards got a little disconnected from the real world had to do with the fact that in other technologies, standards can work in a vacuum as long as implementers or partners agree on them. In our case, I think that the fact that they are so closely related to customer experience and caller satisfaction warrants a much closer analysis of those standards in the context of those same caller’s goals. For example, standard #6 reads: “Callers should not be forced to listen to long/verbose prompts.”, but without any context, it would be akin to promoting a web standard similar to “Users should not be forced to read long/verbose sections of text.”… well, what happens if I’m reviewing a prospectus or accessing a white paper? Would offering that service disqualify me from being standard-compliant?

Furthermore, I think the other reason it cannot survive as an independent standard is because users very seldom limit their interactions to a single interaction channel (telephone in this case) but attempt to use whatever channel is more convenient based on their situation, location and past history with the company (internet, phone, branch, email, fax, chat, etc.). Therefore standards should consider those other channels as well so that the original goal of providing high quality service and having satisfied users can truly be accomplished in the context of the entire customer service experience.

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

After catching-up on all the topics and discussions from the vuids group that came out around the Holiday season, the idea that seemed to kept coming up was that it’s still very hard (if not harder) for designers to get designs done right, mostly due to external reasons (things sold the wrong way, business requirements, picky customers, etc.) and particularly when businesses don’t want to pay attention to what designers have to say.

Furthermore, the idea of picking the *right* technology for the job (touchtone, speech, SLMs, or plain-old agents) is the right idea yet not widely supported (by sales people in particular).

Therefore I wanted to share with you this jewel from TED by David Pogue which I just recently ran across which reinforces the point that “simplicity sells”. Funny to think it’s a couple of years old, but keeps being as true now as it was back then. In particular, I loved the part about Palm having a “tap counter” to make sure no task required more than a limited number of taps on a Palm device, which makes me wonder if our projects wouldn’t benefit from having a “word counter”, a “choices counter” and a “menu levels counter”

Enjoy!

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.

That’s right. How many times have you been outside and saw one of those humongous ad displays telling you about the next great thing since sliced bread? Well, what if you could now interact with those displays, and not only that, but even be able to play with other bystanders!

I’ve seen similar things in shopping centers where an overhead projector displays ads on the floor with which kids can interact. For example, a sports brand may display a soccer ball within the projected image and kids start to kick the ball around the ad in an attempt to score a goal.

But this is the first time I’ve heard about someone taking that to the next level by targeting to adults and allowing them to interact with it using any cell phone!

Megaphone has created this innovative way to engage crowds and let them interact with advertisements. As I mentioned, all you need is a cell phone which then becomes a game controllers you can then use to shoot other players or fire weapons at space-alien attackers while seeing their own phone avatar along with those of other players. Some games are played with your telephone keypad while some others are controlled with your voice. Sweet!

As you can see in the videos below, the games have a certain ‘retro’ vibe which makes them very appealing and reflect the simplicity of the game, making it easy for anyone to join in.

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?

Whenever I visit an art museum and get exposed to various painting styles, I’ve got to admit I prefer Realism over other painting styles, especially those belonging to Surrealist or Abstract art movements. And I guess part of it is because with Realism, we all tend to converge on the meaning of an image and the qualities of the artists, whereas on other styles, both the meaning and interpretation of the piece are absolutely subjective and the beauty of it are in the eye of the beholder.

Reflecting upon those things, I ran across Mark Hurst’s Good Experience newsletter that talked something similar, but in the context of wine. He talked about how “the experience of drinking wine is determined less by the wine itself and more by the consumer’s own expectations for the wine.”

In particular, the thing that baffled me was the New Yorker article about the research done at the University of Bordeaux where participants provided opposite feedback for the exact same wine only because it had a different label, which created a very different set of expectations on them. Furthermore, in the second example, participants in Vegas not only had different expectations but actually showed that customers preferred a fake thing over a real one.

Which made me think about our reality in the world of VUI design and the expectations caller have when the reach a self-service system. Would we see similar responses if we were to simply change the label of our solutions? What would happen if we were to give callers a fake thing (automation) and call it real (agent)? Is part of our challenge as VUI designers to help morph the expectations callers bring to the call to something different, more advantageous for the actual experience?

Digging deeper on that last thought, I kept thinking about my recent experience with self-service solutions as well as feedback I received from friends, family and peers that have used speech recognition systems… I noticed there was a strong correlation between how “good” they felt the system was and the expectation they had when they picked up the phone in the first place.

For example, someone was having a technical issue during the early morning hours and needed help right away. They first attempted to solve it by themselves via manuals and web queries with little success. Therefore they had as a last resort the option of attempting to talk to someone (knowing that most likely they would get an “our offices are currently closed” type of message). In that scenario, being able to reach an automated system that was able to retrieve that customer’s information from the number they dialed from (ANI) and was able to provide step-by-step instructions on how to restore the system back to normal, yielded an “extraordinary experience” for that customer.

But those types of expectations come included with the caller and the context of the situation. So here’s the question again, is it possible to change those expectations on the fly, while a caller is interacting with the system? Are there other fields out there that may be already doing it from which we can learn? Advertising maybe?