Designing Settings Pages That Don't Become a Junk Drawer

On a project management SaaS product we've maintained for a client since 2021, the settings page grew from twelve options to over sixty across a couple of years, one feature launch at a time, each addition seeming reasonable in isolation. By the time we did a usability audit, users were spending an average of over a minute just scanning the page to find a specific toggle they'd used before, because nothing beyond a single flat alphabetical-ish list separated the settings anyone touches often from the ones almost nobody does.

We restructured around frequency and consequence rather than feature area, which had been the original organizing logic. High-frequency, low-risk settings, like notification preferences, got a prominent, easy-to-scan section near the top. Low-frequency, high-consequence settings, like data export or account deletion, moved to a clearly separated danger zone that required a deliberate scroll or navigation to reach, on purpose, since these shouldn't be one accidental tap away from the settings someone checks weekly.

The harder discipline was upstream of the redesign: we introduced a rule that any new setting proposed by a feature team needed a default that worked for the vast majority of users without ever being touched. A setting that exists because a product team couldn't agree on one default is usually a sign the decision wasn't finished, not a genuine user need. We pushed back on several proposed toggles this way, and most of the time the team came back having just picked a sensible default instead.

For the settings that did need to exist, we grouped related toggles under a single expandable heading rather than listing them all flat, which cut the page's apparent length substantially without removing any actual functionality, since most users only ever expand one or two sections in a given visit. Search within settings, which we'd initially considered unnecessary for a page 'that small,' turned out to be one of the most used features once the page had grown past around thirty items.

Time-to-find for a known setting dropped by more than half after the redesign, based on follow-up testing, and just as importantly, the rate of new settings getting added without a default review dropped too, because the process now made the cost of a new toggle visible before it shipped, not just after the page had already become unmanageable again.