Usability on wide and deep menus
Posted by: eolvera, in Usability, Information Architecture, Dialog Design
It seems one of the most frequent questions that come up when designing a new user interface is “how many options should appear on any given menu?” which depending on the answer is almost always followed by “how many levels down should the system have?”
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.