Do more item choices in menus decrease usability? Many people would answer "Yes" and be correct, in my opinion. Yet how do we deal with too many choices for Web surfers? Do we actually reduce them, or do we try to organize them in to manageable stages? An accepted strategy in human-interface usability is limiting the number of any given set of choices. This strategy, which uses the rule "seven, plus or minus two," is often applied to Web site navigation, for example, keeping any given menu to a short list of items, somewhere around seven items. Although I have applied this strategy, and was happy with any given menu (set of choices), I still commonly felt overwhelmed by the number of choices in the overall site navigation. I think, maybe, I have just found a clue as to why.

Watch video

A co-worker recently sent me a video link to a lecture by Barry Shwartz at Swarthmore College, Too Many Choices: Who Suffers and Why. The lecture is almost an hour long, but it is well worth watching. Get some snacks, watch the video, and come back. At least watch the video; it's well worth your time.

Ultimately, Barry Shwartz's point, and I think he's correct, is that many choices do not increase satisfaction. Give people hundreds of choices for TVs, careers, whatever, and they will not be happier, even if they happened to get better results, because the cost of making all those choices and the cost of doubt (did I make the right choice?) increases as well, thereby substracting from satisfaction with the end result.

A common task with Web site navigation is to organize dozens, or hundreds, of pages into a logical navigation system. My strategy has been to follow the number seven rule, which to keep any set of navigation menu items to around seven, plus or minus two. This method of tackling problem often results in one of two types of menus: 1) a nested tree menu that expands and collapses; or 2) a flyout menu similar to software application toolbars. Sometimes these menus work very well and make sense. Othertimes, they don't make sense. But why?

An example of when the menus don't work is when we use them try to reduce confusion among too many choices. Categorizing a large number of choices, of course, does nothing to reduce the large number of choices. So if you have too many choices does categorizing help? Put another way: if you have too many choices, then you probably have too many choices. It makes sense, now, but I didn't think of it that way before seeing Barry Shwartz's lecture.

Designers have control over menus types, the number of items per menu, and how menus look and feel. But that control does not necessarily give designers the tactics to create more usable site navigation. I always assumed it did, until now.

The Perfect Navigation?

A good, typical example is an intranet site with a documentation section that had over a hundred pieces of content, a mix of manuals, checklists, and how-tos. The site used a single page for it's documentation page, with an alphabetical list of all documentation. For people who knew the titles they were looking for (for example, the people who managed the site) this made sense and was extremely easy to use. But for their customers, the titles were full of insider nomenclature, which made finding the right documentation less than obvious in many cases. Adding a search feature was not an option, because the documentation were all PDFs and the intranet's search engine could not handle PDFs. And while later on search was added for PDFs, the documents still needed to be browsable. So the question was: How could the documentation be easier to browse?

Organize By User Type?

My first idea was to create a page for each type of user and only add links relevant to that type of user. This tactic reduced the number of links per page for each type of user and worked only fairly well and not for that long. The trouble was that the documents could not all be clearly divided by user type. It wasn't that much of an issue at first, but as people came to expect their page to have all their relevant documents, each page came to include almost all the documents! The documentation itself was not written in such a way to support user types. This was not obvious to me, because I didn't write the documentation and the people who did agreed early on that my plan should work. But it didn't. The number of links (choices) per page grew over time because nearly every document applied, in some part, to every user.

Organize Hierarchically?

As the number of links per page grew, the person in charge of maintaining the pages decided to start organizing the links hierarchically on each page. She used a nested tree menu that I created. Surely this would help users find the right documents, by presenting them with top-level folders, each containing nested sub-folders, each containing carefully organized links. But it didn't. The first problem, that almost every document applied to almost every user, had not been corrected. And now, second, users had to click through mumerous folders, which has only exasperated the difficulty in finding the right documents. Two for two, organization had not helped.

Organize Via Dynamic Sorting?

By this time, we gave up on the user pages and the nested tree menus. Users wanted all the documents on one page. At least they wouldn't have to drill through nested folders and navigate back and forth among pages.

So then I added drop down menus, two of them, that would let users select the types of documents they want returned. It was a type of search feature that worked out pretty well. It was the best method so far. Users had only one page to navigate to and the sorting feature was very fast, so different document sets could be returned quickly. But, again, we were foiled by the fact that so many documents contained information relevant to so many users and situations. We begin having a repeat of the user page link problem: the number of documents per category kept increasing as the person in charge of organizing the documents kept cross-referencing every document to every category, the number of results for each category kept growing into too many links.

Navigation Could Not Correct the Content

In the end, the content was the problem. Each time a new navigation was implemented it worked at first, until the person in charge of the content had enough time to properly categorize everything. And every piece of content applied to almost every user. The content could not be divided up to reduce the number of links (choices) we could present to users. Also, some documentation was better than others; some documentation had more relevant information; some documentation had newer information; some documentation applied in only specific circumstances.

Rather than reducing the number of choices users had to make in finding their information, because the information itself offered too many choices, we had been trying to tame a wild beast with better navigation, and we couldn't. Now that I look back, nothing about this situation should have been surprising. The department itself allowed too many choices: there were exceptions for almost everything in terms of internal standards and procedures. Many guidelines applied to only certain groups and many standards were slighltly different, according to internal politics. And all this was documented in what turned out to be a fragmented and inconsistent documentation set. How could that problem possibly be solved by navigation? It couldn't.

More Choices Are Not Always Better

The department in question prided itself in empowering different groups to make their own choices, to build their own solutions. But then implementing departmental guidelines, with documentation, became a nightmare. I fnially recommended that each group be responsible for their own documentation. This went over very well and probably solved some internal political issues of different people being offended that "outside" groups were trying to enforce standards. The lesson I learned is that navigation issues are not always design issues and that organization tactics do not always help. So if using good design practices it not solving the problem, maybe the problem isn't design related at all. You can't organize an inherent mess.