Flow Settings

Settings & Account Management

Overview

Settings are visited rarely and under a specific goal ("turn off that email," "delete my account") — so findability beats aesthetics, and destructive actions must be impossible to trigger by accident yet never hidden from users who need them. Organize by the user's mental model, not your org chart or database schema.

When to Use

• Building a settings/preferences area for web, iOS, or Android
• Adding account security flows: email change, password change, 2FA, active sessions
• Designing delete-account, delete-workspace, or any irreversible action
• Adding data export (GDPR/CCPA portability)
• Not for: in-context controls that belong next to the content they affect — a document's sharing settings live on the document (see flow-sharing)
• Not for: first-run onboarding preference pickers

The Proven Flow

1. Entry

   • Avatar or gear icon, top-right on web; profile tab or gear on mobile.
   • Landing view shows the settings nav with the most-visited section (Profile/Account) already open — never an empty "pick a category" splash screen.

2. Navigation

   • Web: left sidebar of grouped categories, content pane on the right (GitHub, Stripe Dashboard).
   • Mobile: single scrolling list of grouped rows drilling into detail screens (iOS Settings).
   • Group by user mental model:
     • You: Profile, Account, Security, Notifications
     • Preferences: Appearance, Language, Privacy, Integrations
     • Money: Billing, Plan, Invoices
     • Org (multi-user products): Members, Teams, Permissions — visually separated from personal settings. GitHub splits personal vs organization settings entirely; Stripe separates account vs team. Users must always know which scope they're editing.
     • Danger zone: last, always.
   • Items needing attention carry a badge or inline alert: unverified email, expiring card, missing 2FA — settings is where users expect to resolve account health.

3. Search

   • Add it above the nav once you exceed ~15 settings. Users don't browse settings — they hunt.
   • Match setting labels, descriptions, and synonyms: "dark mode" must find "Appearance → Theme."
   • Results deep-link to the exact control, scrolled into view and briefly highlighted. iOS Settings and Chrome's settings search both do this.

