Jakob Nielsen's Alertbox, November 12, 2000:

Drop-Down Menus: Use Sparingly

Summary:
Drop-down menus are often more trouble than they are worth and can be confusing because Web designers use them for several different purposes. Also, scrolling menus reduce usability when they prevent users from seeing all their options in a single glance.

Drop-down menus clearly have their place in effective Web design. However, the limited interaction widgets available to designers has led to overuse and misuse of drop-down menus, creating usability problems and confusion. Increasingly, designers employ drop-down menus for a variety of different purposes, including

Command menus, which initiate an action based on the option users select.
Navigation menus, which take users to a new location.
Form fill-in, which lets users select an option to enter into a form field.
Attribute selection, which lets users choose a value from a menu of possible values.

Only the last use conforms to the classic interpretation of the GUI widget used for drop-down menus in current Web browsers. In particular, command menus are supposed to look very different and appear only in a standard menu bar. Although the Mac and Windows have two different menu implementations, in both cases the command menus are different from the attribute selection menus. In fact, on page 87 of the Macintosh Human Interface Guidelines, it explicitly says "don't use pop-up menus for commands."

Outlook for Change

The Web could certainly use a richer set of standard interaction widgets - at least as rich as the design palette that the Mac has offered since the late 1980s. Preferably richer. Given a broader vocabulary, designers could use exactly the right expression for each purpose, and thus increase the users' sense of mastery over the environment. The more designers mix up different actions in a muddled vocabulary, the less users will understand what they can do at any given time.

Unfortunately, there is no hope for better Web browsers any time soon. And, even if we were to get an enhanced design vocabulary, it would be two years or more before I would recommend using it because of the slow penetration of browser upgrades.

Thus, for the foreseeable future, we are stuck with a confusingly overlapping set of uses for a single, unpleasant GUI widget - the drop-down menu.

Designs to Avoid

Drop-down menus do have their advantages. First, they conserve screen space. They also prevent users from entering erroneous data, since they only show legal choices. Finally, because they are a standard widget (even if an unpleasant one), users know how to deal with a drop-down menu when they encounter it.

Despite these advantages, Web usability would increase if designers used drop-downs less often. To that end, here are some examples of designs to avoid:

Interacting menus, wherein the options in one menu change when users select something in another menu on the same page. Users get very confused when options come and go, and it is often hard to make a desired option visible when it depends on a selection in a different widget.
Very long menus that require scrolling make it impossible for users to see all their choices in one glance. It's often better to present such long lists of options as a regular HTML list of traditional hypertext links.
Menus of state abbreviations, such as for U.S. mailing addresses. It is much faster for users to simply type, say, "NY," than to select a state from a scrolling drop-down menu. Free-form input into fields with restricted options does require data validation on the backend, but from a usability perspective it's often the best way to go. (This is guideline #178 for e-commerce usability because of the many errors we observed in check-out forms with state drop-downs.)
Menus of data well known to users, such as the month and year of their birth. Such information is often hardwired into users' fingers, and having to select such options from a menu breaks the standard paradigm for entering information and can even create more work for users, as the following example shows.

At the recent Internet World conference in New York, Kara Pernice Coyne and I gave a talk on Web usability methods. As part of our presentation, we ran a small user test for the audience. When completing a registration page, our test user had to enter her address on a form with a text field for the name of the street but a drop-down menu for the type of street (Avenue, Boulevard, Court, Drive, and so on). Guess what? The test user typed her full street address in the text entry field, because that's what she'd always done in the past. The drop-down menu then came as a complete surprise and she had to go back to the text field and erase part of her already-typed address information.

This small study, conducted in front of a crowd of hundreds, shows that sometimes it is enough to run tests with a single user to clearly illustrate a point. Once you see such confusion in action, you realize that using a "helpful" drop-down menu to save users a few keystrokes can hurt more than it helps.

Impact of Scroll Wheels

(Added 2006.)

Most users now have mice with scroll wheels. When you select a value in a drop-down and then use the wheel to move down the page, you often change the value of the drop-down selection instead. Users often don't realize that they have changed their input but proceed to submit the form.

This is particularly error prone in cases where users have to select a date on a long form, say for reserving a trip or specifying the ship date for a package.

Check with your customer support people and see if they get many complaints about things that were "mysteriously" entered into the system with a ship date or reservation date that's later than what the customer expected. Many of these expensive errors are likely to be caused by the use of drop-down menus on your forms. Try changing to type-in fields and you'll probably see support calls go down and customer satisfaction go up.

(Update 2007: a new study once again found that drop-downs annoyed users.)

Learn More

Two-day course on application usability with guidelines for all types of applications:

at the Usability Week 2009 conference in Washington DC, San Francisco, London, and Sydney.

The conference also has a full-day tutorial on Fundamental Guidelines for Web Usability that covers a much broader set of usability guidelines.