The settings page is the part of every product that grows the fastest and gets the least design attention. Senior interviews increasingly probe whether you can design a settings page architecture that holds up as the product grows. This guide is for the engineer who has been asked to build a settings page and wants to do it well.
Why settings are hard
- They accumulate over time as features ship
- Different settings apply to different scopes (user, account, workspace, project)
- Some settings are gated by role / permission
- Some require write coordination (changing one affects another)
- Mobile gets cramped quickly
- Search becomes essential past 30+ settings
The information architecture
Three structural decisions:
- How are settings grouped (categorically)?
- What is the navigation pattern (sidebar, tabs, accordion)?
- Are settings deep-linkable?
Common groupings
- Personal: profile, notifications, security, preferences
- Account: billing, plan, payment methods, subscription
- Organization / Team: members, roles, billing, branding
- Integrations: connected services
- Advanced / Developer: API tokens, webhooks, debug
Three layers (Personal / Workspace / Org) is the dominant SaaS pattern.
The sidebar pattern
- Left sidebar with grouped sections
- Active section highlighted
- Right pane shows the content
- Search at the top of the sidebar
- Mobile: collapse to drawer
The deep-linking imperative
Users link directly to specific settings:
/settings/notifications/settings/security/two-factor- URL is the source of truth for the active setting
- Clicking sidebar items pushes new URL
- Browser back/forward navigates settings
Search
- Search across all setting names and labels
- Fuzzy match (e.g., “passwd” finds “Change password”)
- Indexed at build time; client-side search
- Results jump directly to the relevant setting (with highlight)
The save pattern
Three common variants:
- Auto-save: changes save on blur or after a debounce. Risk: unintended changes.
- Save button: explicit per-section. Safer but adds friction.
- Hybrid: auto-save for low-stakes; explicit save for high-stakes (password, billing).
Most modern apps use auto-save with a “saving / saved” indicator.
The “destructive” settings
- Delete account, transfer ownership, leave organization
- Always require explicit confirmation (typed name, password, etc.)
- Often grouped at the bottom in a “Danger zone” (GitHub-style)
- Visual treatment makes the danger clear
Permission gating
- Hide vs disable: hidden when the user cannot understand the setting at all; disabled with tooltip when relevant but role-restricted
- Server enforces; client-side checks are UX only
- “You need admin access to change this — request from X” with the right user listed
Loading and empty states
- Skeleton on initial load
- Per-section error states (do not break the whole page)
- “Sync from server” failure: clear retry
- Stale: badge if cached values may be old
Form patterns
- Text inputs, toggles, dropdowns, multi-select
- Inline validation with helpful errors
- Group related controls visually
- Help text under each control with examples
- Reset to defaults per section
Common settings that have unique UX
- Notifications: matrix of (channel × event), often dense — design for scanability
- API tokens: generation, scope selection, revocation, last-used
- Two-factor auth: authenticator app vs SMS vs WebAuthn; recovery codes
- Email preferences: double opt-in / unsubscribe one-click
- Privacy: data export, account deletion, GDPR rights
- Theme / appearance: system / light / dark; custom per surface
Accessibility
- Each setting has a clear visible label
- Labels associated with inputs (
<label htmlFor>) - Help text and error text linked via
aria-describedby - Keyboard navigation: tab through controls in order
- Focus management when navigating sections
Mobile considerations
- Stack vertically; sidebar becomes drawer
- Larger touch targets
- Avoid two-column layouts under 768px
- Contextual entry (deep link from a feature) jumps directly to its setting
The settings registry
For a scalable architecture, define settings declaratively:
{
id: "notifications.email.weekly_digest",
type: "boolean",
scope: "user",
category: "notifications",
label: "Weekly email digest",
helpText: "Receive a summary every Monday",
defaultValue: true,
permission: null
}The renderer iterates the registry. Adding a new setting is one entry, not five files.
Versioning settings
- Old settings can be deprecated; show only if the user has them set
- Migration: rename or restructure with backward compat
- Document what each version of the setting object looks like
What separates senior from staff
Senior candidates build a clean settings page. Staff candidates design the registry abstraction, the search index, the deep-link model, and the permission gating. Principal candidates address the multi-scope settings cascade (user override → org default → product default) and the long-tail UX of settings that are used once a year.
Frequently Asked Questions
Auto-save or explicit save?
Auto-save for the bulk; explicit save for the destructive or high-impact settings. Surface clear “saving / saved” feedback.
How do I handle settings that affect other users?
Confirm before applying. “This will affect 23 members of your team — continue?” Show consequences clearly.
What about settings that take effect after relaunch?
Surface the requirement. “This change will apply on next sign-in.” Or relaunch the SPA route automatically if safe.
Useful next steps:
