#26 - The myth of discoverability

ByScott Berkun, August 2003

Discoverability is often defined as the ability for a user of a design to locate something that they need, in order to complete a certain task. It’s common to hear programmers and designers utter the phrase “that won’t be discoverable”, while pointing to a specific command or link they believe users will fail to find. The trap, and the myth, of discoverability is that in any design, not everything can be discoverable.

There are two flavors of the myth: the core myth, and its corollary.

The myth of discoverability, in concise form: The belief that all good user interfaces make all things in the website or product utterly and extremely discoverable, and any design that makes an element (button, link, etc.) less than extremely discoverable, can’t possibly be very good, and should be thrown away, to the embarrassment of the designer.

The corollary for large teams: In lieu of a truly good design, often people on the team will accept any design that makes the specific feature they care about (because they like it, because it’s new, because they work on it, etc.) discoverable, regardless of its relative importance compared to other features (note that this corollary is often applied without knowledge of the base myth).

Why everything can’t be discoverable

All things can not be easily discoverable because everything is limited. You have limited screen real estate, users have limited attention spans, and abilities to perceive or understand things. Therefore, all design for people is a zero-sum game: tradeoffs must be made and priorities must be set if there’s any hope of a good outcome for customers.

If, as a designer, I tried to weasel out of this, by giving everything equal attention in the design, I’d ensure only mediocrity. By treating everything equally, I’d force customers to make choices of prioritization, which generally, they’re not so interested in doing. Most people are glad that the steering wheel in their automobile is easier to discover than the fuse box. They expect that whoever designed the automobile, or web site, is making good basic choices in their interest, so that they don’t have to think about it. In part, that’s what they’re paying for.

This means that anyone that builds things that people will use has to consider what things need to be discoverable first, and where the emphasis of a given design should be. This turns out to be difficult, and as a result, many designers and engineers do everything they can to avoid these kinds of considerations. Many mediocre designs are the result of the avoidance of tough decisions on the part of the designer, rather than an inability to design well.

Is discoverability the most important aspect of a design?

Discoverability is one link in the chain. Of course it’s important, since in order to get something done, users need to locate the command or link in question. (You can’t even try to make a left turn if you can’t discover the steering wheel). Given that it’s impossible to click on something you can’t locate, discoverability is certainly important.

However, discoverability does not guarantee success. It’s entirely possible for a user to discover the correct item, but not know how to use it, or make it work (e.g. grayed out commands in an application). It’s also possible for an item to be discoverable, but difficult to use. I may know exactly where the spare tire is in the trunk of my car, but that doesn’t make it any easier for me to successfully change a flat. Lastly, a user might be able to discover an item the first time, but have trouble locating the item a second or third time. So the fact that something can be discovered does not imply that their experience after the moment of discovery will be particularly good.

How do you decide what to make discoverable?

You have to prioritize. Whether you’re designing a toaster oven or an airplane cockpit, you must create a framework for how you believe the thing you’re building will be used. Some designers call this scenario based design, where you create a list, preferably based on user research, for the typical things your users need to accomplish with the design. There are many different methods for it, and I don’t think it matters which one you use, provided you’re using one.

But regardless of the specific method, to generate a prioritization for your design, requires stepping away from the functional, engineering driven model of looking at a design, and stepping away from the marketing, business driven framework of a looking at a design, and focus on the perspective most people who will use the thing will probaby have.

Now while everyone thinks they can easily switch gears in their mind to obtain this perspective, most people stink at this (but are great at denying it). It takes great practice for most people to become good at giving up the point of view of their expertise, and allow themselves to observe the design in the full context of how it will be used. In some sense, this is the real gift of a good designer or engineer: the ability to temporarily forget their expertise, and allow themselves to consider and accurately imagine how customers will experience the design.

The golden rule for what to make discoverable

Here is the golden rule:

Things that most people do, most often, should be prioritized first. Things that some people do, somewhat often, should come second. Things that few people do, infrequently, should come last.

That’s it.

If you want more detail, here is a deeper prioritization of how to think about the relative importance of tasks and features:

1. Things most people do, most often.
2. Things most people do, somewhat often.
3. Things some people do, most often.
4. Things some people do, somewhat often.
5. Things few people do, most often.
6. Things few people do, somewhat often.

You get the idea. Depending on what you’re designing, and who you’re designing for, you might have different categories, and place them in a different order: that’s fine. The important point is that you are prioritizing the kinds of tasks and frequency of occurrence, and using that to drive how you allocate resources in your design.

Notable Exceptions to the rule:

• Start up tasks. You may have an important thing that people need to do only once, but it has to be done to enable everything else. (e.g. login, registration, application install, etc.). So even though this might not be done frequently, it may score high in the priority list.
• Some features might be needed only in emergencies. So while they aren’t used frequently, they need easy availability. (E.g. No pilot wants to use the eject button, but if ever they need it, they shouldn’t have to look for it. Car horns are another good example).
• Complex systems may require more complex considerations. Systems involving real time (air traffic control terminals), or intimate usage (development tools), make prioritization more difficult. The more complex the usage patterns, the more design thinking and iteration that may be required. This is more common in application design, than in web design.
• Diverse user groups. For sophisticated applications, there may be specific types of usage patterns associated with certain roles (administrator, user, teacher, student, etc.). It’s possible that the usage patterns are so different, that you might choose to optimize around those roles. You might want to invest in making different things discoverable for different types of users.

