Voice User Interface Design VUI

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.

How good is automation when it only works for part of the process? That’s what I often wondered while traveling since in many occasions I’ve found myself trying to use technology only to find out it didn’t save me from having to get in line at the airport. For example, sometimes you try to check-in online but get a message about having to stop by the counter to get your final seat assignment (aka someone overbooked the flight and will scramble at the gate to get you in). In other cases, you get an electronic version of the boarding pass yet have to go to a counter to check-in baggage.

Therefore you can imagine how happy I was when I read about Continental offering a real electronic check-in option, without the paper trail. Basically you get the equivalent of a boarding pass in the form of a two-dimensional encrypted bar code that gate agents and security personnel can simply scan.

Now, if they could just link that same code with an RFID tag attached to my luggage, I could also skip that lost luggage line…

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?