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>.
Consistency is contrary to nature, contrary to life. The only completely
consistent people are the dead.
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
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
"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
- 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
"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.
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
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.
About the Author
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.