The “Decisions, not options” philosophy argues that giving users too many options can make tweaking a piece of software a difficult and frustrating experience. When a user wants to make a small change, and they find themselves presented with five pages of disorganized options, many will simply give up rather than wade through each one looking for what they want. So, instead, developers should only provide options for the core functionality, and make the rest of the decisions for the user.

I completely agree that presenting a user with a cluttered page containing dozens of options is a UI nightmare, and a problem that developers should try to solve. I don’t think that making decisions on behalf of users is a good solution to that problem, though. When developers make the decisions, it takes control away from the user and unnecessarily places artificial restrictions on what they can accomplish and how they interact with the program. We shouldn’t assume our users aren’t capable of making these decisions, or that one size fits all. Allowing users to customize the interface and behavior of an application can mean the difference between something they only tolerate using and something that they love to use.

Instead of making decisions for them, we should give users as many options as we reasonably can, but we should do it in a way that isn’t hard for them to work with.

In addition to having sensible default values, I think options should be presented in three different layers, each corresponding to the user’s experience and comfort level. Each set of options can be placed on separate pages/tabs/windows/whatever so that users don’t feel overwhelmed.

1. Basic options: This would be the first screen presented to users opening an Options page. It would only have 5-10 of the most common and important settings.
2. Advanced options: This would contain an additional 10-20 options that many users tweak at some point during the application’s lifetime.
3. All options: This would be a complete list of every single option available, and most would be ones that normal users never touch. It would be intended for power users and could work similar to Firefox’s about:config page, including warning the user that changing things without knowing the consequences could break their site.

The settings on each of those pages should also be logically grouped according to function, with section headers so that users can quickly scan the page to find what they’re looking for.

Additionally, those pages should have a JavaScript-driven search feature to help users quickly find what they’re looking for. It should search the option name, description, and any common aliases that a user might enter.

With this approach, you keep things simple for new users, and those who only care about the core functionality of the application, but you still let advanced and power users tweak the behavior to make it suit their exact needs.

Making software easier for users is a great goal, but we shouldn’t do it at the expense of flexibility and customization.