Usability vs Discoverability

I got into another spirited debate discussion on IRC today, this time about application usability and discoverability. We were talking about books and someone mentioned Don’t Make Me Think. I accidentally started the brouhaha by saying that it was a decent book, but that I disagreed with its core point of view. Wow, was that a bad idea.

But, I think I have some valid points to make, and what better place to rant than my own blog, right?

For a while now, there has been a rallying cry of “usability” for the web. It may seem like this is a Web2.0 thing, but it’s been around since at least Web1.5 (CSS) and maybe even longer. My argument was and is this: there is a very important distinction between “usability” and “discoverability”, and secondarily that one does not imply the other. But, too many people confuse the two. Just to be clear, let’s define our terms.

Discoverability
In a web application context, this equates to how long it takes a user to figure out how to perform a specific task without any previous training or documentation. If you said “buy me a boat”, can the user figure out how to do it? It also covers finding new things you didn’t even know you wanted. Note that we are not talking about the ability for the user to find your website in the first place, such as via Google.
Usability
Can the user continue to efficiently use the application over long periods of time? Or are they constantly stumbling over things? My favorite counter-example here is Microsoft Word and its hatred of bulleted and numbered lists. Anyone who has ever fought with lists in Word will understand this.

The distinction between the two is then pretty much down to timeframes: discoverability is about the first time a user does something, and usability is about doing that thing over and over again. Fair enough?

So what about the relationship between the two? As I said above, one does not necessarily imply the other. We could make every feature in our application discoverable by adding a button for every function on a toolbar. This was the approach used by MS Office before the 2003 version. But that doesn’t help usability much, does it? Given enough buttons, and MS Office had plenty, you’d lose valuable screen real estate and never get anything done. Jensen Harris has a great blog post about screen real estate in Office, as well as one about usability and discoverability.

Office 2003 helped this out a little by hiding the things you never used and showing the things you used most often. This only marginally decreased discoverability on the theory that you’d want to discover less over time, and drastically increased usability as the things you used were just there. But you can see, given a large enough application, usability and discoverability can start to degrade each other. Sure, if your app only does 3 things, you don’t have too many compromises to make. But can you imagine a UI for everything that emacs does? Emacs is a paragon of usable, but just about as un-discoverable as you can get.

But how does all of this relate to web applications?

First, start thinking beyond Twitter and Jaiku and Flickr and Del.icio.us and all other other Web2.0 apps. Why? Each of those apps essentially does one thing and does it well. I’m certainly not going to belittle the design or experience of any of those apps, as they obviously work just fine, I’m just saying that there’s a world of difference between those and one that manages the finances for an international Fortune 500 company. I’m going to distinguish this kind of application from general productivity tools like Office by referring to it as a “business app”. That is, you aren’t just doing clerical work with it, you are running your business. There’s no reason why these business tools can’t be web-based or RIAs or whatever. And thus we’re getting around to my point.

Do business applications have the same discoverability and usability needs as typical Web2.0 apps?

Some people would argue that yes, every app should meet minimum discoverability and usability requirements. Here’s the debate part — I’d argue that no, they actually have an entirely different set of rules to play by. More directly, why does a business app need to be discoverable? I’d argue that in a business app, the scales tip almost, if not entirely, over towards usability and discoverability should be only a minimal concern.

Why? Not to put too fine a point on it, but do you want your Fortune 500 company to be run by a clerical temp? No, of course you don’t. Then why would you expect your business applications to be used by a clerical temp? Wouldn’t you expect some minimal level of training and/or education? Your business application shouldn’t be worried about educating a clerical temp on the finer points of import/export restrictions — it should be concerned with letting someone who already knows about those things do what they need to do. And since they are going to be using it 40 or more hours every week, do you really want Clippy to pop up every 10 minutes saying “It looks like you’re trying to export something!”? Of course not.

I should make clear that this is not about security or access control in the traditional sense. I’m not advocating that your UI design should be intentionally kooky just to foil the random passer-by. I’m not talking about hiding features or making things counter-intuitive. I’m just saying that for business apps, usability trumps discoverability.

I am arguing that you should consider the end-user when you design a system. Is it a Web2.0 app that does one or two things and needs to be easy enough to figure out that your grandmother could use it? Then sure, go ahead and add lots of helper buttons and pointers and how-to popups and wizards and whatnot. If it’s a business app that someone is using all day, each and every thing in that list is only going to get in their way. Scott Berkun has a post about the “Myth of Discoverability”.

I was told that this argument is “elitist” and “old-school”. In the strictest sense, that may very well be true. But, really, do you want the Finance Manager figuring out how to run the finances for a company based on how discoverable his business app is? Or do you want him to take the time to learn the business app so that he can use it to effectively and efficiently run the business? This is a case where the “just sit down and go” approach is the exact opposite of what you need. And, I’d argue, for most business apps this will be the case.

I know that it will be anathema to many of the new-school programmers out there, but training is not a bad thing. Don’t Make Me Think is an okay mantra for a product you are selling, but it’s certainly no way to run a finance department.

Published by

Rick Osborne

I am a web geek who has been doing this sort of thing entirely too long. I rant, I muse, I whine. That is, I am not at all atypical for my breed.

