UX Patterns Guide
UI + UX Personalization And Preference established

Settings page

Provide a dedicated settings page structure with explicit page identity, grouped sections, selected-section state, section summaries, deep-link context, mobile section navigation, search for larger settings sets, separated high-risk destinations, and a return path to the invoking product area.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A product has multiple settings sections and users need a durable destination to find the right area.
  • Settings can be reached from several entry points and the page needs to preserve section and return context.
  • Users need to scan categories before inspecting or editing individual settings.

Avoid when

  • There is only one simple in-context setting that can be changed where the user already is.
  • The problem is the save, reset, dependency, permission, or failed-edit behavior of setting values rather than page structure.
  • The surface is primarily a consent or communication preference center.
  • The task is profile completion, onboarding, support, or destructive account closure rather than settings orientation.
  • The page would only mirror global navigation without settings-specific section content.

Problem it prevents

Settings destinations become disorienting when the page shell hides section hierarchy, current location, entry route, search, responsive section switching, or boundaries between ordinary settings and unrelated account tasks.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Settings page in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

Products often have many settings sections across account, profile, workspace, organization, security, notifications, privacy, display, billing-adjacent configuration, integrations, devices, data, and developer tools.

Pattern promise

Provide a dedicated settings page structure with explicit page identity, grouped sections, selected-section state, section summaries, deep-link context, mobile section navigation, search for larger settings sets, separated high-risk destinations, and a return path to the invoking product area.

Required state

Settings landing or overview state with section groups

Recovery path

Users cannot tell whether they are editing personal, workspace, organization, device, or app settings.

Access contract

Use landmarks, headings, and section labels so the settings page, section navigation, selected section, and content region are programmatically distinct.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A workspace Settings page has a title, left section list, selected Security section, summary cards for sign-in, members, audit log, and tokens, plus a breadcrumb back to the workspace.
  • A mobile Settings screen collapses the section list into a labelled section picker, keeps the selected section title visible, and shows high-risk account actions in a separated area.
  • A user opens Settings from a project, lands on Workspace notifications, sees the current section highlighted, searches for retention, and can return to the project after editing.
  • A user on mobile switches from Account to Security through a labelled section picker and sees that destructive account closure is outside ordinary settings sections.
Weak implementation

Vague, hidden, hard to recover from

  • A page called Settings is a long flat list of unrelated links, invoices, help articles, destructive account actions, and onboarding reminders with no section identity.
  • A desktop settings page uses horizontal tabs for 24 categories, hiding Privacy and Security behind scroll and making deep links land without context.
  • A user follows a settings deep link and cannot tell whether they are changing personal, workspace, or organization settings because the page shell has no section context.
  • A user tries to find language settings but scans through mixed billing, support, profile, and integration links because the Settings page has no category map.
UI guidance
  • Render a settings page as a stable destination with a clear page title, section list, selected section, section summary, grouped setting rows or links, current-location cues, search or find-in-settings for larger products, and a reliable way back to the product area that opened it.
  • Separate the settings page pattern from settings management: the page pattern owns the shell, hierarchy, section navigation, responsive layout, and discoverability of settings destinations, while settings management owns how individual settings are inspected, edited, saved, reset, inherited, or recovered.
UX guidance
  • Use a settings page when users must orient within many account, app, workspace, security, notification, privacy, billing, device, integration, or display sections before changing a value.
  • Make the page answer three questions before interaction: where am I, what settings live in this section, and how do I return to the work area without losing context.
Implementation contract

What the implementation must handle

States

  • Settings landing or overview state with section groups
  • Selected section state with title, summary, and current navigation marker
  • Deep-linked section state that preserves location context
  • Search or find-in-settings results state

Interaction

  • Opening a settings page shows the page identity, current section, and whether the scope is personal, workspace, organization, app, device, or system.
  • Selecting a section changes the visible section title and content without losing the user's place in the settings destination.
  • Deep links land with the section navigation and page title visible, not on an orphaned form with no settings context.
  • Search results identify the owning section and move users to that section while preserving a return route to results when appropriate.

