Daring Fireball’s Review of BBEdit 8, and Self-Documenting UIs

John Gruber has published a great review of BBEdit 8. I’m especially interested in his observations regarding UI design and its effects on the user’s perception of the application:

From the perspective of users, however, the importance of the user interface is profound. For users, the application is what they can see, click, and interact with. A user’s relationship with an application is perceptual, sensual.

The raw capabilities of a particular application are, for most users, irrelevant; it’s the usability that matters. Features which aren’t presented via an intuitive, discoverable, usable interface might as well not even exist.

I’ve met few IT folks or programmers that fully grasp this concept. (No slight intended to those that do.) The end result is applications that fail to meet their intended needs, even though they address all requirements specified by the business folks.

Back to the review: John goes on to describe why Mac text freaks (programmers, web developers, writers, etc.) gladly shell out $130 for BBEdit over traditional Unix editors like VIM and Emacs that come freely bundled with OS X. (I know; I used to be an Emacs user before coming back to the Mac two years ago.) And then, a fantastic observation:

The Macintosh’s main appeal is not that it is easy-to-use, but rather that it is easy-to-learn. The difference is significant, but often overlooked.

I am in the middle of a project that aims to remake a consumer-oriented website so that it’s much easier for newbies to use. The key to this project’s success is not going to be to make it easy to use (some of the tasks the users will have to do are quite complex), but to make it easy to learn. To achieve this, the application must have a self-documenting interface.

How does one go about designing a self-documenting interface? Well, I’m in the middle of finding out, but some things I’ve learned thus far:

Use clear labels on all titles and buttons
Choose labels with great care: they must reflect and speak to the user’s mental model and expectations
Make sure that buttons and links are perceived as buttons and links, and text labels are not (obvious, yet often overlooked)
Expose the user only to as much information and choices as she needs at a given moment to perform the specific task at hand
Make more complex options available to experienced users, but only if they select themselves as such (this is something I learned from using Apple’s Hypercard in the early ‘90s)
Whenever possible, explain things visually or very succinctly—folks simply won’t read long texts
If your user finds himself in the middle of a multi-step process, make sure that he clearly knows what he’s accomplished thus far and, if possible, what he will do next
Make it easy for the user to experiment (allow stupid things to happen)
Make sure that when stupid things do happen, the system can recover gracefully (this is usually managed via multi-level undo—not a very webby concept—and confirmation screens)

This is a daunting topic—asking the user to learn an application by using the application itself. I’d be happy to get suggestions on the matter, and I’ll definitely post more on this topic as I learn more.

September 14, 2004 | Archived in Design