User Interface Design for Programmers by Joel SpolskyNotable passages from
User Interface Design for Programmers
by Joel Spolsky

Apress, Berkeley, 2001

To make people happy, you have to let them feel like they are in control of their environment. To do this, you need to correctly interpret their actions. The interface needs to behave in the way they expect it to behave.


[]

Users will assume the simplest model possible.


[]

It has been said that design is the art of making choices.… When you are designing and you try to abdicate your responsibility by forcing the user to decide something, you're not doing your job.


[]

Consistency causes ease of use, which, in turn, causes good feelings.…

If consistency is so obviously beneficial, why am I wasting your time and mine evangelizing it? Unhappily, there is a dark force out there that fights consistency. That force is the natural tendency of designers and programmers to be creative.

I hate to be the one to tell you "don't be creative," but unfortunately, to make a user interface easy to use, you are going to have to channel your creativity into some other areas. In most UI decisions, before you design anything from scratch, you absolutely must look at what other popular programs are doing and emulate that as closely as possible.

When you find yourself arguing with an anti-Microsoft fundamentalist or a creative graphic designer about consistency, they're apt to quote Ralph Waldo Emerson incorrectly: "Consistency is the hobgoblin of little minds…" Emerson's real quote is "A foolish consistency is the hobgoblin of little minds."
   Good UI designers use consistency intelligently, and though it may not show off their creativity as well, in the long run it makes users happier.


[]

Let people do things in whatever order they like. If they want to type their name and address before they provide a credit card number, that should be just as easy as providing the credit card number first. Your job as a designer is not to have a conversation with the user; your job is to provide a well-stocked, well-equipped, and well-lighted kitchen that the user can use to make their own masterpieces.


[]

[A]round 1990, a new trend arose: usability testing. All the large software companies built usability labs where they brought in innocent "users," sat them down in front of the software to be tested, and gave them tasks to do.
   Alas, usability testing does not usually test how usable a program is. It really tests how learnable a program is.

Good usability doesn't just mean "usability under the best of circumstances." It means usability under as many adverse circumstances as possible. This is a principle called design for extremes. Don't design something that can only be read in daylight: design it to be read in dim light, too. Don't design something that can only be handled by a strong, seventeen-year-old athlete; design something an arthritic person can use as well. Design things that work outdoors, in the rain, when you're not looking, when you didn't read the instruction manual, when you're distracted by bombs falling around you, or volcanic ash, or when you've got both arms in a cast and can't quite turn your head.

  1. Design for extremes so that your product can be used under extreme conditions, and
  2. Design for extremes so that your product is more comfortable to use under normal conditions.

When you're designing for extremes with software, the three most important "extremes" to remember are:

  1. Design for people who can't read.
  2. Design for people who can't use a mouse.
  3. Design for people who have such bad memories they would forget their own name if it weren't embossed on their American Express.

They can decipher the manual if they really must, but they sure ain't gonna read it if they don't have to. Users do just-in-time reading on a strictly need-to-know basis.
   The upshot of this is that you probably have no choice but to design your software so it doesn't need a manual in the first place. The only exception I can think of is if your users do not have any domain knowledge—they don't really understand what the program is intended to do, but they know that they better learn. A great example of this in Intuit's immensely popular small-business accounting program, QuickBooks. Many people who use this program are small-business owners who simply have no idea what's involved in accounting. The manual for QuickBooks assumes this and assumes that it will have to teach people basic accounting principles. There's no other way to do it. If a small business owner wants to learn accounting, they actually might just curl up with the QuickBooks manual in a comfortable chair and read it cover to cover. Still, for people who do understand accounting, QuickBooks is reasonably easy to use without the manual.


[]

