Settings is where a product's accumulated decisions go to live, and it is the screen most likely to have been built by six people over three years. The result is familiar: forty controls in no order, half of them saving instantly and half behind a button, and a delete account link one click from a checkbox.
The components are simple. The structure is the work.
The layouts
Sections on one page. Grouped blocks with headings, scrolled through. Right up to about twenty settings.
Tabs or a sidebar. Past that, split by subject: profile, account, notifications, billing, team, danger. Each section needs its own URL, not just a state flag, so a support reply can say "open this link" and land the reader exactly there. The tabs guide has the routing argument.
Glass Account Settings Card by Moumen Soliman is the assembled card shape, and Form Layout by Ephraim Duncan is the labelled-rows arrangement most settings pages want. Profile Dropdown by kokonutd and Profile Dropdown by Arihant jain are the entry points people actually use to get there.
Save instantly or save explicitly
Pick one per section and never mix them on one screen, because a page where some controls apply immediately and others wait for a button is a page where nobody knows what state they are in.
Instant suits toggles: notifications, theme, feature flags. It needs a visible confirmation - a brief inline "Saved" beside the control, not a toast in the corner - and it needs an error path that puts the switch back and says why.
Explicit suits text: names, addresses, anything typed. A save bar that appears when something changes, with save and discard, and a guard against navigating away with unsaved edits.
The pattern that fails is a page-level Save button above thirty controls, twenty-five of which already saved themselves.
The danger zone
Delete account, delete workspace, transfer ownership, revoke everything. The convention of a separate section with a destructive border exists because these need distance from the toggles.
Four rules. Put them last, in their own block. Make the confirmation typed - the name of the thing being deleted - rather than a checkbox, so the action cannot be muscle memory. Say exactly what will be lost and whether it can be recovered. And where you can, make it reversible for a period rather than instant, because the most common support ticket in this area is somebody who meant to delete something else.
The details that make it feel maintained
Show current values, not placeholders. A settings field that shows a placeholder where the value should be reads as empty.
Say what a setting does, once. One line of helper text under the control beats a tooltip nobody opens.
Group by the reader's mental model, not your schema. "Notifications" is a section; "user_preferences_table" is not.
Search, past about forty settings. At that size people stop navigating and start hunting, and the palette guide applies.
Show which settings are inherited or enforced. In a team product, a control the reader cannot change needs to say who set it, not just appear disabled.
Every control needs a real label. A row of switches with only headings above them is the most common accessibility failure here: the switch itself has no accessible name.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| shadcn/ui | Switch, Form, Tabs and AlertDialog, which is most of a settings page | You design the structure |
| An auth or billing provider | The account, session and plan sections, already wired | Their look inside your page |
| 21st | Account cards, form layouts and the profile entry points | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a settings page, get the previews inline, and let the agent write the file.
Frequently asked
- Should settings save instantly or behind a button?
- One or the other per section, never both on one screen. Instant suits toggles and needs a visible inline confirmation and an error path that puts the switch back. Explicit suits typed values and needs a save bar with discard plus a guard against navigating away with unsaved edits.
- How should a delete account action be protected?
- Its own section at the end, a typed confirmation naming the thing being deleted rather than a checkbox, a clear statement of what is lost and whether it can be recovered, and where possible a recovery window instead of an instant irreversible action.
- When should settings be split into tabs or a sidebar?
- Past about twenty settings. Each section then needs its own URL rather than a state flag, so a support reply can link straight to it. Past about forty, add search, because people stop navigating and start hunting.
- What is the most common accessibility failure on a settings page?
- Switches with no accessible name. A row of toggles under a heading looks labelled and is not: each control needs its own label, and settings the reader cannot change need to say who enforced them rather than simply appearing disabled.