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.

The premise is definitively very interesting. What this Canadian start-up is attempting to do is to replicate the concept of bookmarking and deep linking (process of linking pages in the lower levels of a Web site from a home page - or other pages - to help search engines index them) so common these days on the web. What this means for a phone user is that they don’t need to get to the application’s “home page” (aka Main Menu) every time to then have to traverse the phone tree to reach a specific destination…

According to their founder’s pitch, the way it works is that you “bookmark” a spot deep inside a telephone’s system tree. To do this, you go to the Fonolo’s website, find the Company you need, review a transcription of their menu structure, find the spot you need and click on it. By doing that, they call the company for you, navigate the menu up to that specific spot and call you back so you can continue your transaction from that point on.

How do they know what systems look like? Well, as noted in the VoIP weblog, they seem to be using a combination of voice recognition and human editors to generate “maps” of the interactive voice response system.

Aside from the obvious privacy concerns a service like this might raise, the hottest one in my opinion is the service they refer to as “Intelligent Call History”. Since in reality all your calls start from their home page, they are attempting to become something like a Google of sorts for “phone sites”. What I mean by that is that they would keep track of all the interactions you’ve had with a certain company (regardless of the phone you used), along with the actual recordings of those conversations!

In the web world, we’re all familiar with how certain companies keep logs that track your web habits which could then be linked to your IP address. The biggest difference to me is that they mostly keep track of where you’ve been and where you’re going, but not of what’s happening when you are there… and in this case, since you’re using them as a bridge to connect to a Company, how can you be sure those recordings (which may contain account numbers, PINs, etc.) are kept safe and out of anybody’s reach?

Presumably the advantage of something like this is that in case of a dispute, you could play back a recording from the actual conversation and prove a certain transaction happened. But is this benefit really worth the risk? Particularly when it is known that once it becomes available to the public, it will be ad-supported.

On the other hand, they have also expressed that their ultimate goal is to craft partnerships with those companies Fonolo has mapped so that those companies can notify them “when they change or update their IVR” to the point where they hope companies will indeed send transcripts of their IVRs so they don’t have to be mapped anymore

Again, I definitively like the idea of empowering users and allowing them to accomplish their task in the most efficient way, but I think a system like this would be a much better fit for an actual device feature (similar to the GOOG411 dedicated button now present in some phones) - which you could turn on at the beginning of a call and stop once you reach the spot you want to “bookmark” so that in the future your phone would simply repeat the steps you followed and get you to that same spot. And of course, rather than finding more ways to patch user-unfriendly architectures, companies should be looking at fixing the root problem, which in the short term can be somewhat addressed via the deployment of more SayAnything/ SpeakFreely-type menus so callers can say what it is they need right at the beginning of an application…

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.

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…

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?

Interesting article

I certainly wish more companies would apply similar these same principles they apply to design new products and consumer electronics but in the context of new services and consumer support. For example, they talk about participants being able to call a toll-free number to share their emotions about a phone they may be testing, or they are asked to draw pictures representing their mood when holding a phone. Can you imagine having something like this for self-service applications - being able to leave a message about how you felt about your phone experience, or being able to ask callers to represent their mood when using the system via pictures?

I can definitively understand the business motivation to be able to come up with innovative devices that draw people to spend money on them. But I would love to see a similar “hit-driven” mentality when it comes to self-services, having designers being not only aware of the latest usability and human-factors strategies but also about popular culture trends and user’s subliminal needs. What will callers want or need 3 to 15 years from now?

I loved the phrase they used to explain how companies like Motorola are now “forced to give consumers what they want even before they know they want it.” When was the last time your UI design strived to do that?

And I also felt our industry got reflected in Nokia’s statement “Design used to be inconsequential: just make it pretty, make it sell”, which in our case could probably be rephrased as “Just make it comply with requirements, make it work.”