Give the Users What They Want

The best user interfaces keep the user in mind—a few tips from <i>User Interface Design for Programmers</i>.

• By Mike Gunderloy
• 11/01/2002

Many developers have read Aldous Huxley. At least, that's the conclusion I draw from some of the wildly inconsistent user interfaces that I've had to work with lately. Close buttons that look like candy pieces or glowing eyes, drop-down lists that don't drop when you hit the Alt+Down arrow, applications that try to turn Windows into some sort of art deco nightmare. Of course, Microsoft is no paragon of virtue here, with its user interface du jour improvements (if that's the word I'm looking for) to Windows and Office. Take IntelliMenus. Please.

Of late, "usability" has become one of the hot words, and "usability professionals" are starting to tell the rest of us what to do. Perhaps the best-known of these gurus is useit.com's Jakob Nielsen. Nielsen focuses on Web usability, and many designers find his pronunciamentos somewhat annoying ("Web pages can be no more than 3 KB if they are to download in one second which is the required response time for hypertext navigation," for example). So the question is, do usability professionals have anything to say to designers of Windows applications? Joel Spolsky does. His book User Interface Design For Programmers (Apress, 2001) is short and useful. It's a great place to start when you need to think about these things—and you do.

The Cardinal Axiom
Joel doesn't much believe in keeping people in suspense. Right in the first chapter, he gives us the cardinal axiom of user interface design:

"A user interface is well designed when the program behaves exactly how the user thought it would."

If you just remember that, you'll be ahead of 90 percent of the software developers out there when it comes to designing a good user interface. Why? Because most of us write software for ourselves, not for users. Look at a couple of data points:

There are dozens or hundreds of programmer's editors, debuggers, IDEs, compilers, source code control systems, and so on out there. That's because developers know what they want in their own work, so they write it. The edifice of software-for-writing-software just gets taller and taller. Meanwhile, we lose track of the fact that the people outside the development universe have to toss in money and raw meat once in a while to keep us going. What are we writing for them?

Office 2000 is a fabulous set of applications for sharing documents over an intranet. If you've got a big team of people working on a complex design project, and they need to share specifications and schedules, Office 2000 is a fabulous answer. Hey, wait! That's exactly what the Office 2000 team needed to do!

If you keep in mind the simple fact that you are not your users, you'll be more likely to write software that real people can understand. Yes, that means you're going to spend time on interface design. But assuming you'd like to be compensated for your software development labors, this is a generally good idea in any case.

The Trials of Testing
There's more than the cardinal axiom in this book, of course. For example, Joel spends an entire chapter discussing usability testing. If you've never worked on a large consumer product, you might not know how the usability testing ritual works: You bring users into a room with your software design, give them a list of tasks to perform and see how well they do. That's how you decide whether your design is usable.

Or, at least, that's how we pretend to decide. Joel points out some of the truths about usability testing:

• You can't test the actual shipping software, because by the time it's ready to ship, no manager in the known universe is going to let you waste time on usability testing.
• When you watch people, they behave differently. Usability tests tell you how usable things are in the lab, which may not be related to how usable they are in the wild.
• Usability tests are often rigged to prove what the designer wants to prove.
• Usability tests measure how learnable a new UI is (when they measure anything), not how usable it is in the long run.

Fortunately, Joel is not the sort of guy to just tear things down without an alternative:

"Do hallway usability tests, also known as 'fifty-cent usability tests,' when you first design a new feature. The basic idea is that you just show a simple drawing or screen shot of your proposed design to a few innocent bystanders (secretaries and accountants in your company make good victims) and ask them how they would use it."

You're Smarter Than They Are
No, not smarter than your users. Smarter than Microsoft! Joel doesn't pull any punches when he's demonstrating stupid user interface designs and many of his examples come straight from Microsoft (where he once worked). Remember the Windows 95 "Start" button, the one that was shipped before anyone used a Start button? Remember that obnoxious balloon that showed up next to it to say "CLICK ME"? Joel does, and he makes fun of it.

Some of my favorite examples from this book concern those wonderful Options dialog boxes that we all tuck away somewhere in our software. Have you ever actually looked at, say, the Word 2002 options? Eleven separate tabs, hundreds of options. Does anyone other than a software developer dare to go in there and change something? Couldn't the Word team make up their minds about anything?

Joel points out the should-be-obvious:

"Every time you provide an option, you're asking the user to make a decision. This means that they will have to stop and think. That's not necessarily a bad thing, but in general, you should always try to minimize the number of decisions that people have to make."

He goes on to discuss the sort of thing that ought to be in options dialogs, but I'm going to make you buy the book. It's worth your while. Hey, Apress even splurged to print this one in color so you can see how gloriously bad some of the user interfaces out there really are!

Do As I Say
The book has lots of good advice and provides plenty of things to think about. Here's a sampling of topics you'll find:

• The role of metaphors and "affordances" in user interface design.
• What sorts of problems people have reading instructions (hint: the chapter is titled "People Can't Read") or using a mouse.
• How to design so that users don't get frustrated by your software.
• What sorts of things people expect from software.
• Designing for the Web (which might as well be titled "The Sad State of Web Software").

Along the way, you'll find plenty of informal writing and fun stories. At 144 pages, the book is short enough that you might actually read it and funny enough that you'll want to finish it. I'm sure someone has written the thousand-page tome about usability, but I'll take this one instead.

Final Review
Just in case you're still not quite clear on the concept, here's why you should care about user interface design:

• The choices you make in designing a user interface can dictate whether your application is easy or impossible to use.
• If your application is easy to use, it will get good word of mouth and more people will buy it. Your bonus will go up. Your team will get pizza. Your next project will be a fun one.
• If your application is impossible to use, no one will buy it. People who get tricked into buying it will return it. Your bonus will be nonexistent. Your team will be split up and banished to offices in cities without a Starbucks. Your next project will involve cleaning the whiteboards.

Any questions? By the way, if you're intrigued by this look at Joel Spolsky's work, you might want to stop and take a look at his Joel on Software site at http://www.joelonsoftware.com/. It's on my regular list of sites to read.

Do you care about usability in your work? Or is it someone else's problem? What's the worst dialog box you ever saw in a shipping program? Write and let me know. I'll use the most interesting comments in a future issue of my Developer Central newletter.