Settings are not a design failure

Most people don&#x27;t love fiddling with settings. People love when software does what they need, and some of them will be willing to fiddle with settings if they have to. Settings are a cost the user pays (just like data entry, loading times, hard drive space, loss of privacy, ads, or the monetary price of the software) in order to get the value. If good defaults mean most users don&#x27;t have to muck with settings, great, your software is now more valuable. But the only thing worse than having to tweak a setting to get your functionality is <i>not</i> being able to get your functionality at all.

When I was an engineer on Microsoft Office, users would often request features that the product already had. It was great that their problem was quickly fixed (just point them to the right setting), but it shows the lack of discoverability that happens when the list of settings gets long and you have to dig for them. If you can do the right thing automatically and avoid having a setting, that is an improvement.<p>My other observation was that everybody said Office had too many features and then asked for two more.

That is is even a <i>question</i> shows how broken this entire field is, and is everything I <i>hate</i> about modern software development.<p>It <i>really</i> should not be the goal of &quot;design&quot; to try to create &quot;one experience fits all,&quot; because when you do that you create the lowest common denominator, the dumbest experience possible.<p>If you care <i>at all</i> about allowing grownups to do grownup things with their software; if you care that people should be allowed to push themselves to their own technical and mental limits in order to get things done in a good way for them at all, then yes, you need to allow for things like &quot;settings.&quot;

Search options for settings. When done correctly, it helps a lot.<p>For example, in IntelliJ (and other jetbrains products) you can open settings and search for almost anything. It will search in headers, options, values... And you can quickly find what you need, from the hundreds or more settings available.<p>On the other hand, on Android you can also search, but not only takes very long to actually search, it also duplicates entries and often never finds what you want.<p>But I guess the main issue is that the ability to search settings requires special base structure that you need to develop from the beginning, but when you start programming the number of options is small and you don&#x27;t think about adding search until it&#x27;s late.

I am surprised by the settings skepticism in this thread. By insisting that preferences&#x2F;settings are indeed a design failure, many here are missing out on relatively easy user delight wins. I think there is an illusory adversarial relationship between good defaults and having user-configurable settings.<p>Having the ability to configure settings does not need to, and indeed should not, supersede having good defaults. Windows Explorer has the <i>ability</i> to hide file extensions, but that should not be the default.<p>Instead of removing settings, some design tactics I&#x27;ve found useful in building software:<p>1. Provide multiple default settings profiles. E.g., beginner, advanced, and expert. The problem with a single, rigid configuration is that you can&#x27;t satisfy all user types. On the other hand, acknowledging that not every user wants to fiddle with settings, providing a quick way to more closely match their needs via multiple default profiles is a win.<p>2. Always provide settings import and export, or some form of settings synchronization between instances. One of the main reasons users don&#x27;t use settings is that they are exhausted by having to re-apply all of their preferences every time they install your app. I&#x27;ve installed Firefox about a hundred times across many computers. If I had to manually adjust it to my preferences, re-install and configure add-ons, and so on, I&#x27;d just give up and use more of the defaults. The idea of having to re-train NoScript alone is unbearable.<p>3. Provide better descriptions of what settings do and why they are offered. This can be inline help within the settings dialog or &quot;show me&quot; buttons, or whatever. A good example you&#x27;re probably familiar with are video game options panels that say things like, &quot;Enabling this may help increase framerate in the following circumstances: ...&quot; Firefox is similarly pretty good about this. But many apps don&#x27;t give the user much explanation for settings, adopting a more &quot;if you know, you know&quot; attitude. Don&#x27;t assume that because your user is a &quot;layperson&quot; that they can&#x27;t understand what your app&#x27;s settings do if you take the time to explain them.

We&#x27;re finding that having settings has helped us siphon customers from our competition. Love sitting in on sales demos and hearing the prospect go, &quot;You let me control that? Thank you!&quot; or &quot;I can chose my colors? I love it!&quot; Delighting customers and users... that&#x27;s where you want to be.

