Choose Good Defaults


Many Web applications offer configuration options at every turn. This usually happens because developers like to offer every available option they can to users even if it makes little or no sense to do so. "If it can be done, it shall be offered as an option," they say. But the better way to go is to choose good defaults, because it improves a user's chances of learning an application quickly and allows her to dive in and start exploring without having to make a bunch of decisions all the time.

Users typically don't want to configure applications and customize them as much as developers would like to believe. In fact, most users stick to whatever defaults they are offered and avoid customizing at all. Choosing good defaults, then, is not only important, it means that the decisions we make while developing new applications are decisions we make for all of our users. Defaults have long-lasting effects, and we must be careful about what we put in front of users by default, as the user's first impression (and all the others after that) is greatly affected by what we decide to show them.

Jakob Nielsen, renowned guru of Web usability, says in "The Power of Defaults" (one of his many revered Alertbox articles):

Users rely on defaults in many other areas of user interface design. For example, they rarely utilize fancy customization features, making it important to optimize the default user experience, since that's what most users stick to.


Doesn't get much simpler than that. Yes, we could try to gather statistics so we have a hard and fast rule to live by, but users don't work that way. The best we can do is use our best judgment and choose good defaults whenever we can in the interest of providing a quality user experience.

Nielsen states in the same article:

System-provided default values constitute a shortcut since it is faster to recognize a default and accept it than to specify a value or an option. In many cases, users do not even need to see the default value, which can remain hidden on an optional screen that is only accessed in the rare case where it needs to be changed. Defaults also help novice users learn the system since they reduce the number of actions users need to make before using the system, and since the default values give an indication of the kind of values that can be legally specified.


Fortunately, many good defaults are built into applications already and can be used as a lesson in how to choose them. Yahoo email doesn't ask if you want to use regular text or bold text every time you start a new message. Google doesn't ask if you'd like to run a Boolean search or a keyword search. And Amazon doesn't ask if you'd like to see its recommendations based on your previous purchases. These are default behaviors, and obviously they're quite helpful.

A good default is one that is most likely to benefit the most people. While there may be options that can be configured at every turn in many applications, the default options should be the ones users would most likely choose if they had to make the choice.

Consider a help system that includes a search box designed to let users search either the help system or the Web, with radio buttons that let them make the choice. Which option should be selected by default? My vote goes for searching the help system. Odds are the user is there to read help articles, so let's show him help articles.

Consider, too, a site-builder tool like Google Page Creator. First, it automatically selects a template for you so you can immediately start designing. Each template also has a default layout, so if you switch templates, you don't have to make another choice at the same time. You can just start building a page. (If you want to change layouts later on, you can do so without damaging the work you've done in the original layout.) Default fonts and font sizes are used for headings, subheadings, and body text. When you import images, default dimensions are chosen (which you can immediately change via the inline tool-bar). Filenames are also assigned by default based on the name you choose as a heading for a page.

Google Page Creator makes one decision after another for me, so I'm free to be productive instead of being forced to make decisions at every step.

See how many times I said "default" in the preceding paragraph? Sure, you can change anything you want, but defaults get you moving. Fast.

Many developers latch onto the idea that users should have every option available to them. But people don't work like that. We'd rather get something done efficiently so we can move on to something else. Decisions get in the way. Options, settings, choicesthey all get in the way. For software to be most effective, it needs to get out of the way. Choosing good defaults accomplishes this goal.

Integrate Preferences

The real goal behind choosing good defaults is not necessarily to get rid of settings and options completely, but to show logical settings by default while still offering alternative settings when they're needed. When this is done well, we can make things even easier by integrating the settings users will likely want to change into the main application screens.

Settings are often best presented in the context of the application itself. Instead of relegating them to a settings screen full of options where users cannot readily see how a setting affects the application, settings can be integrated seamlessly into main application screens and handled inline. For example, default options that can be changed can be shown alongside a Change This link that reveals a way to change the setting without leaving the page via an inline form or other widget.

Browsers have evolved enough that they now are usually capable of handling desktop-style interactions. With DHTML (JavaScript, CSS, and HTML), and support for the XMLHTTPRequest object (the core of Ajax, or Asynchronous JavaScript and XML, used to retrieve new data on the fly), chunks of code can be generated dynamically and inserted into an application screen on demand to display controls not available when a page is first loaded. Leveraging this approach, we can dump functionality and information into a page without directing users to remote administrative screens, and give users a way to change settings without leaving a page or losing context.

By all means, include settings and configurable options if you think people will want them, but don't force users to make decisions at every step. Make decisions for themlong before they ever see the applicationthat help them get up to speed. If they want to change things, they will. Just let them get their hands dirty first.



Designing the Obvious. A Common Sense Approach to Web Application Design
Designing the Obvious: A Common Sense Approach to Web Application Design
ISBN: 032145345X
EAN: 2147483647
Year: 2004
Pages: 81

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net