Settings page

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?