The cranky user
On the drawbacks of the overcompensatory user interface
Any seasoned computer or Web application user is familiar with the phenomenon of the overactive user interface -- the UI that notes that you're trying to read an article and proceeds to busily close all the other windows on your desktop, whether you want it to or not. It sends out a virtual flurry of unctuous confirmation messages, double-checking your every decision. It seamlessly corrects your spelling as you type, occasionally introducing whole new words into your vocabulary and more often rendering your syntax incomprehensible.
These are just a few variations on the theme of the overactive interface but most have the same basic motivation: to anticipate and correct user mishaps. While some so-called smart features actually are smart (such as inquiring whether the user really does want to empty the trash before it's done), too many features have an unexpected downside: they encourage more user errors, rather than less.
Take a look at several of these common examples of the overeager interface and its undesired, and often unpredictable, consequences.
Could you please overconfirm that?
One of the most difficult questions in user interface design is confirmation. How much confirmation does a user need? For instance, should every single file deletion get a confirmation request? Excessive confirmation creates two dangers. One is simply that it becomes impossible to get anything done:
Would you like to continue reading this paragraph? If so, please open the file menu and click Confirm.
Confirmation messages that disrupt a user's train of thought or make a simple action into a complicated one do more harm than good. Cleaning up my downloads directory is tedious enough without the added nuisance of being asked, every time, whether I'm sure I want to delete the selected program. I know that deleting the program will prevent me from accessing its associated documents, thank you very much.
The second danger is more subtle. We humans are creatures of habit. If I'm asked to confirm every single act I quickly develop a time-saving response: I click "Yes" (or hit Return) almost before the box has had time to materialize. This can take an unfortunate turn on one of the rare occasions when my time-saving habit kicks in before my brain does, and I've dumped a file I really would have liked to save.
Save confirmations for the important stuff. One rule of thumb is to restrict confirmation requests to irreversible actions. Even better is to provide users with a less disruptive failsafe -- such as the trash can (or recycle bin) that is manually emptied. Users get the satisfaction of dumping unwanted files or programs and a place to dig when they throw out something essential. (Unless, they habitually empty the trash the instant a file is placed there.)
Another important factor in the utility of confirmation requests is how much information they provide. A good one should give enough information and options to let the user learn what he needs to know -- all of what he needs to know -- and deal with it effectively in one or two clicks. Windows 95 had a famous example of insufficient information: the box asking whether you wanted to overwrite an existing file only revealed the version number of one file, not the other. It would tell you whether one was newer or older than the other, but file dates aren't always enough to tell you what's happening. Additional options (such as "Yes to all" or "No to all") can help reduce the time it takes for a user to handle a repetitive task.
The flipside of automation
Automation is one of those double-sided coins of user interface design. On the one hand, it's so nice to know that your computer cares enough to note your preferences and carry them out; on the other, it can result in some awfully confusing and erratic behavior. For example, I use Mozilla's Firefox browser. I figured out a while back that if I paste a URL into any Firefox window, the browser will jump there automatically. That's sort of neat. It took me a lot longer to understand why I would periodically find myself rocket-launched to unknown, undesired, untyped-in sites; often one of those you find squatting on a likely-word domain, hoping to get paid big bucks in the next dot-com boom.
I finally figured out that if I have a single word selected and I accidentally paste it into a window, the Mozilla browser will redirect me to the first Google hit on that word. This happens because my mouse is set up to automatically paste on middle-button clicks, or to use the middle-button to open a new tab. So, if I miss a link by a couple of pixels, and I happen to have a single word in my clipboard, I get routed ... somewhere. Not, generally, somewhere I want to be.
Honestly, I would prefer a forthright error message to this silent, erroneous "correction" of my presumed error. The problem here is that Web browsers are actively targeted at users who don't know how to use them -- novice users who make dumb mistakes and get frustrated if things don't go perfectly on the first or second attempt. Rather than try to train users into better behavior, most browsers just try to make things all better, without ever bothering the user with the messy details under the hood. Consider the fate of wpad.com, whose server is smacked regularly by browsers trying to discover proxies, by looking for a machine called "wpad" in their current domain. (This is a side-effect of Web proxy auto discovery; see Related topics.)
For the record, I'm the kind of user who prefers to correct his own mistakes,and hopefully not make the same one twice. But I know not everyone thinks like me.
Whoops -- my mistake!
Now I come to one of the biggest hurdles in user interface design -- the crux of this column, in fact: Users do make dumb mistakes. Back in the day of the mainframe, users were highly trained individuals who knew enough to tiptoe softly around the sleeping giants in their midst; but those days are long over. Today's desktop encourages such a degree of familiarity that some users really do appear to be computing in their sleep.
I recently ran across a blog entry in which the user described a problem that he was having with a customer service Web page. I don't even know how many people responded to the blog entry with support questions clearly intended for the company whose customer service wasn't serving, and not the blogger having the problem himself. These users seemed to be under the assumption that they were on the company site. My guess is that they performed a search and then typed their problem in on the first form they found, which was unfortunately some guy's blog.
It's a lot of fun to tease users about this, and tempting too. Certainly, the Web is full of pages mocking customers who didn't quite live up to the high intellectual standards of application vendors. But it's important to realize how much useful, clear feedback matters in these instances. The much-derided Internet Explorer error messages, while they have flaws, do at least give the user some idea of what might have gone wrong. It is unfortunate that they do so by denying the user any messages that the other server might have wanted to pass on.
Building smarter users
Trying to outsmart your users is dangerous. It's dangerous when you fail and sometimes even more dangerous when you succeed. The fact is, users will make mistakes and sometimes they should be allowed to fall down as a result. Many systems would be stronger if they were built with more consideration for user failure (such as ensuring that the results aren't catastrophic) and less determination to avoid it.
The most typical automation mishaps are the result of assuming that the most common case is the only one that matters. If a user is 80 percent likely to want a particular logical progression, programmers are likely to automate it. Unfortunately, the other 20 percent of the time, this will leave the user in the lurch, very possibly confused and frustrated about what's going on with the computer or application.
Finally, give users the option of disabling some, if not most, automated features. After all, they're supposedly there to make things more efficient. I suggest that the default is to turn such features off, so the user can seek out the most convenient ones. This might prevent many calls to technical support. It also is a first step toward creating smarter users, or at least ones less utterly mystified by their computer's behavior.
This week's action item: Try making small changes to things you do regularly. How does your system correct for them? Are the corrections what you want?
- Read Peter's take on some common characteristics of user interfaces that work, as well as those that don't, in The Principle of Least Astonishment (developerWorks, August 2001).
- On a related note, learn more about the pleasure principle at work in UI design, with Peter's Everything I need to know about usability, I learned at the arcade (developerWorks, June 2002).
- Visit wpad.com for a good description of Web proxy auto discovery -- both the protocol and its unsurprising side effects.
- Discover that some misleading interface decisions are entirely intentional.
- Check out a related phenomenon -- advertiser use of fake error messages to trick users into clicking.
- Find out how IBM's Global Services Usability Engineering team can help you improve your products and make them easier to use.
- Visit these valuable resources on developerWorks: