Jakob Nielsen's Alertbox, December 19, 2011

Overloaded vs. Generic Commands

Summary:
Overloading different outcomes on similar commands can be confusing. Using the same command for multiple actions enhances usability if the results are conceptually the same.

One way to manage interaction design complexity is to have commands serve double duty. There are two ways of doing this, with different usability implications:

Generic commands use the same command in different contexts to achieve conceptually the same outcome, even though details of the specific effects might differ.
Overloaded commands use variants of the same command to achieve different outcomes — sometimes depending on the context and other times depending on where the command appears on the screen.

I discussed generic commands in depth in an earlier article. The most famous generic command these days is the pinch-zoom gesture, which works in most touchscreen user interfaces. In fact, the command is so pervasive that users expect it to work universally — and are sorely disappointed when they encounter an application that doesn't support it. Pinching outward sometimes enlarges text and other times enlarges pictures. Users don't know or care about the differences; they simply rely on the gesture as a generic command when they encounter stuff that's too small and want to make it bigger.

Generic commands increase usability, because they allow users to learn one thing and use it many times. As further discussed in our training course on The Human Mind and Usability: How Your Customers Think, memories are strengthened by repeated activation, so the more places the command works, the better users will learn it.

Overloaded Commands: Often Confusing

You might think that overloaded commands are good as well. Having the same command achieve different (but similar) results sounds like an equally sound idea.

In practice, however, command overloading often confuses users:

If a single command has different results depending on context, users often overlook the context and don't understand why they get different outcomes when doing the "same" thing.
When a single screen has multiple instances of what seems to be the same command, users often assume that the design is redundant and that all instances of the command will have the same effect. Or, when users simply grab onto the first instance they see, they often fail to notice that the command actually appears multiple times.

A classic example of overloaded commands is websites with multiple search fields. I can't count how many times we've seen users issue a query in the wrong search on such sites. (However, there is an exception to the guideline to avoid multiple search fields: people finders on intranets.)

We saw several examples of confusing command overloading in our recent Kindle Fire user testing. For example, the Condé Nast magazine app has one "home" button at the top of the screen that takes users to the list of magazines and another "home" button that takes users to the Kindle home screen:

Two Kindle Fire screenshots, from different pages within Vanity Fair.
Two home buttons in Condé Nast's Kindle Fire app.

These two buttons have different icons and appear in different locations, but they're still confusing.

Even worse, the "back" button has many different interpretations across different Kindle Fire apps:

In many apps, "back" means "back to the previous screen" (which is the recommended use).
In ESPN, "back" means "back to home screen" (and should thus be a "home" button).
In The New York Times, "back" sometimes means "one step back" and sometimes means "two steps back." (When our users did a search and clicked through to an article, tapping "back" didn't return them to the search listing, but rather bounced them back one step further.)

For a decade, one of the primary homepage usability guidelines has been to designate a single page as the one and only official homepage for any given website. Users are confused when several pages are referred to as "home." In other words, don't use "home" as an overloaded command within a website. The main page for a subsite should be called something else, such as "foobar main page," "foobar overview," or — if you must — "foobar home" (within the site's foobar section).

For mobile apps, it's usually a good idea to have an "application home" that users can return to as a safe base after exploring the app’s various areas. This is particularly important for content-rich apps, such as magazines or newspapers. Used this way, the "home" button serves as a generic command: conceptually, it always does the same thing, even though the specific place users return to differs in different apps.

In contrast, offering many different "homes" within the same site or app makes "home" an overloaded command, which is confusing.

A final example of the risks from overloaded command is the swipe ambiguity we found in our iPad user testing. When the same command (a swipe gesture) has different outcomes, depending on exactly where and how the user swipes, confusion results, unless the distinctions are clearer than they were in the apps we tested.

Effective Command Reuse

As these examples show, it can be a bit tricky to determine whether command reuse should count as a generic command (usually good) or an overloaded command (usually bad). There are two key deciding factors:

Do people recognize that two contexts are different? For example, two different websites are usually so different that users wouldn't expect the two sites' "home" buttons to lead to identical destinations. In contrast, the context for two search boxes on the same screen is similar, even if the labels (which users rarely read) are different.
Do people view the outcomes as similar or different? For example, returning to the previous screen is a strong enough concept that users will view "back" commands as conceptually similar, even though the previously screens will usually differ.

Both criteria depend on how users interpret the user interface. How can you know what they'll think? Well, you could analyze it yourself and try to judge the strength of the similarities and differences. But empirical testing is safer.

Learn More

Full-day training courses at the annual Usability Week conference: