> Every time you provide an option, you’re asking the user to make a decision.
At least the author differentiates on types of settings:
> There’s a difference between product settings that a product needs to get right by default and preferences that designers deliberately shouldn’t have a strong opinion on.
I can get on board with separating cosmetic choices and non-cosmetic settings.
If you're shipping a product, every setting is a potential bug because you don't test that particular setting necessarily. Worse, every combination of settings is a potential bug. Ideally, settings shouldn't allow you to put your product in an invalid state. That almost always happens with any nontrivial set of non-cosmetic settings however.
I've brought up this example many times but many here won't remember the early days of connecting to Wifi. On Windows this meant answering questions like:
- Encryption type (eg None, WEP, WPA, WPA-PSK, WPA2, WPA2-PSK)
- Passphrase (is this a password? Is it something else? Well, that depends on the encryption type)
- SSID
Apple came along and reduced this to SSID and password.
The principle I take from this is never, ever ask users to enter something that you can figure out on your own. Like you can figure out the Wifi encryption type so why ask?
Another example: why ask me for a state and a ZIP code? The ZIP code tells you the state.
Settings so often fall into this bucket. You have settings for things that don't make sense, that you can figure out the answer to and are dependent on other settings.
Practically speaking, settings become a cultural disease because product and UI/UX people can't agree and someone "compromises" by saying "let's make it a setting" rather than figuring out the right answer.
Design is the art of compromise. Settings are the art of not making a decision.