Preferences Considered Harmful

Every programmer and user interface designer eventually comes to this point: You can’t decide how a specific part of your user interface should behave. It’s easy, of course. Just make it a preference, and everyone will be happy.

After a few years, you will end up with a preference window looking like this:

BBEdit Preferences Window

BBEdit has so many preferences that Bare Bones Software actually included a full-featured search function within the preferences window. At one point during BBEdit’s existence, somebody must have been annoyed with BBEdit’s default window stacking algorithm and requested that it be made a preference. Here it is:

BBEdit's window stacking setting

BBEdit actually allows you to select the window stacking algorithm. I’m sure somebody, somewhere absolutely needed that feature, but by implementing it, Bare Bones Software forced everyone else to also consider that preference when trying to change a setting.

Now, I want to make it clear that I don’t fault Bare Bones Software for this. Their audience is a diverse set of power users. Programmers, writers, sysadmins and other high-end Mac users all use BBEdit for vastly different tasks, which is why BBEdit has ended up with a huge set of preferences.

However, unless you’re working for Bare Bones Software, your product probably is no BBEdit.

For most applications, the target audience consists of — or at least includes — casual users. These users easily get confused by preferences, and they can become frustrated when they attempt to use a familiar application where somebody has changed preferences.

For this reason, it’s best to avoid preferences.

Configurations aren’t Preferences

Not every item you find in an application’s preference window actually is a preference. Before talking more about how you can avoid preferences, I want to define what I mean by the word «preference.» I find it useful to distinguish between configurations and preferences.


When a given feature of your computer needs you to change settings to make it work, this is a configuration. For example, most entries in «System Preferences» aren’t preferences at all. You don’t «prefer» to turn on Screen Sharing; turning on and setting up Screen Sharing is part of your system’s configuration. You don’t «prefer» that only some users have access to your computer’s screen; you configure your system so only some users can access it:

The Sharing Preference Pane


Changing a preference does not change the functionality of an appliation. It only changes the look or (superficially) the behaviour of an application. Often, preferences are introduced to appease a specific group of users. For example, when Apple introduced Mac OS X, a lot of preferences were introduced to make OS X behave more like Mac OS 9.

On NeXT systems, both scroll bar arrows were at the same end of each scroll bar, while on Mac OS 9 and earlier, they were on opposite ends. Instead of deciding on one behaviour, Apple simply made it a preference:

Scroll arrows preference

Additionally, Apple added a hidden preference for those who wanted both arrows on both ends.


There’s one kind of preference that does not make functional changes, but can often increase the user experience tremendously, and that is personalization. Simply having a desktop background of your dog, or setting the lock screen on your phone to a picture of your family can improve the experience of of using a device and convey a sense of «ownership», without actually adding any functional features. In some cases, it can be useful to include a few of these types of preferences in your application or device.

Why preferences are bad

There are several reasons why cluttering the settings windows with unnecessary preferences is bad.

First of all, it is confusing to people who have legitimate reasons for changing settings. If you want to find out how to change your Dock size, you don’t want to work your way through a list of preferences which includes useless settings about how windows look while they minimize.

Often, applications’ preference windows are cluttered and confusing to the point where it becomes unclear whether something can’t be changed, or whether you simply missed the option in the flood of checkboxes.

Second, it makes applications inconsistent. If a user is used to a system where the Finder’s «Always open folders in a new window» setting is enabled, he can easily become confused and frustrated on systems where this is disabled. If a user is used to getting a warning before emptying the trash, he could easily inadvertently delete files on a system where that warning is turned off. And if he is used to a system where the Finder opens blank DVDs, he could quickly get stumped when using a system which opens iTunes instead.

Third, it makes reproducing errors harder. The more preferences there are, the more code paths you generate. Trying to reproduce user issues can quickly become a nightmare if you first have to reproduce specific sets of preferences.

Fourth, it makes development harder. Preferences mean more code and more application states you have to consider when adding new features.

How to avoid preferences

So, if preferences cause so many issues, how can you avoid them?

Say no to users

Sometimes, it’s better to lose a few users than to say yes to every request. Perhaps having pink windows simply isn’t in the application’s best interest, and if not having pink windows means having a few customers less, it may be worth accepting that.

Decide on the best behaviour and run with it

If at all possible, get rid of preferences and go with the most desirable behaviour instead. Often, interface guidelines state how an application should behave. Adhering to the standards not only helps you get rid of preferences, but also helps you be consistent with other applications, which makes your application behave in a manner predictable to your users. If the interface guidelines don’t specify how your application should behave, an ad-hoc usability test should help you decide which behaviour is preferable. Create versions of your application with both behaviour and let some users who have never seen the specific function use the app while you look over their shoulders. Which behaviour do they grasp more easily? Which allows them to work more efficiently?

For most preferences, there is one option which works better. Find out which this is, and make it the standard behaviour.

Remember the application’s state

Often, you can avoid preferences by keeping track of what the user is doing. Instead of letting the user specify default data, remember the most recent actual data he generated. If the user switches to list view to see the items your application presents, open in list view by default the next time he launches your application. If the user opens a window and turns the toolbar off, remember that for the next window he opens. If the user sorts list entries by date, remember that the next time he opens the application. Always remember window size and position, and when the user has to enter data, try to provide reasonable default data.

Be careful not to be too clever, though. Adapting the UI to statistical analysis of user behaviour typically leads to a frustrating user experience, because the user interface becomes non-deterministic from the user’s point of view. Make sure the rules used are always obvious to the user.

If you can’t avoid preferences

There are cases where you simply can’t avoid preferences. If this occurs, make sure you spend time on finding reasonable defaults, and on labeling them in a way which is obvious to users. Document preferences, and if reasonably possible, make it obvious that the behaviour the user is experiencing was caused by a changed preference item. Otherwise, it’s possible that the user may assume there’s a bug in the application if it behaves differently on different systems.

What about an «Advanced» section?

Some applications try to de-clutter preferences by partitioning them into a «regular» and an «advanced» section. Unless some preferences are used vastly more often than others, I would suggest to avoid this because the difference between normal preferences and «advanced» preferences is arbitrary. Your users won’t be able to reliably predict where you have decided to stick a specific preference item. If your users are looking for a specific setting, having an «advanced» section simply means they have to hunt through two screens instead of one.

If you require a short url to link to this article, please use

designed for use cover

But wait, there's more!

Want to read more like this? Buy my book's second edition! Designed for Use: Create Usable Interfaces for Applications and the Web is now available DRM-free directly from The Pragmatic Programmers. Or you can get it on Amazon, where it's also available in Chinese and Japanese.