Design patterns
Settings page UX: organize choices and make saving clear
Design account and workspace settings with understandable scope, predictable saving and clear treatment of consequential actions.
Start with whose setting it is
A settings page should explain what changes and who is affected. A personal email preference, a workspace default and an administrator permission are different scopes. Grouping them under a single “General” heading can make an ordinary choice feel uncertain.
For an illustrative team app, separate Personal notifications from Workspace notifications. If only administrators can change a workspace setting, show the relevant state and explain the restriction. Do not present a clickable control that will predictably fail for the current user.
Choose a saving model and make it consistent
A group of related fields can use an explicit Save changes action. An independent preference may save immediately. Either model needs a clear pending state and an honest failure state. Avoid combining both without explaining which controls behave differently.
Suppose a user changes their display name and time zone. If Save fails, keep the edits visible and offer a retry. If an immediately saved notification preference fails, reconcile the displayed state with the stored state and explain what happened. The toggle should not keep promising a choice the server rejected.
Keep consequential actions separate
Place actions such as deleting a workspace or revoking access away from routine appearance preferences. Explain the object affected and the consequence in plain language. The implementation should use the product’s existing authorization and confirmation behavior rather than inventing a purely visual safeguard.
Use Taste references to study grouping, explanatory text and save feedback. Annotate which part you want to borrow. A subtle destructive link from a screenshot may depend on a confirmation flow that is not visible in the image.
A settings brief for an AI coding tool
Keep backend permissions and existing behavior in scope when asking for the visual revision.
Improve our settings page without changing authorization rules. Separate personal preferences from workspace-wide settings. For each control, specify whether it saves immediately or with Save changes. Preserve edits on failure and make saved, saving and failed states understandable. Inspect my Taste settings references for grouping and help text. Keep consequential actions separate and retain the existing confirmation flow. Test a member account and an administrator account.
Review changes across a return visit
Change a value, leave the page and return. Does the saved state match the previous confirmation? Open the page with a role that cannot edit workspace settings. Try a failed save and a second edit while a request is pending.
Use status feedback that is available to assistive technology when an update occurs without moving focus. W3C’s status-message guidance explains that requirement. Keep messages specific: “Notification preference saved” is more useful than an unexplained checkmark.