Applying the rule to designs

Once you’ve identified the things that are most important to the design, you can go and focus whatever design, engineering, and usability resources you have on those things first, and on making the important elements of your design discoverable. Perhaps the most flagrant mistake in design are websites or computer terminals that use the most important sections of screen real estate for things that are at the bottom of the priority list.

Progressive discoverability & Context

Another part of the myth of discoverability is that the home page or the toolbar are the only place where discoverability matters. The truth is that in many cases, top level discoverability is useless for features that are only used in a certain context. For example, when you go to the movie theatre, you don’t need to know about where the drinking straws are, until after you’ve purchased your soda. It’d be silly to have straws at the ticket counter, where they make no sense, but are arguably more discoverable, since the ticket counter is the first thing you see when you enter a theater.

It makes much more sense to worry about the discoverability of a given command or link in the places where it has a strong relationship to whatever the user is currently doing, or trying to accomplish.

Carefully choosing how and when to make commands or items discoverable could be described as designing for progressive discoverability. That you give users information on a need to know and useful to know basis, and disclose more depth as users progress deeper into your design, and can make use of those commands. (Note: don’t take this to the other extreme, where you restrict yourself to only showing one command or link on the screen a time. That’s just as silly as showing too many. As usual it’s all about balance).

The difference between discoverable and discovered

Think of the last time you saw someone on the highway drive past an exit, and at the last possible moment, realizing their mistake, cut back across the divider to get off the highway. You probably smiled or snickered, thinking how oblivious they must have been to miss it. Now, think about the last time you missed an exit. Not so funny anymore. When we’re honest with ourselves, we realize that some of the mistakes we make when interacting with systems are not entirely the designers fault.

It’s well documented that human perception is entirely fallible. We are sensitive to thousands of subtle variables and differences in what’s going on around us, and an individual’s performance in perception related tasks is at best unreliable, and at worst, difficult to accurately predict.

This means that simply making something discoverable, doesn’t guarantee it will be discovered. You could do everything in your power as a designer or a programmer, and still, some percentage of people that use what you made will miss certain things you thought were obvious. I don’t mention this to discourage anyone: it’s just a fact. And if you’re going to go about doing this stuff, you should understand that no matter how smart you are, or how much we’d like a smarter population, you just can’t circumvent the limits of the species.

This often means that smart designs account for human limitations. They’re forgiving, they make it easy to recover from mistakes, and sometimes allow for multiple ways to do something, without adding confusion. That’s a hallmark of master level work.

How do you actually make something discoverable?

As a designer, you have a handful of resources for emphasizing things, and trying to draw attention to them:

• Real estate: You get a certain amount of pixels to use however you want. Larger targets are likely to be located first, and easier to be found again. Big targets are easier targets.
• Order: You can place things in specific orders, from left to right, and top to bottom, that might form patterns people can learn to follow, depending on their language (some are left to right, some are right to left, etc.).
• Form: You can use color, font, shape, shadow, composition, and other graphic design constructions to help make use of the real estate you have.
• Expectation & Flow: Depending on how you use the above, you can put things into forms or patterns that are in some way familiar to people. The most obvious examples are printed newspapers, and how columns, line breaks, and headings are used. This might be achieved by emulating another design from another website, or from something in the real world.
• Consistency: If you use the screen in consistent ways, you can teach people to look for certain kinds of commands in certain places. By being predictable, you can score some extra discoverability points. This can often be assisted by using available conventions, and trying to make use of knowledge your users already have.

Every metaphor or paradigm you might be familiar with (GUI, Windows, Mac, amazon.com, etc.) makes use of real estate, order and form to achieve the results they do. Good systems provide some basic constructions for making elements discoverable that can easily be reused.

Does prioritizing discoverability eliminate user choice?

Yes and No. When the guy who designed the highway you drove to work today decided to space exits 5 miles apart from each other, he or she eliminated many possible choices from your driving options. You can’t leave the highway in the middle of those two exits (unless you drive a jeep or a Hummer). But this can work to your advantage. The system of exits gives you a standard way to tell people how to get on and off the highway, and helps to maintain a regular pace of traffic. So while that one exit might be one mile out of your way, the holistic value of those kinds of choices works to your benefit.

So yes, you do give up some degree of freedom, but if the designer is a good one, you won’t mind. The overall benefits outweigh the limited sacrifices.

In other words, eliminating stupid, unnecessary or infrequent choices from the list of decisions people need to make, is almost always a good thing. They don’t care about what they don’t need to care about.

In many cases, we create self-fulfilling prophecies in our user interfaces. People trust us. They think we know what we’re doing. So when we create a link on the web page that says “Modify turbo overdrive optimization threshold” they think there’s a reason they might need to do that, when in reality, it’s probably only the programmer, and the programmers friend across the hall, the really even understand what this is, much less have a reason to ever use it. But by putting it there, we suggest to people that there is a good reason for it. Way too much of the time, there isn’t.

Other important discoveries

Head on over to the forums - ask follow up questions, leave your thoughts, and practice discovering interesting things. The Book: The Art of Project Management (O’Reilly,

2005).

Ten years of hard earned lessons on leading teams and managing projects, applied to the core situations you deal with every day. Book details and ordering information.

Things published elsewhere

Unifying web navigation,Interact ‘99
Agents of Change, Wired 3.04
Ancient pixels, Wired 2.04
The art of project Management, O’Reilly