VibeWeek
Home/Grow/Settings & Account Management Pages: The Page Founders Forget Until Customers Complain

Settings & Account Management Pages: The Page Founders Forget Until Customers Complain

⬅️ Day 6: Grow Overview

If you have user accounts in 2026, settings pages are where users go when they need to change something. Most indie SaaS treats settings as an afterthought — a Profile page with name + email + password — and discovers gaps when customers ask "where do I add another team member?" / "how do I change billing?" / "where's my API key?" / "how do I delete my account?" The fix is a deliberate information architecture: settings split between user-level (my profile, my notifications) and org-level (team, billing, security, integrations); navigation that scales as features grow; permissions per page (admin vs member); and discoverability so users find the setting they need without 3 clicks of guessing.

A working settings architecture answers: how to split user vs org settings, how to organize sections (5-15 categories typical), how to handle permissions (admin-only vs member-visible), how to handle multi-org users (workspace switcher), where to put high-stakes operations (delete account; transfer ownership), how to make discoverable (search; prominent placement), and how to evolve as features compound (don't end up with 50 categories).

This guide is the implementation playbook for settings pages. Companion to Roles & Permissions, Multi-tenancy, Notification Preferences & Unsubscribe, Account Deletion & Data Export, Two-Factor Auth, and Session Management Patterns.

Why Settings Architecture Matters

Get the failure modes clear first.

Help me understand settings failures.

The 8 categories:

**1. User vs org settings mixed**
"Profile" page has account email AND team members. Confusing.

**2. Settings discoverable only by hunting**
User wants to change billing; clicks Profile → not there; tries Account → not there; tries elsewhere → 5 minutes lost.

**3. Permissions inconsistent**
Member sees "Billing" link → clicks → 403. Should not have seen the link.

**4. Multi-org confusion**
User in 3 workspaces; toggles to Settings; whose settings? No clear context.

**5. Destructive actions buried**
"Delete Account" hidden in 4-clicks-deep page; OR too prominent (accidental clicks).

**6. No search / hard to navigate**
30 settings; no Cmd+K; no search; user gives up.

**7. Save / cancel UX inconsistent**
Some pages auto-save; others have Save button; user doesn't know what's been persisted.

**8. Mobile UX broken**
Side-nav doesn't work on mobile; no responsive layout.

For my product:
- Top settings complaints
- Worst current page

Output:
1. Top failure modes
2. User-impact estimates
3. Priorities

The biggest unforced error: single "Settings" page with 50 fields. Discoverability dies; mobile breaks; permissions get sloppy. Split into navigable sections with clear hierarchy.

The 2-Layer Architecture: User vs Org

Help me design the architecture.

The principle: separate user-level (this person across orgs) from org-level (this workspace).

**User-level settings** (per-person):
- Profile (name; avatar; email)
- Password / 2FA / passkeys
- Sessions / connected devices
- Personal notifications (email subscription preferences)
- Personal API keys / tokens
- Connected accounts (Google / GitHub / Slack login)
- Account deletion

**Org-level settings** (per-workspace):
- General (org name; logo; URL slug)
- Team / members (invite / remove / roles)
- Billing & plans
- Integrations
- Security / SSO / SAML
- Audit log
- Custom domain
- API (org-level keys; webhook config)
- Data export / org deletion

**The URL structure**:

/settings/account ← user-level /settings/profile ← user-level /settings/security ← user-level (sessions / 2FA) /settings/notifications ← user-level

/[org-slug]/settings/general /[org-slug]/settings/team /[org-slug]/settings/billing /[org-slug]/settings/integrations


Or alternatively:

/settings ← user-level (always) /[org-slug]/admin ← org-level (admin only)


The URL hierarchy makes the distinction obvious.

**The navigation**:

User-level:
- Top-right: "Profile" / avatar dropdown → "Account settings"
- Lands on /settings (user-level)

Org-level:
- Within workspace: sidebar / header link "Settings" or "Admin"
- Lands on /[org]/settings/general

Don't:
- Put org settings in the user-profile dropdown
- Mix user + org settings in one nav

For my product:
- Multi-org? (likely yes for B2B)
- Current architecture

Output:
1. User vs org split
2. URL structure
3. Navigation

The discipline: explicit org-context in URL. /[org-slug]/settings makes it clear which workspace. Without: user changes setting; doesn't know if it applied org-wide or personally.

Section Organization

Help me organize sections.

The 8-12 standard sections (mid-market B2B SaaS):

**User-level**:

1. **Profile**
   - Name; display name; avatar; bio
   - Pronouns (modern; default empty)
   - Display preferences (timezone; locale; date format)

2. **Account**
   - Email
   - Password
   - Account email (transactional; required)
   - Account deletion

3. **Security**
   - 2FA setup
   - Passkeys
   - Active sessions / devices
   - Login history

4. **Notifications**
   - Per-category opt-in (see [Notification Preferences](notification-preferences-unsubscribe-chat.md))
   - Channels (email / push / in-app)
   - Cadence

5. **Connected Accounts**
   - Google / GitHub / Slack OAuth
   - API keys (personal)

**Org-level**:

6. **General** (org)
   - Org name; URL slug; logo
   - Default timezone / locale
   - Public profile (if applicable)

7. **Team / Members**
   - Invite / remove
   - Roles (admin / member / etc.)
   - Pending invites
   - Group / departments (if applicable)

8. **Billing & Plans**
   - Current plan; usage
   - Payment method
   - Invoices
   - Plan upgrades / downgrades
   - Cancel subscription

9. **Integrations**
   - Connected services (Slack / GitHub / etc.)
   - Webhooks
   - API keys (org-level)

10. **Security (org)**
    - SSO / SAML
    - SCIM provisioning
    - Domain restrictions
    - Allowed login methods

11. **Audit Log**
    - Recent admin actions
    - Filtering / export

12. **Advanced** (often hidden)
    - Custom domain
    - Org deletion
    - Data export
    - White-label settings (if applicable)

**The principle**:

Group like things. "Notifications" with "Notifications"; "Security" with "Security." Don't scatter.

Order matters: most-used first. Profile / Account / Security typically top.

For my product: [feature inventory]

Output:
1. Sections per layer
2. Order
3. Navigation labels

The 2026 trend: Linear / Vercel / Stripe-style settings nav: vertical sidebar; icons + labels; ordered by frequency-of-use. This is the modern default.

Permissions Per Page

Help me handle permissions.

The discipline: hide what users can't access.

**Member view**:
- Profile (own)
- Account (own)
- Security (own)
- Notifications (own)
- Connected Accounts (own)
- Team (read-only; see members)
- Integrations (depends on role)
- Audit log (limited; sometimes none)

**Admin view**:
- All member-view items
- Plus: Team management (invite / remove / change roles)
- Billing & Plans
- SSO / Security
- Audit Log (full)
- Org General (rename, etc.)
- Org Deletion / Transfer

**The implementation**:

1. **Hide nav items user can't access** (don't show + 403)

