- Use Visual Elements Sparingly
- Make Common Tasks Visible; Hide Infrequent Tasks
- Give Feedback; Show Signs of Progress
- Keep Preferences to a Minimum; Give Smart Defaults
- Follow Conventions (Even If They're Not Your Ideal Design)
- Look for "Widgetless Features"
Keep Preferences to a Minimum; Give Smart Defaults
Many programs offer Preferences or Options that allow people to specify how they want the user interface to operate. Usually, applications offer Preferences because the development team disagrees on what "most people" will want (usually because the team members want different things), so they decide to allow each user to choose. The Preference is offered as a gift, giving people the freedom to choose how they want the application to behave. While the sentiment is laudable, Preferences are about as heavyweight as you can get in terms of imposing mental effort on the user. Remember, most people just want to focus on their task. When you ask them to pop out of their task to focus on how the program operates, you're asking them to do some serious mental work.
You're also working against people's expectations. Most technology can't be molded to each person's needs, so people don't think they can change the way something works. (You can't just flip a switch to make a can opener left-handed; you have to buy a left-handed can opener.) Also, most people aren't aware that the user interface is distinct somehow from the application and can be changed to suit their needs. Yes, people will change the appearance of an application, perhaps by modifying the color scheme or applying a "skin," but rarely do they modify the behavior. If they keep bumping their heads against the same problem over and over again, their tolerance capital declines each time. Even experts who realize that they can modify a program usually struggle and complain about a problem until it gets so painful that it dawns on them to check the Preferences to change it. (Ellen confesses that it was two years after she got a new Windows PC that it occurred to her to see whether she could set the default folder where Office applications save or open documents. She had been annoyed each time it offered to save a document in My Documents, which she'd never used. Even though she was aware that she could modify Preferences, it took a lot of effort to "pop out" of the task and think about looking for a remedy in the Preferences.)
You should assume that almost no one will change Preferences that modify the system's behavior. So be careful about choosing the default behavior because for most people, it is the program's behavior. Some tech-savvy users do make use of Preferences, but unless the product is primarily for them, take care of most users' needs before offering them options. Here we return to the idea that you should focus on the common case for most people, not what some people might want to do in some situations (that is, edge cases).
Figure 3.12 shows just one of dozens of Preference sheets from ICQ, an instant messenger. Rarely would it occur to someone to change an item. Consider "Display Email notification on Contact List if Email is assigned to user." Most likely, if someone weren't noticing their e-mail, they wouldn't think to look in the Preferences to find the problem. This window has a scrolling list of categories on the left that change the display on the right. Some categories have subcategories, displayed in tabs. It's hard to believe that the amount of work that went into offering these hundreds of Preferences could be justified by their usage.
Figure 3.12 This is just one of dozens of pages of Preferences for ICQ's instant messenger. Each item in the list on the left displays a set of Preferences on the right, some of which have multiple tabs. Most people stick with default behaviors and never look at the Preferences, so much of this is wasted effort. Usually, the presence of a lot of Preferences in a program indicates that the development team couldn't decide on the right behavior.
Your goal should be to have no behavioral Preferences. You may not achieve it, but it might help you think harder about whether "We'll make it a Preference" is really a good solution.
Design Guideline
Treat "We'll make it a Preference" as a copout. The default behavior is the application's behavior, since few people ever modify Preferences that affect the behavior of the application. Use Preferences mainly to allow people to customize the application's appearance.