The Customer Service Survey

How to Design a Phone Menu

by Peter Leppik on Wed, 2008-03-26 01:00

The conventional wisdom for decades has been that the ideal phone menu (aka IVR tree, aka callflow) should have no more than five options at each level. Any more than that, it was thought, would overtax the short term memory of the caller and lead to confusion and poor experiences.

Never mind the clearly observable fact that menus designed according to this rule of thumb still led to confusion and poor experiences.

Broad vs. Deep

As far as I know, however, nobody had ever experimentally tested the question of how broad (=lots of choices at each level) or deep (=multiple levels and submenus) a design should be for a given application. Until now.

A recent article in the journal Human Factors, A Comparison of Broad Verses Deep Auditory Menu Structure, by Patrick Commarford and James Lewis (both of IBM) et al. tackles the question of broad vs. deep menus head-on and comes up with the surprising result that (at least for the application they tested) it works better to give callers a single menu with lots of options than to give callers fewer options in each menu but have submenus..

In other words, the "no more than five options" rule of thumb is wrong.

The particular application Commarford and Lewis used for this experiment is navigating e-mail through a speech application. They identified 11 different functions (Next, Previous, Delete, Reply, etc.), and built a "Broad" and a "Deep" version of the e-mail system. The "Broad" menu provided all options in a single menu, and the "Deep" version offered four top-level choices (Listen, Respond, Distribution, and Details) with the 11 options contained in the four top-level choices.

There were some design oddities about the "Deep" menus: for example, the "Delete" function was under the "Respond" menu (I can easily write a whole blog entry about the uniquely user-centric design process which led to this, ahem, unique design decision). In the final analysis, though, I think it's fair and reasonable to conclude that for this application a broad design is probably superior to a deep design, even though that leads to more than five choices in a single menu.

What Does It Mean

Some people may read this result to mean "make the menu as flat as possible," presumably by putting every option into one single uber-menu, but I think what it really means is "there's nothing magical about five menu options." There will always be a design decision about how broad or deep to make a tree, unless the system has few enough choices to put in a single menu. If the IVR needs to route the call among hundreds of different destinations or provide several dozen functions, a single menu will simply be unwieldy (of course, one thing to look at carefully in those situations is whether the total number of functions or destinations can be consolidated).

The key to usability is making sure that the menu choices are obvious (which may require including some choices in more than one menu, if they don't fit cleanly in one place), and that the caller's time and mental effort is respected. That means striking a balance between broad and deep, and the right balance will be different in every situation.

The real lesson of this research is that real-world usability testing is likely to show that general rules of thumb break down when applied to a specific design. At the end of the day, usability testing is critical to making sure that the design is right.

Sorry...This form is closed to new submissions.