Settings & UI Cruft
A PM recently asked me, “Should we add a new setting for this feature?” My answer:
Default to no settings!
If we learn that a new setting is really needed/desired by many customers (not just that one big customer that hates change), then add a setting if and only if we can’t make the feature smart enough to not need one.
Someone wants to disable a new feature? Great, let’s jump on a call so we can better understand why, and/or what would make it better for you. You can’t do that as well if you ship settings initially!
Other options:
- Feature flags are only for temporary things, but can be used during testing.
- Internal admin setting: if we’re convinced we really need a setting, but adding one to the UI in a way we’re happy with is too hard, we can add it to our internal employee admin center.
- But this just shifts the burden to Support emails, so it’s not ideal.
UI cruft
UI cruft is sooooo hard to avoid in a maturing product. You must fight back hard, or else every little feature launched in every month in every year for a decade just makes your product more complicated.
What once used to be a simple happy path flow turns into the mess you set out to fix originally when you first started the product. Almost inescapably.
Add in a growing team with specialists responsible for building specific new features and naturally they’ll focus on making that one new feature good/complete (which always means more UI cruft) vs. continually rethinking the entire aggregate experience.
This was originally posted on X in July 2025, along with a follow-up thread on UI cruft the next day.