I love settings.<p>I hate <i>losing</i> settings and having to fiddle with everything all over again.<p>I remember, back in pre-windows XP days, me and some of my friends would spend ages going through the appearance options and customisimg pretty much everything. Even later, I knew of people who had a meticulous desktop ordering or spent substantial amount of time ordering favourite icons in the browser.<p>All that was great fun until the first time, the settings were lost. Maybe you had to reinstall the OS (or got a new PC) or maybe the program updated and simply erased the settings. In any case, trying to <i>redo</i> everything you had arranged before looked to be an enormous amount of work and not fun at all. So after the second time, this happened, we gave up and accepted the standard.<p>But this eas not because we didn&#x27;t want customisation, it was because the experience was too frustrating.<p>My impression is that in modern UX, not only do opportunities for customisation become less and less, the results are also increasingly ephemeral. E.g., there is still no option under Windows to save the arrangement of desktop icons - but there is a menu shortcut which will instantly rearrange everything and render your own arrangement moot. I think this shows a pretty clear priority of the designers.<p>My impression is that customisation opportunities are simply conflicting with a lot of priorites of moders software <i>developers</i>, much more so than their users: Companies want the freedom to frequently change the UI and control overy tiny detail about the &quot;experience&quot; - customisation runs directly counter to that. In some extreme cases, companies even want the freedom to build deliberately <i>unpleasant</i> designs (dark patterns).<p>Additionally, an inflexible UI also provides more opportunity to present some minor improvements as significant new features (&quot;twitter now has <i>three</i> different colour schemes!&quot;, &quot;iOS now can show <i>two</i> apps at the same time!&quot;).<p>Last but not least, an inflexible UI lets you actually <i>sell</i> certain adjustments as a premium feature - e.g. YouTube letting you listen to a video in the background.<p>All of this are strong incentives for software companies to get rid of settings, but none of it has to do with users not liking settings.

I&#x27;m gonna stop the author right here:<p>&gt; First of all, remind yourself that users love settings.<p>&gt; Despite initially being born out of the absence of airplane WiFi, I actually enjoy discovering new settings on my iPhone that will make my life easier or improve my productivity.<p>&gt; Just look at your own user behaviour: What do you do when you set up your new computer?<p>&gt; You change your background image.<p>&gt; You adjust your mouse speed.<p>&gt; You set a default browser.<p>&gt; You make all of those rearrangements not because the operating system is badly designed. You make them to create a more comfortable environment. To feel more at home.<p>Because he is a designer, or a somewhat more technical person, he may love fiddling with settings, but the vast majority of people do not. They do not change their mouse speed, their background image, their default browser. That&#x27;s why a meme exists of people thinking the internet is the blue E icon on their desktop.<p>As a corollary, that is why defaults are so powerful, as evidenced in the book Nudge [0]. If you have sensible defaults, you can make users do actions that you want them to do, such as putting out fresh fruit in a cafeteria closer to the reach of the user than junk food which might be farther away, which increased the number of people eating fruit.<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Nudge_(book)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Nudge_(book)</a>

The biggest thing with settings pages is stop redesigning them. If I&#x27;ve figured it out once I don&#x27;t want to have to again!

&quot;First of all, remind yourself that users love settings.&quot;<p>[Citation needed]<p>Just like for any UX debate: _it depends_. The level of customization needed depends on the type of app, the type of user, the type of use case.

The author is correct, but it&#x27;s sad that he had to say that.<p>I am not thrilled with &quot;inviolate rules of thumb,&quot; as a general principle.<p>Don&#x27;t get me wrong. I have been doing what I do for a very long time, and have developed a huge library of habits, practices, and heuristics, in my work.<p>It&#x27;s just that I treat them as <i>guidelines</i>, as opposed to &quot;Thou Shalt Not&quot; commandments. If an old or obscure pattern fits the bill for what I am doing now, I use it. If the problem looks, but is not exactly, like an issue that I have solved in the past, I will see if I can adjust the old solution to fit today&#x27;s conundrum; even if the old solution is in a &quot;Thou Shalt Not&quot; area. If a current <i>buzzword du jour</i> is nonsensical in my work, I don&#x27;t use it; no matter how good it looks on my CV.<p>Basically, because of my experience, I am allowed to color outside the lines.<p>A lot of times, I need to look at what others have done, and, if I am not an expert in their field, I have a lot less flexibility in what I can do.<p>For example, in the app I&#x27;m developing, the core functionality is pretty much done, and it&#x27;s time to start gussying it up, putting some lipstick on the porker, theming it, what-have-you.<p>I was originally trained as an artist, but that was a long time ago, and my stuff tended to have a rather &quot;prime color&quot; palette. Think &quot;Magpie on LSD.&quot;<p>I don&#x27;t trust my own design sense, when it comes to a palette. I need to look at what others have done. I won&#x27;t be able to deviate much, as I don&#x27;t have their design sense. I don&#x27;t do &quot;subtle,&quot; too well...

