The Design of Everyday Things, by Donald A. Norman, is an exceptional book for people considering "human factors" in almost any field of endeavor. (It was originally published under the name The Psychology of Everyday Things.) Reading the book suddenly makes the little annoyances of daily life jump out at you, because you understand how easy it would have been to avoid them.
The book discusses computer software, but many of the points made about non-computer environments translate quite well into an understanding of computer interfaces.
One of the most useful concepts I picked up from The Design of Everyday Things was the idea of "affordances" -- the set of things an object easily allows you to do. For instance, knobs are almost always intended to be turned or buttons to be pressed.
This concept applies directly to software. If you present a thing that looks like a checkbox, users will try to check it or uncheck it. If you present a button, users will try to click it. If it's hard to tell what a given set of pixels is, users will be confused by it. Users, when confronted with a graphical interface, quickly learn that they can click on things to select them or drag them to move them. The rules for how this will work vary from place to place but, overall, users are quite clear on what the mouse lets them do, most of the time. Surprises can be incredibly frustrating; users who click on a thing that looks just like a button will be unhappy if it doesn't work -- especially if they can't tell which of the objects are buttons.
User interfaces often make mistakes in this regard; I've used a number of programs that had what appeared to be a text-input widget, which was used only to display text. However, if the system's default is to have black text in a white box for user input and black text on a grey field for program output, program output in a white box will be confusing. The user will try to edit the text and fail, and be annoyed in the process.
A particularly good example of this I once saw was a list in which each item had a checkbox, reflecting whether or not that item had been attached to another program. Clicking on the checkbox had no effect whatsoever; the way to attach or detach was to double-click on the name elsewhere in the same line. However, the widget used was precisely the same as the standard checkbox used for toggle controls elsewhere.
Ah, standardization. Often, for user interfaces, even a bad standard is better than no standard at all. A casual look at the difficulty users can have trying to find the links on many Web pages suggests the importance of a standard way of indicating links. (Web designers who take the underlines off of links are just hurting everybody.) Trying to sweep the mouse over everything on a page, hoping that the cursor will change when it reaches a link, is annoying at best; even if underlined text can be annoying, it's better than no standard.
Another good way to see the effect standards have is to watch experienced users of one computer platform trying to use another. The subtle (and obvious) differences can make a significant impact on performance and usability; you're always faster at the interface you know better.
There is something fascinating about the ways in which habits can breed contempt for other systems. A regular UNIX user, I type ^W by habit to erase words -- it works in 99% of the text interfaces I use and is much more convenient than Backspace. When I do this in a browser window on a Windows box, of course, it most likely closes the form. When I wrote to the Mozilla developers to point out how disruptive this could be, one of them referred dismissively to this as "archaic." Of course, any binding you're not used to seems weird and alien ... an interesting perspective. I had always thought the Windows habit of using control characters as menu commands was weird and backwards, because they, unlike the Mac and Amiga, didn't have a special key that was used specifically for menu commands!
That leads us into the next interesting lesson we can learn from this book. A good design should adapt well to the certainty that users will make mistakes. The confusion over keybindings in Mozilla wouldn't have mattered much -- browsers are easy to reopen -- except that it most often happened while filling in large Web-based forms. The problem is that Mozilla had, at the time, no warnings at all between a close action and the loss of any unique data in a window. A good design would recognize that some close actions, especially on pages with large and complicated forms, might be unintentional on the user's part and provide some sort of confirmation prompt. (This might be done by the time you read this; the developers seem to like the idea.)
The general convention of warning before throwing away data is a good one, but there are some interesting special cases. On Palm PDAs, data never needs to be explicitly saved when you've entered something -- it's there. One of the programs I use on my PDA is a word processor, which supports two kinds of documents. The more complicated ones use the traditional desktop model, until you ask to save, you're working on a temporary version of the document. Unfortunately, this is very disruptive, as I might want to check my appointment list without stopping to decide whether or not my changes need to be saved. Nonetheless, I'd rather they do this than just throw my data out without asking.
It's always interesting to see new users experimenting with a system. How much harm will they do? On a good system, very little; likely errors will be fairly harmless. On most computer systems, it's possible to do an amazing amount of damage without any understanding of what's going on. How many programs implement an "Undo" feature which only works some of the time? Far too many. Worse yet, programs sometimes allow you to undo, for instance, a single search-and-replace operation, but not a global one. Of course, it's the global one that's the most likely to have done irreparable damage. In such a case, the "Undo" feature might cause more harm than it prevents -- by making users feel comfortable trying operations that could damage their documents, since they know there's an easy way to undo mistakes.
Many of the same problems that we face when dealing with real-world objects, such as telephones or even doors, show up to haunt us again in computers. Interfaces that try to mimic real-world objects often inherit the same mistakes that make the real objects annoying, while depriving us of the benefits of the experience we have with other computer interfaces.
When designing interfaces, it's important to try to make sure that an interface is as clear as possible. Use standard mechanisms. Use the right interface widget for the job. Try to avoid confusing presentations and always put important data where the user will see it.
Action item: Have you ever worked with a computer for which setting the clock was as annoying as it is on most VCRs?
- Visit the home page for Don Norman's collected writings, with information on his other books, as well as on The Design of Everyday Things.
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags