Skip to content
UX Atlas
Plate PAT·025 · PatternGrid F1 · Rev. 2026-09-14

Settings and Preferences

Group by the question people are trying to answer, decide one convention for saving, and treat defaults as the real design.

PatternCraft conventionIntermediate

Definition

Settings expose the choices a product allows. They accumulate faster than any other surface, and they are usually organised around the system's objects rather than around what the reader is trying to change.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2Structuring them
  3. 3Behaviour
  4. 4Where a setting belongs
  5. 5What every setting owes the reader
  6. 6In practice
  7. 7Local chart
  8. 8Continue from here

Reach for this when

  • Designing or reorganising a settings area.
  • Support answers 'where is that setting' repeatedly.
  • Adding a preference that interacts with an existing one.

Common mistakes

  • Grouping by internal object model.
  • Mixed saving conventions on one page.
  • Toggles whose real effect depends on a hidden parent setting.
  • Delete account next to theme selection.
  • Adding a setting to avoid making a decision, which moves the work to every reader instead of doing it once.

Structuring them

  1. 1

    Group by intent

    People look for the outcome they want to change, not for the entity that stores it. 'Who can see my work' beats 'Workspace object permissions'.

  2. 2

    Separate scopes visibly

    Personal preference, workspace policy and billing are three different kinds of setting with three different audiences. Mixing them causes the wrong person to change the wrong thing.

  3. 3

    Pick one saving convention

    Either every control applies immediately, or the page has an explicit save. Mixing both in one interface means nobody can predict whether a change took.

  4. 4

    Add search past about twenty items

    Beyond that, the structure stops being memorable even when it is correct.

Behaviour

Do

  • Confirm immediate changes with a brief status message, announced to assistive technology.
  • Show the effective value when a workspace policy overrides a personal preference, and say who set it.
  • Keep destructive account actions in their own area, visually separated.
  • Write each label as the outcome, with help text for the consequence.

Do not

  • Do not use a toggle for a setting that needs a save step. A toggle promises immediacy.
  • Do not hide a setting's dependency: a notification channel that is off globally makes every per-event switch meaningless.
  • Do not ship a default nobody argued about. It will be the value most people keep.

Where a setting belongs

SettingHomeWhy
Affects one screen onlyOn that screenNobody goes to settings to change what is in front of them
Affects the whole accountSettingsIt needs one place, findable by search
Affects one deviceSettings, labelled as device-specificOr readers expect it to follow them and it does not
Affects other peopleSettings, with the scope statedSharing and permissions need an explicit audience
Used once at setupIn the setup flow, and then in settingsDiscoverable at the moment it matters, findable later

What every setting owes the reader

A control alone is not a setting. These are the things a reader needs in order to change one with any confidence.

  • The effective value, which is not always the value this person chose: a workspace policy or a plan limit may be overriding it.
  • The scope, in words: just me, everyone in this workspace, or this device only.
  • When it takes effect, since a setting that applies at the next sign-in or the next billing period is a different promise.
  • Its dependencies, so a per-event switch made meaningless by a global one off above it says so rather than sitting there looking active.
  • What it costs, where a setting changes billing, retention or what other people can see.
  • How to get back to the default, without having to remember what the default was.

In practice

  1. i.

    Effective value beats a stale toggle

    In a workspace where an admin has disabled external sharing, showing a personal 'sharing' switch as on is a lie. Showing it as off, disabled, with 'Turned off for this workspace by your admin' explains the state and names the route to change it.

  2. ii.

    The setting that had already been overridden

    Effective value

    An account preference showed as on while a workspace policy had turned it off. Showing the effective value, and what overrode it, is the only honest way to render a setting with layers behind it.

Local chart

PAT·025 · Region III · Grid F1

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Default EffectBIAS·004 · PRINCIPLES BEHIND THISProgressive DisclosurePRIN·003 · PRINCIPLES BEHIND THISStatus Messages and Live RegionsA11Y·009 · DEPENDS ONToggle SwitchCMP·007 · OFTEN USED WITHDestructive ActionsPAT·009 · OFTEN USED WITHSearchPAT·002 · OFTEN USED WITHSaaS Product ChecklistCHK·007 · CHECK YOUR WORK

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Principles behind this

The reasoning this solution is an application of.

Depends on

Get these right first, or this one will not hold.

Often used with

These usually appear in the same screen or the same decision.

Check your work

Review passes that test whether this was done properly.