Skip to content
Fundur
T3 · Complete designSettings & AccountPublished 12 days ago

Settings That Explain Themselves

A settings architecture where nobody has to guess what a toggle does.

Opens in
Figma, React, Tailwind
Screens
12
Components
22
Dark mode
Included
Accessibility
WCAG AA
A settings architecture where nobody has to guess what a toggle does.

01 / 03

01The problem

Twelve screens of settings for a product with a hundred of them, organised by what a person is trying to change rather than by which team built it.

02The brief

A B2B product had accumulated 94 settings across seven screens, organised by the team that shipped each one. Support handled the same six questions every week, all of which were 'where is X' or 'what does X actually do'.

Who it's forProduct teamsFoundersSupport leads
ConstraintsNo settings could be removed — every one had a customer depending on it. The work was entirely architectural.
03The approach

Group by user intent, not by system boundary. Every setting gets a one-line consequence statement in the same voice, and anything destructive is separated by layout rather than by a confirmation dialogue.

Reference landscape

  • SlackRight about search-first settings, punishing hierarchy
  • GitHubRight about danger zones, inconsistent copy
  • macOS System SettingsA cautionary tale about reorganising without renaming
04The insight it turns on

A setting without a stated consequence is a guess.

Most settings UI names the mechanism and hides the outcome. Writing the consequence line first — before the label, before the layout — reveals which settings are duplicates, which are actually two settings, and which nobody can explain and should therefore be a default.

05How it was made

Stage by stage

  1. 01

    Understand

    Read every support ticket mentioning settings for a quarter. The complaints clustered on six settings, none of which were the complicated ones.

  2. 02

    Gap analysis

    94 settings, 94 consequence lines written by hand. The exercise itself was the finding — eleven could not be written at all.

  3. 03

    Information architecture

    Seven system-shaped screens became twelve intent-shaped ones. Counter-intuitively, more screens with clearer names beat fewer screens with mixed contents.

  4. 04

    Design system

    22 components, including a documented danger-zone pattern that never relies on a modal to carry the warning.

06The hard parts

What was difficult

Reorganising settings breaks every support article and every customer's muscle memory.

Old locations are kept as redirecting stubs that name the new home, and the handoff includes a mapping table for the support team. The migration is part of the deliverable, not an afterthought for the buyer.

Eleven settings had no explicable purpose.

Rather than delete them — the brief forbade it — they are grouped into an advanced section with an honest heading, which surfaced the political question instead of hiding it.

07What's inside

Exactly what you get

  • Figma source
  • 12 screens
  • 22 components
  • Light + dark
  • React + Tailwind
  • Written IA rationale
Version
1.0.0
Formats
Figma, React, Tailwind
Screens
12
Components
22
Dark mode
Yes
Prototype
Yes
Accessibility
AA
Figma
2026.2

Dependencies

  • Inter — SIL Open Font Licence — included
  • Radix UI — MIT — patterns referenced, not bundled

Commercial fonts are never redistributed — they are named and linked, with a free equivalent substituted in the delivered files.

08What it changed

Eleven settings turned out to be duplicates or unexplainable. The architecture absorbed the other 83 into twelve screens with no search required.