Settings pages that don't sprawl

Settings pages are the warehouse where every feature that didn't have a home in the product goes to die. Year one, settings is a five-row form with avatar, name, email, password, notifications. Year three, it's 47 sections across six tabs, three of which were added by features that shipped and were never tested in production, and the search input you didn't ship is the most-requested feature in support.

The fix isn't a redesign every two years. It's picking a structure up front that scales, and writing down a small set of rules that decide where new settings go before anyone has to argue about it.

The structure that scales

Three layers, almost universally. Once you internalize the three, you stop arguing about where things go.

1. 01Account. The user themselves. Name, email, password, 2FA, sessions, danger zone (delete account).
2. 02Workspace / Team. Settings that affect everyone in the workspace. Members, billing, integrations, plan, workspace name, domain.
3. 03Product preferences. Per-user settings about how the product behaves. Theme, notifications, default views, keyboard shortcuts.

Almost every setting fits into one of those three. The argument every team has, "is this a workspace setting or a product preference?" is settled by asking who else it affects. If it changes things for other people, workspace. If it only changes things for you, preference.

Sidebar vs tabs vs a single page

Three layouts, picked by content volume:

Single page

For products with fewer than ~20 settings total. A single vertical scroll with section headers. Linear's early settings page; Notion's per-document settings. Fast to ship, easy to scan, dies past about 25 settings.

Top tabs

Two to five tabs at the top, one panel below. Good for the 20–50 settings range. Each tab is one of the three layers (Account / Workspace / Preferences). Stripe Dashboard's settings worked this way for years before sprawling.

Sidebar

A vertical nav on the left, settings page on the right. The default past about 50 settings. GitHub, Vercel, Notion, every mature product converges here. Group the sidebar by the three-layer model; collapse less-used groups by default.

The rules that prevent sprawl

• One canonical place per setting. "Notification preferences" appears in one place, not three. Cross-links from related places are fine; duplicates are not.
• Naming follows verb-object. "Change password," "Add member," "Remove integration." Not "Password," not "Members," not "Integrations" as section headers and then again as ambiguous links inside.
• Dangerous actions are visually quarantined. "Delete workspace," "Revoke API keys" go at the bottom in a section labeled Danger zone with a red accent. GitHub set this convention; copy it.
• Empty workspace defaults are valid. A new workspace should work without touching any settings. Settings are for overrides, not for required configuration. If the product is unusable until settings are filled in, those aren't settings, they're onboarding steps.
• No setting is unreachable. Every setting is linkable directly (/settings/account/security#sessions). The search you don't have today, you'll need next year.

The pages that almost always sprawl

Notifications

The most-frequently-bloated settings page in any product. Group by activity (Mentions / Comments / System), not by channel. Per-row checkboxes for each channel (in-app / email / push). One "Pause all" at the top. See the notification center post for the deeper anatomy.

Members and permissions

Roles, invites, pending invites, removed members, audit log. The trap: shipping per-permission toggles instead of role-based access. Roles scale; toggles don't. Start with 3–4 roles (Owner, Admin, Member, Viewer); add custom permissions only when enterprise customers force you to.

Billing

Plan, payment method, invoices, usage, upgrade/downgrade flow. The biggest mistake is hiding the downgrade button or the cancel button. Both should be visible; trust is built by making leaving as easy as joining. Stripe Customer Portal solves most of this if you don't want to ship it yourself.

Integrations

List of connected apps, OAuth scopes per app, disconnect button, last-used timestamp. Sort by recency; show last-used so users can prune dead connections. Don't show 47 "available integrations" on the same page as connected ones; that's a marketplace, not a settings page.

Patterns that quietly help

1. 01Autosave on settings that can autosave. Toggles, text fields with debounce. Save buttons make sense for groups that need atomic submission (billing, password); kill them everywhere else.
2. 02Inline success feedback. A small "Saved" indicator that fades in next to the field. Better than a toast that fires for every keystroke.
3. 03Search inside settings. Past 30 settings, the search bar is the most-used feature. Ship it before users ask.
4. 04Deep links from product UI. A small link in the product like "Change your default view in Preferences" beats a help article every time.
5. 05An audit log. Once you have a paid workspace tier, customers will want to see who changed what. Even a thin audit log (date, actor, what changed) is worth shipping.

The mistakes

1. 01A settings menu shaped like the company org chart. "Marketing," "Sales," "Engineering" as section headers is a sign you let internal politics design the page. Users don't care which team owns the setting.
2. 02Modal-only edits. Every setting requires opening a modal, every modal has Save / Cancel. Fine for billing; brutal for everything else. Inline editing scales better.
3. 03A reset button at the top. "Reset all settings" should not exist. Per-section resets are fine; a single nuke button is a footgun.
4. 04Hidden destructive defaults. Anything that affects data retention, billing, or visibility should never be a default toggle. Make destructive options opt-in explicitly, with confirmation.

Frequently asked

Should personal preferences be per-workspace or global?

Global, with per-workspace overrides where it matters. A user's theme preference shouldn't reset when they switch workspaces; their notification preferences might genuinely differ between a hobby workspace and a work one.

Where should I put 2FA and security settings?

Inside Account, in a Security sub-section. Not buried under "Privacy," not mixed into general account settings. Visible enough that users find it without help articles.

Save buttons or autosave?

Autosave for toggles, single-field changes, and preferences. Save buttons for atomic operations (billing details, password change). The hybrid is fine, what's not fine is one save button at the bottom of a page with 30 unrelated fields.

How do I handle workspace switching in settings?

Make the active workspace visible in the settings header, with a switcher. Settings pages are routinely the place users accidentally change the wrong workspace; the prominent label prevents the support ticket.

Ship one

The dashboard entry in the directory has the settings-page anatomy with the three-layer model and sidebar variant already encoded. Pair with the auth entry for the account and security sub-pages, and the forms entry for the inline-save patterns that make settings feel like part of the product instead of a back-office detour.