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.

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.
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 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.