Accessibility

  • Use landmarks, headings, and section labels so the settings page, section navigation, selected section, and content region are programmatically distinct.
  • Do not rely on color alone to indicate the current section, unavailable section, admin-only section, or high-risk area.
  • Keep section navigation keyboard reachable and make the selected section available through text, aria-current, or equivalent semantics.
  • Ensure search results name the owning section and are reachable by keyboard before moving focus to the target section.

Review

  • Can users identify the settings scope, selected section, and return path before changing anything?
  • Does this page organize sections by user mental model rather than internal service ownership?
  • Which destinations are settings-adjacent but should be separated from ordinary configurable behavior?
  • Will a deep link, search result, or mobile drawer still show enough section context?
Evidence trail

Source-backed claims behind this guidance

Apple Human Interface Guidelines Settings

Apple Developer - checked

Apple supports deliberate placement of settings based on how often users change them and whether they belong inside the app or system Settings.

Material Design Settings pattern

Material Design - checked

Material supports settings screens with clear navigation placement, labels, secondary text, and current values.

Android Developers Settings

Android Developers - checked

Android supports settings screens with preference hierarchy, current values, dependencies, and persistence.

Full agent/debug reference

Problem Context

  • Products often have many settings sections across account, profile, workspace, organization, security, notifications, privacy, display, billing-adjacent configuration, integrations, devices, data, and developer tools.
  • Settings pages can be reached from global navigation, utility navigation, object context menus, email links, admin links, search results, onboarding prompts, or deep links.
  • Users may visit rarely and need orientation even before they inspect or edit any specific setting value.
  • Desktop layouts often use a persistent section rail, while mobile layouts need a compact section picker, drawer, or stacked category list that still preserves current section identity.
  • Some settings-adjacent destinations, such as invoices, support, account deletion, profile completion, and legal pages, create confusion when placed beside ordinary configurable behavior without separation.

Selection Rules

  • Choose settings page when the main design problem is the destination layout, section hierarchy, selected section, and wayfinding for many settings areas.
  • Use settings management when the main design problem is how setting values show current state, save behavior, dependencies, permissions, reset behavior, or failed edits.
  • Use side navigation for navigation between major product destinations; use settings page navigation for sections inside one Settings destination.
  • Use tabs for a small set of peer views inside one setting section, not for the entire settings taxonomy when categories are numerous or unrelated.
  • Use navigation drawer when the app shell or mobile layout needs to reveal settings sections temporarily; the drawer should still lead to a settings page with a visible selected section.
  • Use preference center when the page is specifically about communication, consent, privacy/data sharing, topics, language, and personalization choices that need consent-style clarity.
  • Use profile setup when the task is profile readiness, required profile fields, visibility, or onboarding completion rather than long-term settings navigation.
  • Use complete complex form inside a settings page when one section contains interdependent configuration that needs one reviewed save.
  • Provide search or a settings index when there are enough sections that users cannot reliably scan the section list.
  • Separate high-risk, legal, billing, support, and destructive account destinations from ordinary settings sections with clear labels and spacing.

Required States

  • Settings landing or overview state with section groups
  • Selected section state with title, summary, and current navigation marker
  • Deep-linked section state that preserves location context
  • Search or find-in-settings results state
  • No-result or unmatched setting search state
  • Mobile section picker, drawer, or stacked category state
  • Empty, unavailable, or permission-limited section state
  • High-risk or destructive destination separated from ordinary settings state
  • Return-to-origin state after opening settings from a product area
  • Long section labels, localization, and high-zoom wrapping state

