I read an article by Stephen H. Wildstrom some time ago in BusinessWeek (see "A Computer User's Manifesto"). The article discussed a ten-point User's Bill of Rights created by Clare-Marie Karat, PhD, Psychology. Karat works at IBM's Thomas J. Watson Research Center in Hawthorne, New York, where she evaluates the way people interact with computers. Karat, like millions of other computer users, is frustrated by poorly designed, late, and ineffective systems that often don't meet user expectations. To combat this problem, she has created a ten-point User's Bill of Rights based on the concept that the user is always right.

I confess I am a software engineer as well as a user, so I may indeed be part of the problem-and maybe even a little defensive. Even though I desire all the things Karat listed (such as "The user has the right to a system that performs exactly as promised," or "The user has the right to know the limits of the system's capabilities"), I would like to add some points for consideration for all of my fellow software users.

One of the problems with "the user is always right" is defining "Who is the user?" Companies that make and sell commercial software spend lots of thought and money on just this issue. All users are not the same and they have different needs. Some users want to have a powerful system devoid of annoying prompts such as "Do you really want to delete this file?" Other users are a little more timid and after deleting their newly written version of War and Peace would welcome the childlike question that requires a confirmation. Sometimes User A wants a feature that is a direct detriment to what User B wants. Who is right, and who decides? Or maybe we want to pay for two systems to satisfy both users. Of course if you have a hundred users instead of just two…

Another problem is the cost incurred by complexity. Making software isexpensive. Gratefully, people in our business make a pretty good wage since they're in such demand. It is ironic that making very simple user interfaces often complicates the nature of the software, making it increasingly more expensive. Putting in error logic for every arcane potential failure may be gratifying to the user, but it adds greatly to the cost of developing and testing the system. Certainly we can do this, but there is a cost in development and possibly in performance.

Another problem is that the users often don't know what they want. That's not pointing the finger since the software engineers also don't know what they want. Anyone who has ever participated in the creation of a requirements document (which, by the way, is often done by the users) knows just how difficult that task is. There are, of course, other problems with requirements. During the course of developing the system, the business requirements often change, or the users change, or implementing a particular requirement is more expensive than originally thought. Sure you can have sub-second response time¾that will cost you $1 million¾ or for $500, you can have two-second response time. Is sub-second response time required?

We have come a long way in a short time. The computer business is only a few decades old. Where was the automobile business forty years after the inception of the automobile? Would you be satisfied with the performance of a Model-T today? We're getting better, and we're getting better quickly. Having dissatisfied users helps us to constantly redefine our standards and adapt to what is acceptable in the eyes of the beholder. Unfortunately, we will never satisfy all users just as a modern Ford Probe or a Chevy Corvette will not satisfy all automobile users today. But we will constantly strive to produce the best software possible, or at least good enough to persuade users to purchase our software over someone else's.

[For the complete article, go to businessweek.com/1998/39/b3597037.htm]