&gt; <i>One of the small preferences we introduced in the Linear app is not displaying the mouse cursor pointer over links. We want to mimic the feeling you natively have on the desktop with our Mac app.</i><p>Hmm. This might actually be an example of settings as a result of design failure.<p>The text in the screenshot describes the setting as applying not just to links but to &quot;any interactive element&quot;. But most native desktop apps (which they&#x27;re trying to mimic) would use a special cursor for links and a regular mouse cursor for other interactive elements, so it seems that (by entangling links and other interactive elements) the setting allows a choice of two incorrect behaviours instead of just behaving correctly by default.

One of the first things I do when I install a new app or programme is open the settings and have a look around.

There is a difference between “the app has a pretty UI to set something” and “this setting is configurable”.<p>One of the great things about the Mac is that there is always the option to defer certain advanced settings to the `defaults` program on the command line (or just things you want to make configurable but do not yet have time to extend the GUI). So if you <i>want</i> a somewhat-streamlined UI with just a few of the most common options, you can do that without completely sacrificing the ability to expose the rest somewhere else.

One of the reasons I love the KDE desktop environment on Linux is because it has settings available to customize nearly <i>everything</i> about it, <i>but</i> it has <i>good default settings</i> out of the box, so you don&#x27;t <i>have</i> to customize much, but any time you <i>want</i> to customize something, you can go dig around in the settings and find it and change it easily to fit <i>your</i> needs. That&#x27;s honestly the way it <i>should</i> be. Good settings by default for users who like to just use things as they are, but options readily <i>available</i> to easily change things if you <i>want</i> to.

I <i>love</i> settings. It is the first thing I open if I start a new program. It tells me about the maturity of the program. Whether it is a toy or something really well thought out.

I had a realisation a while ago that one of the first things I do when I start using a new app, or after a significant update, is to look at the settings. It gives me a feel for the &quot;functionality space&quot; of the application and helps me visualise its &quot;boundaries&quot; somehow. Different ways of presenting properties seem to make this harder or easier: I find Android to be less good and (for example) Visual Studio and Lightroom to be better. I&#x27;m not sure why.<p>Does anyone else do this?

I mostly disagree with this. To quote Joel Spolsky [1]:<p>&gt; Every time you provide an option, you’re asking the user to make a decision.<p>At least the author differentiates on types of settings:<p>&gt; 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.<p>I can get on board with separating cosmetic choices and non-cosmetic settings.<p>If you&#x27;re shipping a product, every setting is a potential bug because you don&#x27;t test that particular setting necessarily. Worse, every combination of settings is a potential bug. Ideally, settings shouldn&#x27;t allow you to put your product in an invalid state. That almost always happens with any nontrivial set of non-cosmetic settings however.<p>I&#x27;ve brought up this example many times but many here won&#x27;t remember the early days of connecting to Wifi. On Windows this meant answering questions like:<p>- Encryption type (eg None, WEP, WPA, WPA-PSK, WPA2, WPA2-PSK)<p>- Passphrase (is this a password? Is it something else? Well, that depends on the encryption type)<p>- SSID<p>Apple came along and reduced this to SSID and password.<p>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?<p>Another example: why ask me for a state and a ZIP code? The ZIP code tells you the state.<p>Settings so often fall into this bucket. You have settings for things that don&#x27;t make sense, that you can figure out the answer to and are dependent on other settings.<p>Practically speaking, settings become a cultural disease because product and UI&#x2F;UX people can&#x27;t agree and someone &quot;compromises&quot; by saying &quot;let&#x27;s make it a setting&quot; rather than figuring out the right answer.<p>Design is the art of compromise. Settings are the art of not making a decision.<p>[1]: <a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2000&#x2F;04&#x2F;12&#x2F;choices&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2000&#x2F;04&#x2F;12&#x2F;choices&#x2F;</a>

This article, and many of the comments here, commits a central mistake: declaring things to be true with no evidence. &quot;Users love settings.&quot; Umm, prove it. Even more glaring, the author goes on to use his own anecdotal story to make his point. If there&#x27;s one thing I&#x27;ve learned in decades in software development (and there&#x27;s not), it&#x27;s that my opinion is not a satisfactory proxy for &quot;what everyone thinks&#x2F;does.&quot;

Who is saying settings are a design failure? I&#x27;ve never heard of that before.

The other reason for settings seems to be turning off things that the UI designers insisted on, but which all actual customers hate.<p>See the display density (amount of whitespace) option in Salesforce for an example of this.

It&#x27;s a common antipattern to design away settings, and practical usability, with artistic purity. OTOH, providing an endless jumble of uncommon settings is overwhelming to almost everyone.<p>1. Make things work in the common-most use-cases, for power users and novices. I think there&#x27;s a lack of respect shown to people who have difficult, edge-case, real problems to solve, like batch receiving orders while being forced into narrow pagination and sparse layouts suitable only for casual customers. Usable search and bulk actions are needed in more contexts than originally assumed.<p>2. If someone asks for it, there could be 100 who didn&#x27;t speak-up but also want it.<p>3. Organize and explain settings succinctly.<p>4. Have a reset to defaults option.

&gt; While I was reorganizing my phone, I had a sudden realization: Settings are typically seen as the result of design failure. The thinking goes that as designers, our goal is to create product experiences that don’t require any adjustments by the user. Consequently, offering customization options is interpreted as a failure to make firm product decisions.<p>I wonder if the author has ever considered how much users hate when things arbitrarily change as designers try to figure out what the One True Product Experience should be. (Or, more likely, try to optimize some metric management is unhappy about.)

It is both possible and desirable to build into a product a strong set of assumptions and useful defaults which can be easily overridden when your assumptions do not hold for every case.<p>The problem with settings and option flags is when a user needs to set a great deal of them to get anything done. Smart defaults for the common case are useful. Overrides for the uncommon case expand that utility to more cases. These two ideas are not mutually exclusive. They are, in fact, a pragmatic and helpful combination.<p>Have defaults. Allow overrides of them.

My take: Settings are a last resort. The more settings you have, the less likely a user is to actually find the one they need. So some settings are good, but too many are bad. E.g. dark mode is a setting that just makes sense because different users have different preferences. But it&#x27;s quite easy to measure what settings almost no one is using, and to axe those. In other cases you may be able to figure out a smarter way to offer the functionality without a checkbox hidden away in a settings page

&gt; Settings are not a design failure<p>When have settings ever been considered a design failure?

Users love settings for things they care about… and abhor and ignore settings on things they don’t care about.<p>Better get your defaults right. That is: don’t force your users to answer questions they don’t know the answer to.<p>Also, partition your settings by user concern… that is, don’t confront your users with a bunch of questions they don’t understand or care about (even if the defaults are right).

In some cases they are. Global config needed to support a local module(As in a PHP app depending on proper Apache conf) kinda sucks because it can create conflicts that can only be solved manually or with a container.<p>Settings that can&#x27;t be done via GUI suck. I shouldn&#x27;t have to dig through some other app and copy and paste an IP address to use your thing.<p>Settings should not have to change for common activities. US vs Metric should be a document property. I should not have to change settings to properly view a certain document.<p>Settings without sane defaults suck too.<p>A good setting is &quot;Here&#x27;s a discovery server, but you can change it&quot;. A crappy setting is &quot;Select an API version for this global daemon that 5 other things use, and only 3 can work at the same time&quot;.<p>Anything that can by dynamic and autodetected... probably should be unless there&#x27;s a really good reason.

Being able to change settings is fantastic. ResEdit taught me that being able to do more than that is even better.

I love settings, browsing the settings screen gives me a feeling about how mighty a software is. Software without settings is usually very shallow, only supporting a handful of usecases. But in the modern SaaS world, they still want to charge 5 bucks per month. No thanks.

No one mentioned video games settings?<p>It&#x27;s a solved problem there, have profiles : &quot;Low&quot;, &quot;Medium&quot;, &quot;High&quot;, &quot;Ultra High&quot;.<p>They allow for a quick start, then as the user is more aware of the feature, the user can tune the predefined profiles themselves.<p>You can have independent profiles for each independent feature : input profiles (keyboard&#x2F;gamepads), graphics profiles, audio profiles, etc<p>For example, on a Google account, that would be a single drop down list with those options: &quot;Private and no personalized experience&quot; (everything turned off), &quot;Private with personalized experience&quot;, &quot;Public&quot;

I think the author might be concluding too much from a period of boredom. Shouldn&#x27;t we design tools primarily for busy, distracted people who have better things to do than mess around with our UI?

Just a little bit dumbed down, but this is the absolute correct take. Settings are design features, not bugs. Settings are beneficial to diverse kinds of humans.

Using the word &quot;Settings&quot; is a design failure. For example, when I right click on my so-called modern desktop, there is a longish drop down menu with a &quot;Desktop Settings...&quot; menu item in it which goes to a window named &quot;Desktop&quot; and defaults to the Background tab. On my more antiquated OS, the menu item is named &quot;Change Desktop Background...&quot; which seems more obvious &#x2F; discoverable.

Spend time to design the defaults.<p>Make sure that most users won&#x27;t ever have to change a thing, but always, always have the settings, and always mark what the default value is, so if someone messes it up, they can find their way back.<p>Forcing the user to make decisions because it was hard or annoying to find a good default decision is why some people have come to hate settings.<p>I hate being forced to create a configuration. I love being allowed to change one.

“Users love settings”<p>Author then goes on to talk about their own personal love of settings and does not offer any evidence that their actual users want settings.<p>Whether settings are good or bad depends ENTIRELY on your specific users and their specific needs. Blanket statements like this based entirely on one particular designer’s feelings are not particularly convincing.

Oh, well that&#x27;s good. We have one or two or hundred settings... <a href="https:&#x2F;&#x2F;docs.fastcomments.com&#x2F;guide-customizations-and-configuration.html" rel="nofollow">https:&#x2F;&#x2F;docs.fastcomments.com&#x2F;guide-customizations-and-confi...</a>

A good &quot;setting&quot; is something that&#x27;s part of the normal UI. Take brush size in Photoshop as a simple example.<p>You obviously don&#x27;t want to set that in some control panel. So you just integrate it into the main UI.<p>I think one should strive to do the same with most settings.

The thing I most dislike about settings is that many products once they create settings for a thing then don&#x27;t put thought into sensible defaults with the logic, &quot;oh they can just change that&quot;. So in a way settings can be a crutch.

Does he understand the idea right? The program shouldn&#x27;t require a change in settings in order to work: it should have reasonably workable default settings. This doesn&#x27;t preclude customization at all.

Is it just me or does the website flash with content for a second which is then replaced with a fake &quot;Not found&quot; display?<p>I&#x27;m on my phone so I&#x27;ll not debug anything right now.

Design tip: don&#x27;t load a 4000px image into a 800px container, it&#x27;s very wasteful for everyone involved. Or maybe provide some settings so I can adjust it? :)

It&#x27;s nice to have settings, but you also absolutely need to have defaults which work for the vast majority of the user base who will never open the settings menu.

settings are also a great resolution to behind-the-scenes design conversations<p>in particular the classic &#x27;PM wants to incentivize a flow, developer thinks it will be annoying as shit and threatens to throw phone out the window&#x27;<p>&#x27;let&#x27;s make this a setting to see if people turn it off&#x27; is my favorite compromise for these. (Also simplifies phase two of a gradual rollout, because jealous early adopters can turn the beta setting on manually)

Every time an application (i.e Firefox) removes a feature due to &quot;low user adoption&quot; I feel the extents of this kind of UX misunderstanding.

settings are also a liability, a form of technical debt. When you add new settings you have to make sure it works with every (logical) combination of other settings. And you need to keep doing it in the future possibly forever because users hate settings being removed. So, your tests get bigger, adding new features and especially settings becomes costlier.I try to avoid it as much as I can

Don&#x27;t make me tap the sign.<p><a href="https:&#x2F;&#x2F;ometer.com&#x2F;preferences.html" rel="nofollow">https:&#x2F;&#x2F;ometer.com&#x2F;preferences.html</a>

Side note: linear’s website especially the home page, makes my iPhone 11 crash when zooming in and out. Firefox Daylight 39.0 (6519)<p>Crazy.

Cramming a big pile of &quot;settings&quot; into your program because you are unwilling to make choices about how things should work is shirking your job as program author&#x2F;designer, and passing the work along to your hapless users.<p>In many cases something that is a &quot;setting&quot; could be better handled some other way. (For one thing, only a trivial proportion of users are ever going to actually examine your setting page.) You should strive to find another solution first, and only add a new setting as a last resort.<p>This is not to say users shouldn’t be allowed to modify the way things work. Allowing customization of keyboard shortcuts and menu layouts, letting users write or install plugins&#x2F;extensions, including powerful abstractions that can be combined in unanticipated ways, etc. can all be very helpful.