I recently had a conversation with a friend about the usability difficulties I had with Android phones, and something that came up is the matter of discoverability. Discoverability is how easily a user can find a feature or function. A key component of discoverability is consistency within an application and across the user’s experience.

When people talk about usability, they often think an interface needs to be intuitive or that it can be sussed out in a few seconds. While it’s great to shoot for that goal, the truth is, many applications require a sophisticated feature set that is too deep for users to “get” in a few minute. Some examples of these applications are:

  • Image editors
  • IDEs
  • Statistical analysis
  • Geographic information applications
  • 3D modeling
  • Animation

The list is pretty long. Even if you are quite familiar with those particular kinds of work, it takes a good amount of effort to learn to use the tools. I have been writing software for more than 20 years, and using Visual Studio (a pretty advanced IDE as far as these things go) for nearly 10 years, but that does not mean that I can pick up Eclipse and just start working with it proficiently — not by a long shot. Even within Visual Studio, there is functionality that I either stumble upon or re-discover. Visual Studio (and Eclipse) is so massive that it can take a long period of usage to find each function, and then learn it well enough to incorporate it into your development workflow. I am not saying that Visual Studio is bad, but it is a great example of an extremely sophisticated application with a discoverability problem.

For application developers, the key to making your applications be discoverable is to follow conventions. In the Windows ecosystem, Microsoft (often with Office) generally is the standard setter. In Windows 95, Microsoft introduced the idea that a right-click should consistently bring up a list of less-used, but still important functions. Office 2007 brought about the Ribbon and contextual, floating toolbars to try to aid discoverability to varying degrees. In each case, application developers quickly imitated the Microsoft style in their own applications.

On the Web, we see a multi-layered set of OS conventions. First, there are the conventions within your application and site. A good example of this is the display style for hyperlinks; if they always appear in the same color on your site, users will see them more easily. Next, you have the conventions that other sites have established, such as linking the logo in the top-left corner to the home page or putting a search box in the top right corner of the screen. Beyond that, there are the conventions of the Web browser; and the expectations of the “Back” button are another example. Finally the user’s OS gives them a consistent set of behaviors (like copy/paste). If your website or application is going to ignore or contradict these conventions, you do so at the risk of damaging the user’s ability to discover functionality.

In some cases, consistency is not necessarily a good thing. On many mobile phones, for example, there is a consistent idea that a “long tap” should be different from a “short tap” to bring up a context menu. The problem is that the consistency in this case is reinforcing the use of a horrible UI metaphor. The “long tap” is a bad UI idea, because elements almost never have a way of indicating that they can be acted upon by a long tap; the discoverability is close to nil. The good news is, while using these UI metaphors may be consistent, they are so underused by users due to their poor discoverability that not being consistent with them has little penalty.

As an application developer, you need to be aware of the conventions that your users will be accustomed to due to the platforms they use, how commonly they are accessed by users (for example, right-click is not used by many users, despite the number of applications that support it), the level of training users will receive, and other factors that will play into the discoverability of your capabilities. If your features will not be very discoverable, you need to seriously consider whether they should be cut under the “80/20 rule,” or if there is another way to expose them in the interface so they can be used.