Group settings by who owns the decision and what happens when it changes, not by which part of the product they belong to. Most settings pages are organised around the engineering team's mental model, which is why a customer looking for one switch has to check four tabs.
Settings are the screen nobody designs and everybody adds to. A feature ships, it needs a switch, the switch goes on the settings page, and three years later there are sixty of them in no discernible order.
This is the framework we use when we untangle one, plus the specific rules that stop it happening again.
Because nothing forces them to stay coherent. A dashboard gets redesigned when the metrics change. A checkout gets scrutinised because revenue depends on it. Settings just accumulate, one pull request at a time, and no single addition ever looks like the problem.
The second reason is that settings are where teams resolve disagreements. When two people cannot agree on a default, the compromise is to make it configurable. That feels like a win and it is a tax paid by every future user.
Nielsen Norman Group made this point a long time ago and it has not aged. Its guidance is that it is imperative to retain a good default design for non customizing users, rather than resolving design debates by offering excessive preference settings. Every switch you add is a decision you have handed to someone who did not ask for it.
That it costs more than teams assume. Jakob Nielsen's write up on customization of user interfaces and products, published on August 16, 2009, separates two things people confuse. Customization is where the user tells the computer what he or she prefers to see. Personalization is where the computer modifies its behavior to suit its predictions about the current user's interests.
The findings in that work are worth holding onto. Interface customization sites achieved 83 percent task completion, matching non customization sites. Product customization sites averaged only 66 percent task completion, a significant decline, and users reported feeling more lost and less in control on customization websites.
That research is old and the interfaces it studied look nothing like today's products, so treat it as a directional caution rather than a benchmark. The direction has held up in our own work. Every settings page we have been asked to fix was too big, never too small.
Before a setting gets a home, answer five questions about it. Who owns this decision. What is its scope. Is the change reversible. How often does it change. What breaks if it is wrong. The answers tell you where it goes and how it should behave.
Ownership is the strongest grouping signal. A billing contact, a workspace admin and an individual user are different people with different jobs, and mixing their settings into one list guarantees confusion. Split by person first, always.
Scope is second. Does this change affect only me, my team, or everyone in the account. A setting that silently changes something for colleagues needs to say so at the point of change, not in documentation nobody reads.
Reversibility decides the interaction. An easily reversed setting can apply immediately with no ceremony. An irreversible one needs a confirmation step and a plain sentence about what will happen. Those are different components, and using the same one for both is how accidents happen.
Frequency decides the placement. Something a user changes weekly should not be four clicks deep behind a settings icon. If a setting is really part of the workflow, it belongs in the workflow, and calling it a setting is often a way of avoiding a harder design decision.
Consequence decides the copy. A setting whose worst case is a slightly different colour needs a two word label. A setting whose worst case is a customer losing access needs a sentence, and probably a link to a document. Match the weight of the words to the weight of the outcome.
It depends on the control, and the rule for toggles is unusually firm. Nielsen Norman Group's toggle switch guidelines, published on July 29, 2018 by Alita Kendrick, state that toggle switches should take immediate effect and should not require the user to click Save or Submit to apply the new state.
That guidance goes further. If immediate results are not achievable, the article says to use a different UI element instead. A toggle with a save button is not a slightly worse toggle, it is the wrong control, because the affordance promises something the system does not do.
Text fields are the opposite case. A name, an address or an API label is edited over several seconds and should not fire a request on every keystroke. So a settings page will usually have both behaviours, and the honest way to handle that is to make the two zones visually distinct rather than pretending they are the same.
Two options, clear labels, obvious state. The same NN/g guidance is that toggle switches handle exactly two mutually exclusive options with a default value. If your setting has three states, it is not a toggle, and forcing it into one produces the classic mystery of what the off position actually means.
On wording, the guidance is that labels must be short and direct, and must describe what the control will do when the switch is on. They should not be neutral or ambiguous. It offers a good test, which is to say the label aloud with on or off appended. Email notifications on works. Do you want to receive email notifications from us on does not.
On state, it recommends high contrast colour and visual cues such as movement and colour, and notes that state descriptors like On and Off can help, placed consistently on the same side to avoid ambiguity. Consistency matters more than the specific choice.
With real groups, not just visual ones. The W3C Web Accessibility Initiative's guidance on grouping form controls says that grouping related form controls makes forms more understandable for all users, as related controls are easier to identify. It uses fieldset as the container and legend as the group heading.
Radio button groups always need this treatment. Checkbox groups and related fields, such as separate shipping and billing addresses, benefit from the same. If the visual design makes fieldset styling difficult, WAI notes that WAI-ARIA provides a grouping role that functions similarly, using role="group" with aria-labelledby, which provides additional styling possibilities.
The underlying requirements are WCAG 1.3.1 Info and Relationships at Level A and 3.3.2 Labels or Instructions at Level A, with techniques H71 for fieldset and legend, ARIA17 for grouping roles, and H85 for optgroup in select elements. Our WCAG guide covers where those sit in the wider standard.
Separate them, name them plainly, and make the confirmation cost something. Deleting a workspace, revoking every API key or removing a user's access do not belong in the same visual rhythm as a notification preference.
The pattern we use is a distinct section at the bottom with different styling, a plain statement of the consequence in a full sentence, and a confirmation that requires deliberate action rather than a reflexive click. Typing the resource name is a heavy pattern and it is appropriate here.
What we avoid is the softened version, where a dangerous action is styled like every other button because the design system only has one button. That is a case where the system should grow a variant rather than the page hiding the risk. Our notes on building a web design system cover how to add that without fragmenting the library.
Past a certain size, yes, and needing it is a signal. If a user cannot find a setting by scanning the groups, search rescues the individual attempt while confirming the structure has failed. Add it, and treat the need for it as a to do rather than a solution.
Search also has to work on synonyms. Users look for the word in their head, not the word in your product. If your setting is called Digest frequency, someone searching for email will find nothing, and they will conclude the feature does not exist.
The cheap version of this is to include a few alternative terms in the searchable text for each setting. It takes an afternoon and it removes a whole class of support ticket.
List every setting, and for each one write down the five answers: owner, scope, reversibility, frequency, consequence. Then check how many settings have the same owner but live in different places, and how many have different owners but sit in the same list. Those two counts are your rework.
Then look for settings nobody has changed. If a switch has been touched by under one percent of accounts in a year, ask whether it exists because someone genuinely needed it or because two people could not agree on a default. Removing it and picking a good default is usually the better product.
If you would like a second pair of eyes on a settings area that has grown past the point of sense, we are glad to look. You can reach our team at phoenix.studio, and our piece on SaaS dashboard UX covers the screen most people reach settings from.
Tell us where you want to go. We'll tell you how we'd get you there.