Insight from Walt Tetschner

Have been engaged in a constructive email back and forth with Walt Tetschner. It started out nicely enough with him sending me a compliment about a piece I had recently published in TMCnet titled Treat Human Humanely and They Might Just Like IVR, a gesture I appreciated very much.

In the compliment, however, I detected what I thought was a bit condescension from Walt in him saying that he was glad to see that I had "found religion" by championing good VUI design. Needless to say, I pointed out to Walt that I had been engaged in championing good VUI design in my writings and in practice most of my professional life, etc., that it was strange that he would be glad to see me champion good VUI when the gethuman project had only bare bones advice in the web site about good VUI, etc., and the exchange went downhill from there for a few rounds.

But the back and forth took a sudden constructive turn when we started talking about the reasons why VUIs out there are so awful. My contention was that there are not enough skilled people out there that know how to do good VUI and that the vast majority of projects are badly managed. Walt however pointed out that even when good designers are engaged, the end result is often still awful. And he pointed to the attitude of call center managers who view callers as the enemy and who communicate such an attitude, subtly or otherwise, to everyone around them, including the VUI designer, who may very well come to the project wanting to produce the best interface ever, but then gets hammered and demoralized into accepting various mutilations of their design to the point where he/she no longer cares as long as they get paid and they can move on....

The insight is interesting and I need to think about it carefully. I have interacted with enough call center managers to grant that the proposition has merit, but I need to think more about whether the main cause is really about call center manager attitude, and if so, what that means in terms of developing a reform strategy....

Tips for effective menu design: Part III

9. Avoid mixing voice and DTMF menu choices

If your application is voice enabled, avoid cramming your menu prompts with instructions on how to pick menu items by voice and by DTMF. Avoid, for instance, wordings such as, “You can say ‘check balance’ or press 1, ‘open account’ or press 2, or ‘transfer funds’ or press 3.” Instead, first offer the leaner voice-only menu, “You can say, ‘check balance’, ‘open account’, or ‘transfer funds’,” and only if the users seems to have trouble with it, revert to the mixed prompt, “You can say ‘check balance’ or press 1, ‘open account’ or press 2, or ‘transfer funds’ or press 3.”

10. Use the same part of speech/clausal form when listing menu options

Bad prompt:

System: You can say, “Balance,” “Open,” or “Transfer.”

Good prompt:

System: You can say, “Check balance,” “Open account,” or “Transfer funds.”

11. Keep you menus consistent with one another

For example: in the opening menu, you ask the user to indicate whether or not they are a registered customer and then you branch off accordingly. Make sure that after the user indicates that they are a registered customer, none of the sub-menus offers options that apply only to non-registered customers (e.g., “To speak with one of our agents about becoming a registered customer, press “3”).

12. Let users ask, “What are my choices?”

At any point in the call, the user should be able to ask, “What are my choices.” In response, the system should respond by, first, positioning the user in the menu tree, and then listing the menu items that the user can select from.

User: What are my choices?

System: We were transferring funds. I need to know which account you would like to transfer funds from? You can say, “Checking,” “Savings,” or “Money Market.”

Tips for effective menu design: Part II

4. Use the construct, “You can say….”

If your application is speech-enabled, use the construct, “You can say….” to list the menu options.

Example:

System: You can say, “Books,” “Magazines,” or “Newspapers.”

5. Avoid the construct, “For X, say X, for Y, say Y, For Z, say Z.”

Simply rewrite the menu prompt as, “You can say, X, Y, or Z”. In cases where you can’t find the X, Y, or Z wordings that will accurately convey the meaning of the options, then use the construct “To A, say X, To B, say Y, To C, say Z,” whet “To A” would briefly explain what the option means.

Example:

System: To get your current balance, say, “Check balance,” to open a new account, say, “Open account,” to transfer funds from one account to another, say, “Transfer funds.”

6. Don’t use, “Please select from the following options”

A tired phrase that needs to be retired.

7. Never allow holes in your DTMF choices

We say that a menu has a hole if the options presented are not sequential. A menu that offers the user the option to press “1,” “2,” or “4,” has a hole. A menu that offers the options, “1,” “2,” and “3,” does not.

8. Mark position in the menu tree

A simple, “Main menu,” played prior to listing the menu items will reduce user confusion as to “where” they are in the dialog. The menu position marking becomes even more important as the user is led deeper into the menu tree. When you are leading a user down a menu path, list a menu header whenever you traverse a path and then list the sub-menu options. In case of a no-input or a no-match, then list the full path prior to replaying the menu prompt.

Example:

System: Main menu: you can say, “Check balance,” “Withdraw funds,” or “Transfer funds.”

User: Transfer funds.

System: Transferring funds. Which account do you want to transfer funds from? You can say, “Checking,” “Savings,” or “Money Market.”

User: Savings.

System: Transferring funds from Savings.

9. Avoid mixing voice and DTMF menu choices

If your application is voice enabled, avoid cramming your menu prompts with instructions on how to pick menu items by voice and by DTMF. Avoid, for instance, wordings such as, “You can say ‘check balance’ or press 1, ‘open account’ or press 2, or ‘transfer funds’ or press 3.” Instead, first offer the leaner voice-only menu, “You can say, ‘check balance’, ‘open account’, or ‘transfer funds’,” and only if the users seems to have trouble with it, revert to the mixed prompt, “You can say ‘check balance’ or press 1, ‘open account’ or press 2, or ‘transfer funds’ or press 3.”

Tips for effective menu design: Part I

Primitive a mechanism as they may be, menus remain the most effective way to elicit information from users. The system offers a list of options, the user picks what they want, and the system moves on to the next step. Nothing could be more straightforward. And yet, one can easily design a difficult to use menu unless some basic principles are observed.

In the next few posts, I list 16 guidelines that should help you design usable menus.

***

1. Present the most requested items first

Not all menu items are created equal. If you know which items are requested most frequently, place those items at the head of the menu list.

2. Keep the menu list to 4 items or less

Because of the invisible nature of VUIs, try to keep your menus to four items or less. In case you need to present the user with more than four items, split the list into two, with the first list presenting the user with the items they are most likely to request, and access to the second list offered as the last option.

3 Keep the menu depth to 3 or less

People hate deep menus. They are exasperated by them. And the deeper the menu, the stronger the feeling that they are being led into a blind alley, with little hope to get to where they want to go. If you can’t keep your men depth to 3 or less, go back to the drawing board and see if you can’t consolidate some of those tree branches.