Programmers are often accused of not taking the user's needs into account when they design software. Even when they do, however, they usually minimize the wrong function. Consider the following functional form for pain:
Total Pain =When only wo is non-zero, the user is not considered at all. When the programmer has to use the result, wi > 0, but wo is usually much larger, since one almost always understands how to use ones own programs.wo · Pain experienced by programmer while implementing feature
+
Sum for i=1..N of (wi · Pain experienced by user in possible situation i)
Ideally, wo should be zero. Unfortunately, in the real world, constraints on time and money force it to be non-zero, but it must be kept much smaller than wi to produce something useable by others.
A more subtle problem is that programmers are trained to write code that handles every possible case, without worrying about how likely each possibility is, so they automatically set wi to the same value for i=1..N. This results in a design where all cases are equally annoying, such as the ubiquitous confirmation dialog: "Do you want to save this before closing it?"
This is clearly unnacceptable from the average user's point of view. If something is very likely to happen, it should proceed smoothly. If something is very unlikely, it doesn't matter if it takes some effort to deal with it. Thus, the correct approach is to
make wi a function of the probility of case i
In many cases, this leads to a significantly different design, one that is much more tolerant of mistakes and much more enjoyable to use. As an example, consider the confirmation dialog. How often do you not want to save your work? One time out of a hundred? A thousand? Definitely a very rare event. How does this affect the design? Clearly, the program should assume that you want to save it, so it shouldn't bother to ask. But, you gasp, what if this was that one case where I didn't want to save?! If the program keeps a history of previous versions, then you can go back to the previous one. This requires some effort, since you have to open a dialog and find the previous version in the list (presumably at the top, since it should be sorted by date), but it happens so rarely that nobody is likely to complain. In fact, this mechanism also allows you to go back several versions, so it is likely to draw praise instead. Of course, now the programmers are gasping, That's a lot more work than a simple confirmation dialog!! True, but wo is almost zero, so nobody else cares. If one program implements the confirmation dialog and another implements the version history, the users will all want to use the one with the version history. Of course, this begs the question, Why don't any programs provide a version history? The answer is sadly that programmers have too much control over the design so wo is way too big and, if nobody implements it, then the users can't actually make the choice so the status quo is maintained. (The technical problem is that a version history can really only be done correctly by the operating system, and nobody has shown any interest in digging that deep.)
This shows that design really ought to be done by professional designers instead of programmers. Unfortunately, this doesn't normally happen because programmers usually have a lot more clout within the company.
Free software is a special case. Unless designers join the fight and work for free, such software will always be designed by the programmer because it because it is a labor of love. In this case, the best one can do is listen to one's users, get ideas from books and other programs, and never consider one's design or code to be unchangeable.
Norman, Donald A. The Design of Everyday Things. New York, NY: Currency Doubleday, 1988.
Back to the CUR Main Page