```typescript
const navItems = [
  { label: 'Profile', href: '/settings/account', visible: true },
  { label: 'Billing', href: '/settings/billing', visible: user.role === 'admin' },
  // ...
];
  1. Server-side permission check (defense in depth)

Even if nav hidden, route handler must verify:

if (request.path === '/settings/billing' && user.role !== 'admin') {
  return redirect('/settings/account');
}
  1. Visible-but-disabled (for partial access)

For "your role doesn't allow this" cases:

  • Show the page
  • Disable destructive actions
  • Show "Contact admin" CTA

E.g. member can SEE billing page (knows the plan; usage); can't change.

For my permissions: [roles]

Output:

  1. Per-section permissions
  2. Hide vs disable
  3. Server-side enforcement

The trap: **leaving stale "Billing" link visible to members**. They click; get 403; feel locked-out. Worse: server-side missing → access bug.

## Multi-Org / Workspace Switching

Help me handle multi-org users.

For B2B SaaS where users belong to multiple orgs (consultants; agency users; multi-account):

Workspace switcher:

Top-left dropdown:

  • Current workspace (highlighted)
  • List of joined workspaces
  • "Create workspace" CTA (if applicable)

Click switches context; URL updates; settings + data refresh.

Settings context clarity:

  • User-level: "Settings" (no workspace prefix)
  • Org-level: "[Workspace Name] Settings" (clear)

Don't show org-level settings while in user-context. Mix = confusion.

Per-workspace member roles:

User can be admin in workspace A; member in workspace B. Permissions per workspace.

Implementation:

CREATE TABLE workspace_members (
  user_id UUID,
  workspace_id UUID,
  role VARCHAR(20),
  joined_at TIMESTAMPTZ,
  PRIMARY KEY (user_id, workspace_id)
);

Permissions check: query role for current workspace + user.

Default workspace:

User logs in: which workspace shows?

  • Last-active workspace (cookie)
  • First-joined workspace (fallback)
  • Personal workspace (if you have personal-by-default model)

For my product: [multi-org model]

Output:

  1. Switcher UI
  2. Default workspace
  3. Permissions per workspace

The discipline most teams skip: **clear workspace context in nav at all times**. Without: user changes settings; later realizes they applied to wrong workspace; data corruption.

## Discoverability: Search + Cmd+K

Help me make settings discoverable.

The standard solutions:

1. Cmd+K palette

Already covered in Keyboard Shortcuts. Settings should be searchable via Cmd+K:

User types "billing" → palette shows "Billing settings" User types "2FA" → palette shows "Security → Two-Factor Auth"

Implementation: index all settings pages + sub-sections; expose via cmdk.

2. Settings page search

Search input at top of settings: "Search settings..." → autocomplete to specific settings page or section.

<input placeholder="Search settings (e.g. 'password', 'billing', 'team')" />

Some apps (Slack, GitHub) put search prominent on settings page.

3. Direct URLs

Most settings should have specific URLs:

  • /settings/security/2fa
  • /settings/billing/payment-method
  • /settings/team/invitations

Allows direct linking from emails / docs.

4. Sitemap on root settings page

If user lands on /settings (no specific section), show categorized cards:

Profile          Account          Security
Notifications   Integrations    Connected accounts
[Org-level]
Team            Billing          Audit log

Visual; scannable.

5. Help-center linking

In settings, link to docs: "Learn about 2FA in our help center"

Don't make user search docs separately.

For my product: [discovery today]

Output:

  1. Cmd+K integration
  2. Settings search
  3. URL structure
  4. Sitemap design

The win that compounds: **deep-linkable settings**. Customer-support emails: "click here to set up 2FA" → direct link to specific page → 1 click. Without: "go to Settings → Security → 2FA" → 3-step instruction → user error.

## Save / Cancel UX Discipline

Help me handle save UX.

The 3 patterns:

Pattern 1: Auto-save on blur

User edits field; clicks elsewhere; saves automatically.

Pros: low friction Cons: user can't review before commit; mistakes propagate

Use for: low-risk fields (display name; avatar)

Pattern 2: Save button (manual)

User edits; clicks Save; persists.

Pros: explicit; user can review Cons: mandatory click; "did I save?" anxiety

Use for: medium-risk (email change; password)

Pattern 3: Save + Cancel + dirty warning

User edits; "Save" + "Cancel" buttons appear; navigation triggers "you have unsaved changes" warning.

Pros: explicit; safe Cons: more UI

Use for: complex forms; high-risk

The 2026 default:

  • Single field changes (name): auto-save with toast
  • Multi-field forms: explicit Save
  • Destructive (delete account): typed confirmation

Toast pattern:

After save: "Saved" toast (3-5s). After failure: "Couldn't save. Retry" toast (persistent).

Don't:

  • Silent saves (user wonders if it worked)
  • Modal "Saved!" (interrupting)
  • No feedback at all

Dirty-state warning:

If user navigates away with unsaved changes:

"You have unsaved changes. Discard? [Cancel] [Discard]"

For my forms: [pattern per]

Output:

  1. Pattern per field type
  2. Toast / feedback
  3. Dirty warning

The pivotal detail: **always confirm save with toast**. Without: user wonders. Toast = "saved"; user moves on.

## Destructive Operations: Delete Account, Transfer, etc.

Help me handle destructive actions.

The high-stakes operations:

Delete account (user-level):

  • Permanent (after grace period)
  • Cascade: delete data; remove from workspaces; cancel subscriptions

Delete workspace (org-level):

  • All data in workspace gone
  • Members lose access
  • Subscription cancelled

Transfer ownership (org-level):

  • Pass admin to another member
  • Original admin demoted

Remove team member:

  • Their access revoked
  • Their data... what happens? (orphaned / re-assigned)

Cancel subscription:

  • Keeps access until period end
  • Triggers downgrade flow

The UX:

  1. Bury appropriately: settings / Account → bottom of page; "Danger zone" section
  2. Type confirmation for destructive:
"Delete account permanently?

This cannot be undone. Your account, all data, and subscriptions will be deleted after 30 days.

Type your email to confirm: [______]
[Cancel] [Delete account]"

Type-to-confirm catches accidents.

  1. Grace period:

For account / workspace deletion:

  • Mark as "deletion-pending"
  • 30 days to recover
  • Cron deletes after grace

User sees "Account deletion scheduled for [date]. Cancel?" link.

  1. Email confirmation:

After delete request:

  • Send email: "Your account is scheduled for deletion. If you didn't request this, click here to cancel."
  • Catches account-takeover attempts.
  1. Audit:

Log all destructive actions:

  • Who initiated
  • When
  • IP / user-agent
  • Forensics-friendly

For my destructive operations: [audit]

Output:

  1. UX per operation
  2. Type-confirmation
  3. Grace period
  4. Audit log

The discipline: **type-to-confirm for destructive**. Cost: tiny UX friction. Benefit: catches 99% of accidents. Required.

## Mobile Settings UX

Help me handle mobile.

The challenges:

1. Side-nav doesn't fit mobile screen

Patterns:

  • Mobile: list-style settings page (no sidebar; scroll through)
  • Or: hamburger / drawer for nav; tap to navigate

2. Responsive forms

Multi-column desktop forms → single-column mobile. Adequate touch targets (44px+).

3. Long settings pages on small screens

Use sticky section headers (CSS position: sticky). Or: collapsible sections (accordion).

4. Cmd+K not on mobile

Replace with prominent search input + visual cards.

5. Native iOS / Android settings parity

If you have mobile app: settings UX should match your web settings semantically; don't reinvent on mobile.

For my mobile: [test]

Output:

  1. Responsive pattern
  2. Mobile-specific UX
  3. Cross-platform parity

The check: **set browser to phone width; navigate every settings page**. Half the issues you'll find: side-nav covering content; buttons too small; forms unwieldy. Fix iteratively.

## Common Settings Mistakes

Help me avoid mistakes.

The 10 mistakes:

1. User vs org settings mixed Confusing context.

2. Single big settings page 30 fields; no hierarchy; mobile breaks.

3. Stale nav items (member sees admin) Click → 403; feels locked-out.

4. No deep links Support has to give multi-step navigation.

5. Auto-save without feedback "Did it save?"

6. Destructive without confirmation Accidental account deletion = support nightmare.

7. Mobile broken Side-nav covers content.

8. No search 30 settings; user can't find.

9. Inconsistent save patterns Some auto-save; some need button; user confused.

10. Settings only built reactively Customer asks for X → ship X with bad UX → repeat.

For my product: [risks]

Output:

  1. Top 3 risks
  2. Mitigations
  3. Audit

The discipline: **architect settings BEFORE you have 20 of them**. Building reactively means each new addition is shoehorned in; eventually unreckonable. Plan the IA early.

## What Done Looks Like

A working settings architecture:
- Clear user-level vs org-level split
- 8-12 sections, ordered by frequency-of-use
- Vertical sidebar nav (desktop) / list view (mobile)
- Permissions enforced server-side; UI hides for visible roles
- Workspace switcher with clear context
- Cmd+K integration for search
- Deep-linkable URLs
- Toast confirmation on save
- Type-to-confirm for destructive
- 30-day grace period for delete-account
- Email confirmation + audit log on destructive
- Responsive mobile layout

The proof you got it right: a customer asks "how do I change billing?" → support links to /settings/billing → 1 click; fixed. A new admin tours settings; finds everything; doesn't request improvements. Mobile users complete settings tasks without complaint.

## See Also

- [Roles & Permissions](roles-permissions-chat.md) — companion permission layer
- [Multi-tenancy](multi-tenancy-chat.md) — workspace context
- [Notification Preferences & Unsubscribe](notification-preferences-unsubscribe-chat.md) — notification settings page
- [Account Deletion & Data Export](account-deletion-data-export-chat.md) — destructive ops
- [Two-Factor Auth](two-factor-auth-chat.md) — security settings
- [Session Management Patterns](session-management-patterns-chat.md) — sessions in security tab
- [Password Reset & Magic Link](password-reset-magic-link-chat.md) — password change
- [SSO & Enterprise Auth](sso-enterprise-auth-chat.md) — SSO settings
- [Audit Logs](audit-logs-chat.md) — audit settings page
- [API Keys](api-keys-chat.md) — API key management
- [Internationalization](internationalization-chat.md) — locale settings
- [Time Zone Handling](timezone-handling-chat.md) — timezone settings
- [Form Validation UX](form-validation-ux-chat.md) — settings forms
- [Toast & Snackbar Notifications UI](toast-notifications-ui-chat.md) — save feedback
- [Keyboard Shortcuts & Command Palette](keyboard-shortcuts-command-palette-chat.md) — Cmd+K integration
- [Dark Mode Implementation](dark-mode-implementation-chat.md) — theme setting