Screens

Settings

Account and application configuration screens — how to organize settings for discoverability without overwhelming users.

#settings#preferences#configuration#account#notifications#privacy#billing

What is it?

Settings screens allow users to configure their account, application behavior, notifications, privacy, and billing. They are among the most visited screens for engaged users, yet among the most frequently over-engineered or under-designed. The fundamental challenge is organizing diverse configuration options in a way that's discoverable and understandable.

Why it matters

Settings are where users customize the product to their needs. Poor settings design forces users to live with defaults they'd change if they could find the option, or to contact support for configuration that should be self-service. Settings are also a trust signal: clear notification and privacy controls signal product integrity.

Best Practices

Use a left sidebar with categories on desktop, a top-level list that navigates to category pages on mobile.
Common categories: Account, Profile, Notifications, Privacy, Billing, Security, Integrations.
Settings should be searchable — users often know what they want but not where it is.
Toggles for on/off settings are better than checkboxes — clearer state, larger touch target.
Show the current state of each toggle clearly — it should never be ambiguous whether a feature is on or off.
Changes to settings should save automatically (with a subtle confirmation) or have a clear Save button.
Destructive settings (delete account, disconnect integrations) should be in a dedicated "danger zone" section at the bottom.
Billing settings should show current plan, next billing date, payment method, and easy path to upgrade/downgrade.
Notification settings should be granular and explicit — not just "All notifications on/off."
Security settings: active sessions list, 2FA setup, API keys — these deserve dedicated design.

Common Mistakes

All settings on one unstructured page with no categories.
Checkboxes instead of toggles for on/off settings.
No search functionality for finding specific settings.
Auto-save with no feedback confirmation — users don't know if settings were saved.
Destructive actions (delete account) mixed into regular settings without visual warning.
Notification settings that only allow all-or-nothing control.

Checklist

Settings are organized into clear categories (sidebar or list pattern)

Settings are searchable

Toggles used for on/off settings (not checkboxes)

Toggle states are unambiguous (label matches state)

Changes auto-save with feedback, or have an explicit Save button

Destructive settings are in a clearly labeled danger zone

Notification settings are granular (per-type control)

Billing section shows plan, next date, payment method

Security section: sessions, 2FA, API keys

Mobile settings use a list → category page navigation pattern

Research & Theory

Progressive Disclosure in Settings

Research shows that users are overwhelmed by settings pages that show all options simultaneously. Progressive disclosure (category → detail) reduces cognitive load without hiding functionality.

Why it's relevant

The category structure of a settings page is itself a design decision. The categories must match how users think about configuration.

Real-World Examples

Linear

Clean settings sidebar with 8 categories. Toggles throughout. Auto-save with subtle confirmation. Danger zone at the bottom. Comprehensive but not overwhelming.

Notion

Settings as a modal dialog with sidebar navigation. Settings are categorized, searchable, and use consistent toggle patterns throughout.

Slack

Settings in a modal with left navigation. Notification preferences are extremely granular but well-organized. Mobile uses a different, native-feeling pattern.