Interaction Contract

  • Opening a settings page shows the page identity, current section, and whether the scope is personal, workspace, organization, app, device, or system.
  • Selecting a section changes the visible section title and content without losing the user's place in the settings destination.
  • Deep links land with the section navigation and page title visible, not on an orphaned form with no settings context.
  • Search results identify the owning section and move users to that section while preserving a return route to results when appropriate.
  • Mobile layouts keep the selected section and available sections reachable without hiding important categories behind unlabeled controls.
  • High-risk destinations such as account closure, legal changes, or billing records are visually and semantically separated from ordinary settings sections.
  • A return action goes back to the product area or object that opened settings, not always to a default home page.

Implementation Checklist

  • Inventory settings sections by user mental model, scope, risk, frequency of change, owner, and entry route before choosing the page structure.
  • Define desktop and mobile section navigation patterns, including selected state, section summaries, deep-link behavior, and long-label wrapping.
  • Decide which settings-adjacent destinations belong in the page, which need separation, and which should live outside Settings.
  • Add search, index, or direct setting lookup when sections are numerous, rarely visited, or named differently across teams.
  • Represent unavailable sections, permission-limited sections, empty integrations, and admin-only areas without making the page feel broken.
  • Test global entry, object-scoped entry, deep links, browser back, return to origin, mobile section switching, high zoom, localization, keyboard navigation, and screen-reader landmarks.

Common Generated-UI Mistakes

  • Treating Settings as a miscellaneous link dump for billing, help, onboarding, profile completion, invoices, support, and destructive account actions.
  • Using tabs for too many unrelated settings categories, causing hidden overflow and weak deep-link context.
  • Styling settings section navigation exactly like global app navigation, so users cannot tell whether they changed app area or settings section.
  • Deep-linking directly to a setting form without page title, section list, or scope label.
  • Hiding the selected section on mobile after the user opens a drawer or picker.
  • Putting ordinary settings and irreversible account closure in the same visual group.
  • Adding search results that jump to a row but do not show the owning section or path.
  • Letting long localized section names overlap controls or truncate the only meaningful navigation label.

Critique Questions

  • Can users identify the settings scope, selected section, and return path before changing anything?
  • Does this page organize sections by user mental model rather than internal service ownership?
  • Which destinations are settings-adjacent but should be separated from ordinary configurable behavior?
  • Will a deep link, search result, or mobile drawer still show enough section context?
  • Is the section navigation distinct from global product navigation and local tabs?
  • What happens when a user lacks permission for one settings section?
Accessibility
  • Use landmarks, headings, and section labels so the settings page, section navigation, selected section, and content region are programmatically distinct.
  • Do not rely on color alone to indicate the current section, unavailable section, admin-only section, or high-risk area.
  • Keep section navigation keyboard reachable and make the selected section available through text, aria-current, or equivalent semantics.
  • Ensure search results name the owning section and are reachable by keyboard before moving focus to the target section.
  • Make mobile section pickers, drawers, and accordions expose the current section name and available section count.
  • Preserve long labels, localized labels, high-zoom layouts, and large text without overlapping section names, summaries, or actions.
  • Separate destructive or legal settings with headings and descriptions that screen-reader users encounter before the action.
Keyboard Behavior
  • Tab moves through page-level return link, settings search, section navigation, selected section heading, section content, and any separated high-risk destinations.
  • Arrow keys may move through a tablist, tree, or listbox-style section picker only when the component uses the matching semantic pattern.
  • Enter or Space activates a section link, section picker item, drawer trigger, or search result and moves focus to the selected section heading when appropriate.
  • Escape closes mobile drawers, section pickers, or search result panels and returns focus to the invoking control.
  • Browser Back returns through settings section history or to the invoking product area according to the route model.
  • Search no-result state keeps focus in the search area and offers a clear route back to the full section list.
Variants
  • Account settings page
  • Workspace settings page
  • Organization settings page
  • App settings screen
  • Mobile settings screen
  • Settings landing page
  • Settings section page
  • Settings category index
  • Settings search page
  • Admin settings page
  • Device settings link page

Verification

Source trail checked:

Saved items