Settings Skill
How this skill behaves (read first)
This is a generative skill. Settings is a pattern users know — the job is get in, change one thing, get out — and the default failures fight that: a flat dump of every option, the page used as a junk drawer for links that fit nowhere else, technical-jargon labels, no current status shown, destructive actions sitting up top where they're hit by accident, and changes that save with no feedback (or autosave where the user expected a deliberate Save). A settings screen has two design problems in one — how the options are organized and how changes are saved — and each has its own rules. So this skill gates:
- Establish scale, platform, and sensitivity — how many settings, mobile vs. web, and whether sensitive data is involved decide the structure and the save model.
- Apply the always-true core — relevance, grouping, plain labels, visible status, destructive-last, clear save feedback.
- Surface the context-dependent decisions (autosave vs. Save button, search, advanced split, confirmation/2FA) with trade-offs.
Then it hands off to ux-heuristics-audit, ux-accessibility-audit, ux-aesthetics-audit, ux-microcopy-audit, ux-information-architecture-audit, ux-dark-patterns-audit, and ux-mobile-responsiveness-audit for validation.
Scope & composition (per docs/orchestration-policy.md §9): this skill covers the settings page and its save model and composes lower-scope skills rather than re-deriving them. Core children (built as part of the page): the choice of control (toggle vs. checkbox vs. radio vs. slider) via ux-selection-controls. Peers that own a sub-part (defer): the search input itself to ux-search and notification-preference depth to ux-notifications-and-toasts (they own those sub-parts if reached). Inherit, don't regenerate: under an existing design system, take color/type/spacing from its tokens — only set those when designing from scratch.
Step 0 — Establish context before designing
Ask if not known; state the assumption if proceeding without an answer:
- How many settings? A handful needs only grouping; dozens need search, an advanced-settings split, and disciplined frequency ordering. Don't add search to a five-option page; don't ship fifty options as one flat list.
- Platform. Mobile changes save expectations and adds the device-vs-app permission split (notifications/location toggles live partly in the OS). macOS users expect autosave; Windows users expect explicit Save/Apply — match the platform habit.
- Sensitive data? Email, password, billing, payment methods — these warrant confirmation and often two-factor verification before a change applies.
- Audience. General users need plain language; only a developer-facing product can assume technical terms.
The always-apply core (correct for almost every settings page)
Organize so users get in and out fast
- Only real settings belong here. Settings is for user preferences (notifications, privacy, appearance, account). Don't use it as a catch-all for links that fit nowhere else — that confuses and distracts.
- Group related settings by type (account, security, notifications…) or use case, separated with headings and white space — not one continuous list and not a wall of divider lines (visual noise).
- Order by frequency. The settings users change most sit at the top and are clearly visible; rarely-touched ones go lower; advanced/expert-only options hide behind an "Advanced" disclosure.
- Make settings easy to reach — a known spot (top corner on web, bottom bar or top corner on mobile), never buried in submenus.
Make each control self-explanatory
- Plain-language labels and short helper text. Write the way the audience talks (research real vocabulary from support tickets, reviews, forums); explain non-obvious controls in a brief line placed right next to the control (proximity), not floating.
- Show current status beside each setting — the toggle/selected value or a one-line summary of the current configuration — so users can review choices without drilling in.
- Label toggles by the action, not the state — "Shake to send feedback," not "Shake to send feedback off"; the control's visual state shows on/off.
Protect the user
- Destructive actions (log out, delete/deactivate account) go at the bottom, set apart by color, an icon, or extra white space — reducing accidental taps. (Note: hiding logout/delete to trap users is a dark pattern — put them last, don't bury them. → dark-patterns.)
- Surface urgent system alerts at the top — a privacy-policy change, expiring trial, or low storage deserves a badge and top placement, not a buried line.
Close the loop on saving
- Give clear save feedback through button states: Save disabled until something changes → active once it does (signaling unsaved changes) → loading while saving → a non-intrusive success toast/banner confirming it saved (with Undo for reversible changes).
- Let users leave without saving. Closing or pressing Back should not silently persist changes; if they abandon unsaved sensitive edits, use a short, specific confirmation dialog.
The context-dependent decisions (surface, don't auto-apply)
| Decision |
Apply when |
Avoid / adapt when |
Default recommendation |
| Autosave vs. explicit Save |
Autosave for single-action, easy-to-undo controls (a standalone toggle/checkbox that takes effect immediately) |
Multi-field or deliberate changes, or sensitive data, where users want to confirm |
Autosave atomic toggles; an explicit Save for grouped/sensitive edits; respect platform habit (macOS autosave / Windows Save) |
| Search within settings |
More than a handful of options, or sub-menus users must scroll through; show related results not just exact (search "Siri" → Accessibility, Notifications…) with auto-suggest |
A short page where grouping already makes everything visible |
Add once scrolling/sub-menus appear — after first minimizing the option count |
| Advanced-settings split (progressive disclosure) |
A mix of common and expert/complex options |
Hiding a commonly-needed setting behind "Advanced" |
Primary visible to all; advanced disclosed on request — ≤ the depth users can follow |
| Confirmation / two-factor on a change |
Changing sensitive data (email, password, billing) or destructive actions |
Trivial reversible toggles (confirmation fatigue) |
Confirm + 2FA for sensitive/destructive; let everyday toggles apply freely |
| Confirmation-dialog wording |
When you do confirm, the heading states the one action; CTAs are unambiguous |
Generic "Warning" / "Are you sure?"; "Cancel" next to a delete (ambiguous — cancel what?) |
Specific heading + action-word buttons (Leave, Stay, Delete) → microcopy |
| Mobile: deep-link to OS settings |
A permission (notifications on/off, location) lives in the device Settings |
Pretending the app can fully toggle an OS-level permission |
Manage in-app what you can; explain why and route to system Settings for the rest |
| Defaults |
Set defaults to the experience most users expect (validate with research/card sorting) |
Defaulting from team preference/assumption |
Research-backed defaults; card-sort the grouping and naming when unsure |
Validate the result (orchestration)
Hand-offs name each lens by its installable skill name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.
After generating or revising, hand the result to the audit lenses rather than declaring it done. These are candidate lenses — posture is set by docs/orchestration-policy.md, or route the whole thing through ux-design-review. Here, heuristics, microcopy, and dark-patterns are Tier A (auto-run); accessibility, aesthetics, information-architecture, and mobile-responsiveness are Tier B (offered) — under an existing design system aesthetics is suppressed and accessibility narrows to usage; mobile-responsiveness applies only on mobile. If the user invoked this skill for one specific thing, respect that scope.
ux-heuristics-audit (Tier A) — visibility of system status (current values, save state), user control & freedom (leave without saving, Undo), error prevention (confirm sensitive/destructive changes), recognition over recall.ux-accessibility-audit (Tier B — offer; narrow under a design system) — control labels and states announced, target sizes, focus order, contrast on status indicators.ux-aesthetics-audit (Tier B — offer; suppress under a design system) — grouping legibility, white space over divider-line noise, a scannable hierarchy rather than a flat list.ux-microcopy-audit (Tier A) — this skill leans hard on copy: plain labels, action-based toggle labels, helper text, and confirmation-dialog headings/CTAs.ux-information-architecture-audit (Tier B — offer) — whether the grouping scheme and ordering match users' mental model (card-sort evidence), and whether labels carry scent.ux-dark-patterns-audit (Tier A) — destructive actions placed last but not hidden; no confirmshaming on cancellation; no forced retention friction.ux-mobile-responsiveness-audit (Tier B — offer) — touch targets, the app-vs-OS permission split, save-button reach (sticky bottom), one-handed use.
If the audits surface a conflict (e.g., security wants confirmation on everything vs. fast settings), resolve back toward the primary task: users came to change one thing and leave — protect the dangerous changes, get out of the way on the rest.
Common do/don't patterns
| ❌ Don't |
✅ Do |
| Dump every option in one flat list |
Group by type/use case with headings + white space |
| Use settings as a junk drawer for stray links |
Only real preferences; everything else lives elsewhere |
| Order by internal logic |
Order by how often users change each setting; advanced hidden |
| Technical/jargon labels |
Plain words from how users actually talk; short helper text nearby |
| Hide the current value |
Show each setting's status beside it |
| "Notifications: Off" as a toggle label |
Action-based label ("Email notifications") + visual on/off state |
| Destructive actions up top — or hidden entirely |
Last, set apart by color/space; present, not buried (→ dark-patterns) |
| Save silently / not at all |
Save state: disabled → active → loading → success toast (+ Undo) |
| Autosave a multi-field or sensitive edit |
Explicit Save for deliberate/sensitive; autosave atomic toggles |
| "Are you sure?" / "Cancel" on a delete dialog |
Specific heading + unambiguous action-word CTAs |
| Bolt search onto a 5-item page |
Minimize options first; add search when scrolling/sub-menus appear |
| Ship without checking |
Hand off to heuristics + accessibility + aesthetics + microcopy + IA + dark-patterns + mobile-responsiveness |
Source lessons (Uxcel)
1---2name: ux-settings3description: Design or critique a settings / preferences page — organizing many options without overwhelm, plus the save model (autosave vs. explicit Save, confirmation, revert). Applies the always-true core (only relevant settings, frequency-ordered groups, plain labels, visible current status, destructive actions last, clear save feedback) and gates context-dependent levers (autosave vs. Save button, search, advanced-settings split, sensitive-change confirmation) with trade-offs. Trigger when the user asks to design or review a settings page, preferences screen, account settings, app configuration, or a save/confirmation pattern.4license: MIT5---67# Settings Skill89## How this skill behaves (read first)1011This is a **generative** skill. Settings is a pattern users know — the job is *get in, change one thing, get out* — and the default failures fight that: a flat dump of every option, the page used as a junk drawer for links that fit nowhere else, technical-jargon labels, no current status shown, destructive actions sitting up top where they're hit by accident, and changes that save with no feedback (or autosave where the user expected a deliberate Save). A settings screen has two design problems in one — **how the options are organized** and **how changes are saved** — and each has its own rules. So this skill gates:12131. **Establish scale, platform, and sensitivity** — how many settings, mobile vs. web, and whether sensitive data is involved decide the structure and the save model.142. **Apply the always-true core** — relevance, grouping, plain labels, visible status, destructive-last, clear save feedback.153. **Surface the context-dependent decisions** (autosave vs. Save button, search, advanced split, confirmation/2FA) with trade-offs.1617Then it **hands off to `ux-heuristics-audit`, `ux-accessibility-audit`, `ux-aesthetics-audit`, `ux-microcopy-audit`, `ux-information-architecture-audit`, `ux-dark-patterns-audit`, and `ux-mobile-responsiveness-audit`** for validation.1819Scope & composition (per `docs/orchestration-policy.md` §9): this skill covers the **settings page and its save model** and composes lower-scope skills rather than re-deriving them. **Core children (built as part of the page):** the **choice of control** (toggle vs. checkbox vs. radio vs. slider) via `ux-selection-controls`. **Peers that own a sub-part (defer):** the **search input itself** to `ux-search` and **notification-preference depth** to `ux-notifications-and-toasts` (they own those sub-parts if reached). **Inherit, don't regenerate:** under an existing design system, take color/type/spacing from its tokens — only set those when designing from scratch.2021---2223## Step 0 — Establish context before designing2425Ask if not known; state the assumption if proceeding without an answer:2627- **How many settings?** A handful needs only grouping; dozens need search, an advanced-settings split, and disciplined frequency ordering. Don't add search to a five-option page; don't ship fifty options as one flat list.28- **Platform.** Mobile changes save expectations and adds the device-vs-app permission split (notifications/location toggles live partly in the OS). macOS users expect autosave; Windows users expect explicit Save/Apply — match the platform habit.29- **Sensitive data?** Email, password, billing, payment methods — these warrant confirmation and often two-factor verification before a change applies.30- **Audience.** General users need plain language; only a developer-facing product can assume technical terms.3132---3334## The always-apply core (correct for almost every settings page)3536### Organize so users get in and out fast37- **Only real settings belong here.** Settings is for user preferences (notifications, privacy, appearance, account). Don't use it as a catch-all for links that fit nowhere else — that confuses and distracts.38- **Group related settings** by type (account, security, notifications…) or use case, separated with headings and white space — not one continuous list and not a wall of divider lines (visual noise).39- **Order by frequency.** The settings users change most sit at the top and are clearly visible; rarely-touched ones go lower; advanced/expert-only options hide behind an "Advanced" disclosure.40- **Make settings easy to reach** — a known spot (top corner on web, bottom bar or top corner on mobile), never buried in submenus.4142### Make each control self-explanatory43- **Plain-language labels and short helper text.** Write the way the audience talks (research real vocabulary from support tickets, reviews, forums); explain non-obvious controls in a brief line placed right next to the control (proximity), not floating.44- **Show current status beside each setting** — the toggle/selected value or a one-line summary of the current configuration — so users can review choices without drilling in.45- **Label toggles by the action, not the state** — "Shake to send feedback," not "Shake to send feedback off"; the control's visual state shows on/off.4647### Protect the user48- **Destructive actions (log out, delete/deactivate account) go at the bottom,** set apart by color, an icon, or extra white space — reducing accidental taps. (Note: *hiding* logout/delete to trap users is a dark pattern — put them last, don't bury them. → dark-patterns.)49- **Surface urgent system alerts at the top** — a privacy-policy change, expiring trial, or low storage deserves a badge and top placement, not a buried line.5051### Close the loop on saving52- **Give clear save feedback through button states:** Save disabled until something changes → active once it does (signaling unsaved changes) → loading while saving → a non-intrusive success toast/banner confirming it saved (with Undo for reversible changes).53- **Let users leave without saving.** Closing or pressing Back should not silently persist changes; if they abandon unsaved sensitive edits, use a short, specific confirmation dialog.5455---5657## The context-dependent decisions (surface, don't auto-apply)5859| Decision | Apply when | Avoid / adapt when | Default recommendation |60|---|---|---|---|61| **Autosave vs. explicit Save** | Autosave for single-action, easy-to-undo controls (a standalone toggle/checkbox that takes effect immediately) | Multi-field or deliberate changes, or sensitive data, where users want to confirm | Autosave atomic toggles; an explicit Save for grouped/sensitive edits; respect platform habit (macOS autosave / Windows Save) |62| **Search within settings** | More than a handful of options, or sub-menus users must scroll through; show *related* results not just exact (search "Siri" → Accessibility, Notifications…) with auto-suggest | A short page where grouping already makes everything visible | Add once scrolling/sub-menus appear — *after* first minimizing the option count |63| **Advanced-settings split (progressive disclosure)** | A mix of common and expert/complex options | Hiding a commonly-needed setting behind "Advanced" | Primary visible to all; advanced disclosed on request — ≤ the depth users can follow |64| **Confirmation / two-factor on a change** | Changing sensitive data (email, password, billing) or destructive actions | Trivial reversible toggles (confirmation fatigue) | Confirm + 2FA for sensitive/destructive; let everyday toggles apply freely |65| **Confirmation-dialog wording** | When you do confirm, the heading states the one action; CTAs are unambiguous | Generic "Warning" / "Are you sure?"; "Cancel" next to a delete (ambiguous — cancel what?) | Specific heading + action-word buttons (Leave, Stay, Delete) → microcopy |66| **Mobile: deep-link to OS settings** | A permission (notifications on/off, location) lives in the device Settings | Pretending the app can fully toggle an OS-level permission | Manage in-app what you can; explain *why* and route to system Settings for the rest |67| **Defaults** | Set defaults to the experience most users expect (validate with research/card sorting) | Defaulting from team preference/assumption | Research-backed defaults; card-sort the grouping and naming when unsure |6869---7071## Validate the result (orchestration)7273> Hand-offs name each lens by its installable skill `name`. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.7475After generating or revising, hand the result to the audit lenses rather than declaring it done. These are **candidate** lenses — posture is set by `docs/orchestration-policy.md`, or route the whole thing through `ux-design-review`. Here, **`heuristics`, `microcopy`, and `dark-patterns` are Tier A (auto-run); `accessibility`, `aesthetics`, `information-architecture`, and `mobile-responsiveness` are Tier B (offered)** — under an existing design system `aesthetics` is suppressed and `accessibility` narrows to usage; `mobile-responsiveness` applies only on mobile. If the user invoked this skill for one specific thing, respect that scope.7677- **`ux-heuristics-audit`** *(Tier A)* — visibility of system status (current values, save state), user control & freedom (leave without saving, Undo), error prevention (confirm sensitive/destructive changes), recognition over recall.78- **`ux-accessibility-audit`** *(Tier B — offer; narrow under a design system)* — control labels and states announced, target sizes, focus order, contrast on status indicators.79- **`ux-aesthetics-audit`** *(Tier B — offer; suppress under a design system)* — grouping legibility, white space over divider-line noise, a scannable hierarchy rather than a flat list.80- **`ux-microcopy-audit`** *(Tier A)* — this skill leans hard on copy: plain labels, action-based toggle labels, helper text, and confirmation-dialog headings/CTAs.81- **`ux-information-architecture-audit`** *(Tier B — offer)* — whether the grouping scheme and ordering match users' mental model (card-sort evidence), and whether labels carry scent.82- **`ux-dark-patterns-audit`** *(Tier A)* — destructive actions placed last but *not hidden*; no confirmshaming on cancellation; no forced retention friction.83- **`ux-mobile-responsiveness-audit`** *(Tier B — offer)* — touch targets, the app-vs-OS permission split, save-button reach (sticky bottom), one-handed use.8485If the audits surface a conflict (e.g., security wants confirmation on everything vs. fast settings), resolve back toward the primary task: **users came to change one thing and leave — protect the dangerous changes, get out of the way on the rest.**8687---8889## Common do/don't patterns9091| ❌ Don't | ✅ Do |92|---|---|93| Dump every option in one flat list | Group by type/use case with headings + white space |94| Use settings as a junk drawer for stray links | Only real preferences; everything else lives elsewhere |95| Order by internal logic | Order by how often users change each setting; advanced hidden |96| Technical/jargon labels | Plain words from how users actually talk; short helper text nearby |97| Hide the current value | Show each setting's status beside it |98| "Notifications: Off" as a toggle label | Action-based label ("Email notifications") + visual on/off state |99| Destructive actions up top — or hidden entirely | Last, set apart by color/space; present, not buried (→ dark-patterns) |100| Save silently / not at all | Save state: disabled → active → loading → success toast (+ Undo) |101| Autosave a multi-field or sensitive edit | Explicit Save for deliberate/sensitive; autosave atomic toggles |102| "Are you sure?" / "Cancel" on a delete dialog | Specific heading + unambiguous action-word CTAs |103| Bolt search onto a 5-item page | Minimize options first; add search when scrolling/sub-menus appear |104| Ship without checking | Hand off to heuristics + accessibility + aesthetics + microcopy + IA + dark-patterns + mobile-responsiveness |105106---107108## Source lessons (Uxcel)109110- [How to Design Useful Settings Pages](https://uxcel.com/lessons/settings-best-practices-572)111- [Saving Changes](https://uxcel.com/lessons/saving-changes-390)112- [Mobile Settings Design](https://uxcel.com/lessons/mobile-settings-745)
Uxcel-Lab