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):
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:
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.
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.
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.