4. Individual settings

   • Each row: label, one-line description of consequence (not a restatement), and the control.
   • Toggles apply instantly, confirmed by the state change itself or a brief toast.
   • Forms (profile fields) use an explicit Save button — disabled until dirty — plus an unsaved-changes guard on navigate-away.
   • Never mix auto-save and explicit-save within the same section; users can't tell what's applied.
   • Avatar upload gets crop-and-preview plus an initials fallback; username changes warn about consequences ("your profile URL changes and old profile links break immediately; repo links redirect until the old username is reclaimed" — GitHub's rename model).
   • Feature surfaces deep-link into settings: the "Manage notifications" link in an email or a nudge lands on that exact settings row, not the settings home.

5. Email change

   • New email field → verification link sent to the new address → change applies only on verification.
   • Notification email to the old address with a "this wasn't me — secure my account" link.
   • The old email keeps working until verification completes. GitHub and Google both work this way. An instant swap on submit is an account-takeover vector via one stolen session.

6. Password change

   • Current password (or fresh re-auth) → new password with inline strength meter and visible requirements → confirm.
   • On success: confirmation screen, email notification, and an offer to sign out all other sessions.
   • Sensitive pages require recent authentication — GitHub's "sudo mode," Stripe's re-auth. Re-prompt when the session's last auth is older than ~15–60 minutes.

7. Two-factor authentication setup

   • Offer methods in security order: passkey / authenticator app first, SMS as fallback only (SIM-swap risk) — state the recommendation inline.
   • Setup: QR code + manual key → user enters a code to prove it works → recovery codes shown once, with download/copy buttons and a "I've saved these" confirm before finishing.
   • Disabling 2FA requires re-auth plus a second factor, and triggers a security email.

8. Notification settings

   • Matrix by event type × channel (email / push / in-app), not a single master toggle plus mystery.
   • Every email footer's "unsubscribe/manage" deep-links to this exact screen.
   • Security notifications are not disableable — say so: "Security alerts can't be turned off."

9. Data export

   • One button: "Request export." Async job → email with an expiring, auth-gated download link.
   • Show job state inline: "Export requested Jul 7 — we'll email you when it's ready."
   • State what the export contains ("all documents, comments, and account data") so users can judge completeness before deleting anything.
   • Formats: JSON/CSV plus media files. Never gate export behind a support ticket — GDPR Art. 20 makes portability a right, and export is the trust-preserving companion to deletion.

10. Delete account — the canonical destructive flow, three gates in order

11. Confirm intent: a button in the Danger Zone opens a dedicated screen or modal — never a bare "Are you sure?"

12. Show consequences concretely: "Deletes 3 workspaces and 1,240 documents (subscription paid through Aug 12). This cannot be undone." Enumerate real counts from real data. Apple/Google-billed subscriptions can't be canceled by the developer — link the platform's manage-subscriptions sheet and state the subscription must be canceled there (App Review 5.1.1(v)). Offer alternatives on this same screen: export data, downgrade to free, deactivate instead.

13. Type-to-confirm: the user types their username, email, or the phrase "delete my account" exactly — GitHub's repo-deletion pattern. Typing engages deliberate attention; a checkbox does not. Then re-auth if the session isn't fresh. The submit button is red, labeled with the consequence ("Delete this account"), and disabled until the phrase matches.

• Afterward: sign out everywhere, send a confirmation email, and ideally hold a 30-day soft-delete grace window with reactivation-by-login. Whichever policy is real, say it — faking permanence and faking deletion both destroy trust and invite regulators.

11. Sessions & security events

• List active sessions: device, approximate location, last active. Per-session revoke plus "Sign out all other sessions."
• Mark the current session — "This device" — so users don't revoke themselves by accident.
• Send email on: new-device sign-in, password change, email change, 2FA change. Each email carries a recovery link.

Layout & Structure

• Groups of 3–7 items. More than 7 in a group → split the group. More than ~9 top-level categories → merge, or make search primary.
• Hierarchy depth ≤ 3: category → screen → control. Deeper is unfindable without search.
• One column of controls. Label left, control right (web rows / iOS cells); consequence description under the label in secondary text.
• Danger Zone: bottom of the Account or General page, visually distinct — GitHub's literal red-bordered "Danger Zone" card. Contents: only destructive, irreversible actions (delete account, transfer ownership, leave organization). Never place a destructive action adjacent to a routine one.
• Destructive buttons: red/destructive style; never the default-focused button in any dialog; never triggered by Enter; always at least one deliberate extra step away. In confirmation dialogs the safe action gets default focus and prominence.
• Button copy names the action, never "Yes"/"No"/"OK": "Delete 3 documents" / "Cancel."
• Consequence-first descriptions beat label restatements: "Stops all email except security alerts" — not "Controls your email settings."
• Platform specifics:
  • iOS — grouped inset lists, system cells, red text rows for destructive actions. Apple Guideline 5.1.1(v): if the app supports account creation, account deletion must be initiable in-app.
  • Android — standard preference-screen pattern; respect system back behavior between levels.
  • Web — every settings page has a stable, shareable, deep-linkable URL.
• Disabled ≠ hidden: settings unavailable on the current plan stay visible, disabled, with a one-line reason ("Available on Pro") — hiding them makes users doubt the feature exists.
• Accessibility: toggles are real switches with accessible names matching the visible label; keyboard focus order follows visual order; destructive confirms trap focus in the dialog with the safe action focused first.
• Current value visible at rest: rows that drill into a detail screen show the current selection inline ("Language — English") so users don't open screens just to check state — iOS Settings' core convention.
• Confirmation emails for identity changes only: email, password, 2FA, and payment method changes get an email; toggling dark mode does not. Over-notifying trains users to ignore the security emails that matter.

Quick Reference

Anti-Patterns