Cramming a big pile of "settings" into your program because you are unwilling to make choices about how things should work is shirking your job as program author/designer, and passing the work along to your hapless users.
In many cases something that is a "setting" 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.
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/extensions, including powerful abstractions that can be combined in unanticipated ways, etc. can all be very helpful.
What you're saying is the orthodoxy among designers.
The author of this article is saying they disagree with that orthodoxy.
I don't think it's helpful to just repeat the orthodoxy without saying more.
In particular I'd be very happy never to see the claim "people only add settings because they're shirking their job of making a decision" again. I don't think it's true, and I think it's impolite to make such a claim without justification.
Is it? I see an awful lot of overwhelming pointless 'settings' crammed into weird corners all over the place, sometimes in ways where the default experience is just broken and long-term users just all learn they need to tick the appropriate settings to have an acceptable experience. Over time the settings proliferate and the settings page just becomes a dumping ground. Maybe designers (or project managers) need to take this 'design orthodoxy' more seriously.
The author’s own screenshots show a settings page with like 15+ separate pages of miscellaneous settings. Maybe there’s no other way to solve the design challenges in his app, but I doubt it. When he claims that “users love settings [...] just look at your own user behaviour,” he’s projecting his personal preference/compulsion for testing and analyzing trivial tweaks (maybe as a way to procrastinate from actually using the tool? or because thinking about tool design is more interesting to him than tool use?) onto other people.
E.g. when he suggests “Some details become annoying because they are so repetitive” the easy answer is: just cut those out! Why should users have to hunt around obscure corners of your tool for a way to eliminate the annoying gimmicks you added?
Note that it is entirely possible to have a very flexible, powerful set of tools that satisfy a wide variety of niche needs while having those tools available to all users in a sensible way, without any need to hunt through the "settings" page to access them. It just takes a lot of design effort to figure out how to break down user goals into parts, abstract them, make tools capable of handling those, and then teach users how to use them.
But trying to solve tool design problems without the crutch of adding extra checkboxes to your settings page doesn’t mean you have to cripple the software or prevent people from using it in their own way.
Trust me. I have gone through every settings page on iOS, WP, Samsung, Android and many more.
All of them were necessary. You would be surprised at how many non engineering people using android samsung have non designer approved fonts and themes.
> In particular I'd be very happy never to see the claim "people only add settings because they're shirking their job of making a decision" again. I don't think it's true, and I think it's impolite to make such a claim without justification.
Reading carefully, I don't think OP made this claim exactly. I suspect all three of us might agree that there are good reasons to add settings and that we should be careful of adding them for bad reasons.
I think in many cases a setting gets added not because an individual /refused/ to make a decision but rather because no individual was /empowered/ to make the decision. I find it easy to imagine a meeting (perhaps a meeting with too many participants) that gets deadlocked on some question and the only apparent way to get out before lunch is to compromise on making it a setting. And maybe compromising the design is the best way to go, but then that's how it will be.
Is it really fair to your users to presume the are clueless? Is it a good idea to take all decisions from them, and rob them of the ability to become a designer?
I have a suspicion that this is a self-fulfilling prophecy: take away agency, and you'll end up with a demographic which never wanted any.
> Is it really fair to your users to presume the are clueless?
The more charitable interpretation is that we should assume they're overloaded; they're using our application because they have to get something done, and they need to get it done as quickly and easily as possible so they can get on with their day. This doesn't always apply; if you're developing an application that will be the primary tool for some line of work, something that people will live in for hours every day, then it makes sense to give them the freedom to make it their own. But when developing something that will merely be part of someone's workflow, possibly imposed on them without their choice, then it makes sense to impose as little as possible on them.
Good. If you take away something and users don't care, it wasn't important or necessary. Perfection is achieved when there's nothing left to take away.
You measure. You measure how often that setting was used, you analyze behavioral changes before/after, you measure retention changes, you measure complaints & feedback.
I agree that you can get momentary insight into changes, but that doesn't help you understand if you are indeed alienating potential users, for two combined reasons.
First, you can't measure the preferences of those who never were your users, or those who already dropped out.
Second, software is not static, and whenever you apply changes to it - including those not related to UI - its utility to different demographics changes. And you can't know how much of the new demographic would be your users if your software had a diffrent UI.
So while you can measure the impact of UI changes on your userbase via behaviour analysis, you can't find out whether you're excluding potential users this way.
In many cases something that is a "setting" 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.
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/extensions, including powerful abstractions that can be combined in unanticipated ways, etc. can all be very helpful.