Choose broad over deep for menu structure
Or maybe more accurately, don’t be afraid to go broad when that looks to be the best decision.
A long-standing concept in menu design has been that due to memory limitations, menus should be short, no more than five items at very most. However, callers are rarely asked to remember all the menu options, simply to select the right one. Making sure that the options are clear and distinct is more important than the number of options. At each option, the caller needs to process the choice and either discard it, store it as a possibility, or select it as a definite match. With this approach, they should rarely have to remember more than two options as they listen to the list. To enable callers to process each option as it’s presented, there has to be a sizeable pause between options, between 500 and 750ms. (See section on pauses). However, if a menu has three or fewer options, the caller can do all the processing at the end rather than between options.
Additionally, there has been a lot of research conducted since 1997 contrasting broad and deep menu structures that unequivocally favors broad.
Let’s look at a couple of examples. Say there are seven functions in an IVR. There are several ways to structure them.
Assuming the seven items are clear, distinct, and disparate, broad is the way to go. Two levels with more options is harder to navigate (see research below), and random grouping is just plain hard for callers to figure out at all.
The last one is a special case. Sometimes options truly fit well under a category. For instance, say your functionality includes these items:
In this case, a main menu option of “billing questions” with a submenu might make perfect sense. It would somewhat depend on how many and what other options the system encompassed. In this situation, the deep menu structure appears more like a follow up question than a second layer of menu.
However, when creating categories which lead to submenus, the category name must fit all the items in the category, and the category name should be clear and easily understandable. On occasion designers will be tempted to write prompts such as
* For payment arrangements, check balances, or to make a payment, say “billing.”
This is definitely not a good idea. Cognitively speaking, the task becomes more difficult as the caller must remember what they want to do and then at the end of the sentence, understand that they have to say a specific keyword associated with that task. If options cannot be neatly categorized under a few clear and coherent words, it is better to not categorize them at all.
A key piece of information to consider is the desirability of each option, i.e. the frequency with which callers will choose this information. This information may be available from earlier IVRs or from call center data. If the data shows that “check balance” is the #1 most favored choice in the IVR, especially if it is by a large margin, the designer should resist the temptation to neatly put it in the “billing questions” submenu, because that would force the majority of your callers to navigate an additional step. Instead, “check balance” should be placed front and center on the first menu, with the potential to nest the other “billing questions” options under a different keyword. Note that in this case, the specific item should always be placed before the more general item to prevent the caller from choosing the more general item when they want the more specific item.
Deep menus get into trouble in two situations. The first is where the list is simply cut in half and tied together with a “more options.” This leads callers to hunt for what they want. Can it work? Yes, but it takes longer and has no benefit. The exception to this is where there are more than nine options when using DTMF as either the initial input mode or as an option on reprompts. In this case, you either have to go to two digit entries or employ “more options.” The second trouble situation is where a super-category is forced onto a group of options unnaturally. This ends up violating the clear and distinct rule for menu options, forcing callers to guess if it’s the right place.
Use “Help Me With Something Else” in place of “More Options”
HMWSE is an acronym for “help me with something else.” When you need to go deep, it is better to use this sort of phrase in a menu (or a variant thereof) instead of the more frequently over-used “more options.”
Hunter (2009) reports a quasi-experiment where they report that “many of those who used “more options” seemed to be exhibiting surfing behavior triggered by that phrase. That is, they wanted to hear and think about all possible choices before committing to one because “more options” seemed to mean “more options that you might want to hear before you make a decision”. This frequently led, though, to failures in the menus as callers encountered cognitive load problems having to hold all the choices and their possible meanings in mind. Callers who heard and used HMWSE, however, did not encounter nearly the same number of problems. They were not surfing but rather, and this is the key point, they were listening to and then rejecting previously heard choices when they said HMWSE… Callers clearly preferred not to surf, but to have a way to eliminate choices.
“Help me with something else” allowed them to hear, absorb, then discard choices they did not consider valid and specify to the system that new choices should be presented.
Failing menu:
Winning menu:
Use HMWSE consistently Whatever phrase you use, use it consistently. There are systems in existence that look like this:
This is disconcerting to the caller. They learn that HMWSE means they get more choices, so when they employ it a second time that's what they expect. Then it turns out to mean something different. The next time they call, they may be trying to remember what's going to happen. Maybe they know that what they want is there, and they're willing to look a bit. Maybe they don't want an agent. Or maybe they do and can't remember the “magic” place to say HMWSE to get to the agent. Keep the usage consistent.
As noted above, most early auditory menu design guidelines suggested a limit of four to five options per menu (Gardner-Bonneau, 1992; Gould, Boies, Levy, Richards, & Schoonard, 1987; Marics & Engelbeck, 1997; Schumacher, Hardzinski, & Schwartz, 1995; Voice Messaging User Interface Forum, 1990), a recommendation carried forward into current SUI design by many practitioners and researchers (Balentine & Morgan, 2001; Cohen, Giangola, & Balogh, 2004; Suhm, 2008, Wilkie, McInnes, Jack & Littlewood, 2007). The cited rationale for this limit is generally Miller’s famous (1956) paper about the magic number 7±2, part of which described experiments demonstrating that people have trouble remembering more than about 7 (plus or minus 2) items at a time due to limits in human working memory (Baddeley & Hitch, 1974). There is a potential tradeoff here, however, because for a given total number of options, restricting the number of options per menu necessarily leads to a deeper rather than a broader menu structure and, as recent research has shown, cognitive loads associated with menu navigation can be more problematic than those associated with selecting an option from a list.
Starting in 1997, a number of research studies have indicated that the practice of restricting the number of options in auditory menus is not necessarily best practice and, in fact, may be more of a misguideline (Commarford, Lewis, Al-Awar Smither & Gentzler, 2008; Huguenard, Lurch, Junker, Patz, & Kass, 1997; Hura, 2010; Suhm, Freeman, and Getty, 2001; Virzi & Huitema, 1997, Wolters, Georgila, Moore, Logie, MacPherson, & Watson, 2009).
Commarford et al. (2008) provided a detailed cognitive analysis of selection from an auditory menu that showed that, at least theoretically, auditory menus could be of almost infinite length (also see Hura, 2010 – “My Big Fat Main Menu”). Basically, callers do not memorize the options in an auditory menu – instead, they come into the task with a goal in mind (one mental chunk) and listen to the options, comparing them with the goal (one more mental chunk) and until they hear an option that is a strong enough match to the goal that they decide to select it, they hold in memory the best option so far (one more mental chunk) – for a total of three chunks of memory at any given time, regardless of the length of the menu.
In an experiment testing their model, Commarford et al. (2008) had participants with high and low working memory capacity (WMC) complete tasks using deep and broad auditory menu structures. They found that it took participants in the deep condition significantly longer to complete the tasks, and those participants also had significantly lower task completion rates and poorer satisfaction ratings. Participants with higher WMC completed significantly more tasks. The most important finding was an interaction between menu structure and WMC for task completion time. Specifically, participants with high- and low-WMC completed tasks at about the same rate when using the broad version (both groups relatively and about equally quick), but high-WMC participants were significantly faster than low-WMC participants when using the deep version (both groups relatively slow, but the low-WMC group much slower than the high-WMC group, by about 30 seconds on average). The data indicated that the design intended to help people with low-WMC – the deep menu design with fewer options per menu but more structure – actually made the tasks more difficult.
“Note that it is the designer's role to determine how best to allow users access to a specified set of options. Although it is an important factor, menu length is not the only factor. It is also important for designers to provide unambiguous menu labels and to place menu items into logical groups to meet user expectations and avoid confusion. If the items fall nicely into groups of four or fewer, it is reasonable to organize them in this manner. The IVR design question under consideration (whether long menus have user performance advantages compared with sets of shorter menus) becomes critical when more than a few items are relevant (potentially useful) at a particular point in the user interface flow.” (Commarford et al., 2008, p. 78)
Baddeley, A. D., & Hitch, G. (1974). Is working memory still working? American Psychologist, 56, 851-864.
Balentine, B., & Morgan, D. P. (2001). How to build a speech recognition application: A style guide for telephony dialogues, 2nd edition. San Ramon, CA: EIG Press.
Cohen, M. H., Giangola, J. P., & Balogh, J. (2004). Voice user interface design. Boston, MA: Addison-Wesley.
Commarford, P. M., Lewis, J. R., Al-Awar Smither, J. & Gentzler, M. D. (2008). A comparison of broad versus deep auditory menu structures. Human Factors, 50(1), 77-89.
Gardner-Bonneau, D. J. (1992). Human factors in interactive voice response applications: “Common sense” is an uncommon commodity. Journal of the American Voice I/O Society, 12, 1-12.
Gardner-Bonneau, D. (1999). Guidelines for speech-enabled IVR application design. In D. Gardner-Bonneau (Ed.), Human factors and voice interactive systems (pp. 147-162). Boston, MA: Kluwer Academic Publishers.
Gould, J. D., Boies, S. J., Levy, S., Richards, J. T., & Schoonard, J. (1987). The 1984 Olympics message system: A test of behavioral principles of system design. Communications of the ACM, 30, 758-569.
Huguenard, B. R., Lurch, F. J., Junker, B. W., Patz, R. J., & Kass, R. E. (1997). Working-memory failure in phone-based interaction. ACM Transactions on Computer-Human Interaction, 4(2), 67–102.
Hura, S. L. (2010). My big fat main menu: The case for strategically breaking the rules. In W. Meisel (Ed.), Speech in the User Interface: Lessons from Experience (pp 113-116). Victoria, Canada: TMA Associates.
Marics, M. A., & Engelbeck, G. (1997). Designing voice menu applications for telephones. In M. Helander, T. K. Landauer, & P. Prabhu (Eds.), Handbook of human-computer interaction, 2nd edition (pp. 1085-1102). Amsterdam, Netherlands: Elsevier.
Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. The Psychological Review, 63, 81-97.
Schumacher, R. M., Jr., Hardzinski, M. L., & Schwartz, A. L. (1995). Increasing the usability of interactive voice response systems: Research and guidelines for phone-based interfaces. Human Factors, 37, 251–264.
Suhm, B. (2008). IVR usability engineering using guidelines and analyses of end-to-end calls. In D. Gardner-Bonneau & H. E. Blanchard (Eds.), Human factors and voice interactive systems, 2nd edition (pp. 1-41). New York, NY: Springer.
Suhm, B., Freeman, B., & Getty, D. (2001). Curing the menu blues in touch-tone voice interfaces. In Proceedings of CHI 2001 (pp. 131-132). The Hague, Netherlands: ACM.
Virzi, R. A., & Huitema, J. S. (1997). Telephone-based menus: Evidence that broader is better than deeper. In Proceedings of the Human Factors and Ergonomics Society 41st Annual Meeting (pp. 315-319). Santa Monica, CA: Human Factors and Ergonomics Society.
Voice Messaging User Interface Forum. (1990). Specification document. Cedar Knolls, NJ: Probe Research.
Wilkie, J., McInnes, F., Jack, M. A., & Littlewood, P. (2007). Hidden menu options in automated human-computer telephone dialogues: Dissonance in the user’s mental model. Behaviour & Information Technology, 26(6), 517-534.
Wolters, M., Georgila, K., Moore, J. D., Logie, R. H., MacPherson, S. E., & Watson, M. (2009). Reducing working memory load in spoken dialogue systems. Interacting with Computers, 21, 276-287.