These are all valid concerns, but UX is purportedly concerned with serving the user. Reducing expenses is a competing concern. Together, they influence the desi

These are all valid concerns, but UX is purportedly concerned with serving the user. Reducing expenses is a competing concern. Together, they influence the design, but I don't think it follows that removing options leads to a better user experience. It could, but it's not a given. > It's easier to add another option and the keep the previous behavior as default than to do the hard work of figuring out what the best behavior is and then, if the new behavior is better, having the courage to change the default. Having no options is good for discipline as it removes the temptation of doing it the easy way. Ideally, you already knew what the trade-offs are before you built the feature. That should have come out of a user study. Human psychology simply doesn't change as substantially or as frequently as modern UX seems to suggest. Of course, things can fall through the crack and you can learn new things (even that previous conclusions were misguided). But, setting up all options as a choice you need to make for the user isn't necessarily helping the user experience. Some portion of the world prefers a 12 hour clock, some portion a 24. If you're adamant about only showing one of those and it's not configurable, you haven't helped the people with a different preference. You're inflicting your design on people without really taking their cultural norms into account. I'd go a step further and suggest changing defaults on people is something that should never be taken lightly because the user experience isn't a point-in-time thing. Changing workflows on existing users is a negative user experience in many cases. As a concrete example, the ReasonML language forked into another language call Rescript. The code formatting tool in Rescript works almost identically to the one in ReasonML and that's by design, since it's supposed to facilitate migration. But, for whatever reason, the new formatter dropped the option to configure line width. So, if you used to set your line width to 120 characters, too bad. You have to use 80 characters or don't use the tool. Also, you need to chance your workflow and any configurations using the old flag. Having the option to change a numeric variable is not some overwhelming burden. Forcing a fixed value isn't some courageous decision and it's not based on any human factors studies. It feels like an overreach of "opinionated software" that ultimately made my code harder to read (both languages use annotations that artificially increase line length). In the end I abandoned the migration, which I suppose means if they poll community members, they'll have something of an echo chamber. > There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor. This sounds like a failing of software engineering to me. To the extent that this field's raison d'être is to make computers perform work for humans with minimal fuss, our tooling should be geared towards supporting that goal. Dropping functionality that would be beneficial to people because it's more difficult to support sounds like trying to mold people to the machine rather than the machine to people. Certainly, you can have a product that functions, but it's similar to all the other things we have to put up with because a better option doesn't exist. This take isn't drawn from the book I mentioned, but I think the book has influenced my opinion on the matter. If settings/options lead to a better user experience but our tooling and development processes make adding settings/options difficult, we should try to improve our tools and processes. With that said, we have to operate with the constraints we have. I just don't think we should convince ourselves it makes for a better user experience. That sort of thinking tends to snowball.