9 thoughts on “Usability vs Discoverability”

  1. I would disagree with a few points here:

    “I am arguing that you should consider the end-user when you design a system.”

    This is wrong if you ask me. All end users are not alike, and to classify the end user into a single group is wrong. One person learns faster than another. One user may have a difficult time understanding something if you train them 5 times. Therefore, discoverability is essential to any application. That user may need to discover the same feature 10 times before understanding where it is and how to do it over and over again

    “I was told that this argument is “elitist” and “old-school”

    I certainly don’t think this is elitist. Old school, yes.

    Also, your view fails to take into account any evolution of a product. Are you going to retrain them with each new version? That seems costly and ineffective compared to making your application discoverable.

    Obscurity is bad practice in my opinion. Security should handle keeping unwanted users away. Training will assist the folks you do want using the application to use it properly. Discoverability will help remind them how it is supposed to be used. Usability will assist them in making their experience with the application better and enhance their workflow.

  2. TJ: Thanks, that’ll help me clarify a few dusty corners of my rant. You said:

    “All end users are not alike, and to classify the end user into a single group is wrong.”

    That’s my point – for a business app you know exactly who your end-users are. You aren’t worried about grandmas having to walk up to it and figure it out.

    “Are you going to retrain them with each new version?”

    Presumably, yes. I’d argue that the up-front cost of training is far smaller than the long-term cost of not being able to run a business correctly.

    “Obscurity is bad practice in my opinion. Security should handle keeping unwanted users away.”

    But again, I’m not saying you should obscure anything. Just that if it comes down to a question of “if I add this button it will increase discoverability but take away some other thing that could have gone there” … then you have to think about what the right answer is. You can’t just assume that the discoverable option is the best one.

  3. I think the short answer is that discoverability is one aspect of usability. Usability (even more so UX) is a broad term, whereas discoverability is a much more focused one. Discoverability contributes to usability, and needs to be considered within the context of the latter.

  4. I definitely agree that business apps as you describe them should be optimized for efficiency rather than discoverability. I’d wager that web site builders who favor discoverability over efficiency would never consider replacing their computer languages, libraries, and programming environments with a web-like point-and-click UI, but that’s analogous to what they’re saying. For a business app, in principle, one could make a cost-benefit analysis for a known employee turnover of the training and supports costs versus the productivity gains, and I’m sure there are many business situations where having an app that requires training comes out ahead.

    But, while there are some definite situations where you have trade-offs between efficiency and discoverability, fortunately many if not most design principles that work for discoverability also work for efficiency. For example instant unambiguous feedback at the point of user input re-assures the new user s/he did the right thing, but also allows the expert user to move to the next task faster. A deep convoluted navigation sequence means a greater chance for the novice to get lost, and also more clicks for the expert to do the task.

  5. I would suggest that, like Grant, that discoverability is a subset of usability. Your narrow definition of usability is flawed.

    If you decided to have a usability consultant come in and test your app, would you really be satisfied if all they looked at was whether or not an experienced user could efficiently complete tasks? I don’t think so… and if that is all you got, then you shouldn’t pay full price.

    A huge part of usability is ensuring that new users can find their way around and become regular experienced users.

    Case and point: Your Blog doesn’t have an about section. I have no idea who you are and why I should read your Blog. Chances are that as a result of this I won’t become an experienced and regular user. A usability study would have shown you this.

    As said, your argument is flawed from the point where you separate usability and discoverability.

  6. Greg said: “Your narrow definition of usability is flawed.”

    I’d been thinking about that, and I’m willing to grant you that not everyone will agree with that particular word (usability) being paired with that particular definition (long-term ability to efficiently navigate the application). Maybe you’d like to suggest a better word?

    “A huge part of usability is ensuring that new users can find their way around and become regular experienced users.”

    Is it? That’s precisely the point I’m trying to get people to think about. As I said in my post, I’ll grant that such a view is very applicable to certain types of applications (say, ecommerce websites), but is it applicable to every type of application? Would it be applicable to, say, the nuclear football? How push-button-easy do you really want that particular system to be?

    “your argument is flawed from the point where you separate usability and discoverability.”

    And that, as I said, is precisely the point that I am making: that people are being trained these days to not distinguish between the two, and it’s only leading to applications that are no longer geared toward their users.

    In our Attention-Deficit-Disorder-gone-mad world, people are only thinking about the experience of the first five minutes, and not of the next five years. Think about how many reviews of new applications you read that say how easy or hard something was out of the box. That’s all fine and good, but where are the reviews that tell you how easy or hard a product was to use after 3 months? Does long-term use mean nothing any more?

  7. I think there is a difference. A great site to demonstrate this is of all things for the Boobahs (if you have kids you know who/what those are).

    http://www.boohbah.com

    I went to this site as was confused – there are no words. No instructions. Nothing. I couldn’t figure out how to do anything. And even after clicking around for awhile I found it difficult to navigate ‘back’ to a previous location.

    Both my kids (4 and 7) can easily navigate it. And they can re-visit the site and immediately go to a particular section.

    It would be interesting to know their design process and what kind of testing they did.

Comments are closed.