Intuitively, you might guess that the Juno version [of a dialog box message], with eighty words of instructions, would be "superior" (in other words, easier to use) than the Windows version with its five words of instructions. In reality, when you run a usability test on this kind of thing, you'll find that:

  1. Advanced users skip over the instructions. They assume they know how to use things and don't have time to read complicated instructions.
  2. Most novice users skip over the instructions. They don't like reading too much and hope that the defaults will be OK.
  3. The few novice users who do earnestly try to read the instructions (some of whom are only reading them because it's a usability test and they feel obligated) are often confused by the sheer number of words and concepts. So, even if they were pretty confident that they would be able to use the dialog when it first came up, the instructions actually confused them even more.


[]

Lesson number one is that if you're an English major from a fancy university, then you are in a whole different league of literacy than the average Joe and you should be very careful about wording dialogs that seem like they might be helpful to you. Shorten it, dumb it down, simplify, get rid of the complicated clauses in parentheses, and do usability tests. But do not write things that look like Ivy League faculty memos. Even adding the word "please" to a dialog, which may seen helpful and polite, will slow people down: the increased bulk of the wording is going to reduce, by some measurable percentage, the number of people who try to read the text.


[]

The poxy dropdown listbox is even more annoying because there's such an easy solution: just make the dropdown part high enough to show all options at once. Ninety percent of the combo boxes out there don't even use all of the available space to drop down, which is a sin. If there is not enough room between the main edit box and the bottom of the screen, the dropdown should grow up until it fits all the items, even if it has to go all they way from the top of the physical screen to the bottom. and then, if there are still more items than there's room for, it should scroll automatically as the mouse approaches the edge rather than requiring the poor user to mess with a teensy weensy scrollbar.


[]

Designing good software takes about six steps:

  1. Invent some users.
  2. Figure out the important activities.
  3. Figure out the user model—how the user will expect to accomplish those activities.
  4. Sketch out the first draft of the design.
  5. Iterate over your design again and again, making it easier and easier until it's well within the capabilities of your imaginary users.
  6. Watch real humans trying to use your software. Note the areas where people have trouble, which are probably areas where the program model isn't matching the user model.


[]

Watch Out for Unintended Consequences. One of the most famous UI metaphors of all time is the trash can from the Macintosh desktop. The original metaphor was terrific: when you dragged a file to the trash can, it was deleted. And the neat thing was, you could look in the trash can and see all your old deleted files! So if you ever dragged something there by mistake, you could get it back. How do you get a deleted file back? You drag it out of the trash can, of course! An excellent metaphor.
   There was one problem. After a few releases, the Mac designers went a little too far and decided that a trash can with something in it should look "stuffed," so when you drag something in there, you get a full trash can instead of an empty trash can. The trouble is that neat freaks were distracted by the full trash can. It looks messy. When they wanted to clean up, they would empty the trash. Over time, many people got into the habit of dragging things to the trash can and then mechanically emptying the trash so that the trash can wouldn't look messy, thus defeating its original purpose: to provide a way to get things back!


[]

You Don't Need to Test with a Lot of Users. As it turns out, with a usability test, you don't really care about statistics. The purpose of a usability test is simply to find the flaws in your design. Interestingly, in real life, if you have major usability problems, it only takes about five or six people before you find them.

A Usability Test Measures Learnability, Not Usability. It takes several weeks to learn how to drive a car. For the first few hours behind the wheel, the average American teenager will swerve around like crazy. they will pitch, weave, lurch, and sway. If the care has a stick shift, they will stall the engine in the middle of busy intersections in a truly terrifying fashion.
   If you did a usability test of cars, you would be forced to conclude that they are simply unusable.
   This is a crucial distinction. When you sit somebody down in a typical usability test, you're really testing how learnable your interface is, not how usable it is. Learnability is important, but it's not everything. Learnable user interfaces may be extremely cumbersome to experienced users. If you make people walk through a fifteen-step wizard to print, people will be pleased the first time, less pleased the second time, and downright ornery by the fifth time they go through your rigmarole.
   Sometimes all you care about is learnability: for example, if you expect to have only occasional users. An information kiosk at a tourist attraction is a good example; almost everybody who uses your interface will use it exactly once, so learnability is much more important than usability. But if you're creating a word processor for professional writers, well, now usability is more important.
   And that's why, when you press the brakes on your car, you don't get a little dialog popping up that says, "Stop now? (Yes/No)."


[]

One of the best, if not the only, good reason to have a usability test is because it's a great way to educate programmers about the real world.


[]

Days Are Seconds. It usually takes days of design, programming, and testing to create a fragment of software that a user will experience in a matter of seconds.… What that means is that some aspects of the dialog may make perfect sense to you as a programmer, because you spent four days thinking about them, but they won't necessarily make sense to a user, who has to figure them out in a couple of seconds.

Months Are Minutes. When you create a new software package, even a fairly simple one, it typically takes between six months and two years from the initial conception to the shipping the final bits. During those months or years, you have an awful lot of time to learn about your own program and how it works. When you invent a new concept every month or so for two years, the leaning curve is not very steep—for you. For your user, it means there are twelve things to learn right out of the box in the first five minutes of using the dang thing.
   The products that we recognize as the being the best designs always seem to have the fewest buttons. While those products were being created, it's pretty obvious that the designers kept thinking of ways to simplify the interface, not complicate it.…
   As you design and build your product, try to notice if you are adding complications or removing complications.

Seconds Are Hours. The third time warp rule is that it doesn't take very long before somebody gets bored and decides that your program is slow. If your program feels slow, your users won't feel in control, and they'll be less happy.


[]

The general rule for how to use color was best stated by Web designer Diane Wilson: "Design in black and white. Add color for emphasis, when your design is complete."

Color can be used successfully for a few things:

  1. As decoration—in pictures, icons, and text, where the effect is solely decorative.
  2. To separate things—as long as you do not rely on the color as the only indicator, you can use color as one distinguishing factor, for example, by using a different color and a larger font for headings.
  3. To indicate availability—by using grey to indicate an option that isn't available.


[]

Some early Web usability gurus did some usability tests and discovered that people don't know how to scroll. What they failed to notice was how quickly people learn this skill. Once again, they confused usability with learnability. In the meantime, an uncanny amount of damage has been done by Web site designers who try to cram their sites into a tiny rectangle so that their site is viewable without scrolling, usually by using a font so small most people have to strain to read it. Luckily, the "nobody knows how to scroll" superstition is wearing off.


[]