Settings page design: how to organize an app's preferences

What is a settings page?

It is where users store their preferences and where the app asks for the options it needs to work in each person’s context. It is often one of the least visited screens in a product, but a poorly designed one creates a lot of friction: a user arrives with a specific task, such as muting a notification, and cannot find the option.

The key is that the page is not a drawer for everything the team did not know where to put. Each setting should have a reason to be there, and users should be able to find it without knowing the technical name the engineering team gave it.

How do you group settings?

Grouping is the first thing that makes a settings page readable. According to Setproduct’s guidance on settings UI, tabs suit a moderate number of categories, and side navigation becomes more useful when there are many options. In both cases each group needs a descriptive label, such as “Notifications” or “Privacy”, rather than “Advanced options” or “Misc”.

Some practical rules:

• Group by the user’s task (“what do I want to control”) rather than by the product’s internal structure (“which module implements it”).
• Put the categories people check most often first.
• Highlight the active section so users know where they are. Breadcrumbs help when there are sublevels.
• If you use side navigation, make sure it adapts to small screens. Setproduct suggests collapsing it or turning it into a hamburger menu.
• If there are many settings, put a visible search field at the top of the page. Setproduct recommends it, with suggestions as the person types.

How do you choose default values?

A default is the answer the system gives on the user’s behalf before they do anything. Because most people never open the settings page, that value ends up being the real configuration for almost everyone.

Nielsen Norman Group frames it this way in its article on pagination preferences: most users prefer to use the default settings, so it is the designer’s responsibility to pick the default that benefits the most people. Setproduct’s operational advice points the same way: for radio buttons, choose the most common or recommended option; checkboxes should start unchecked.

If the user does change a setting, the system should remember it. Nielsen Norman Group notes that the system should almost always respect the preference a user stated and use it as the default next time, instead of making people repeat the choice.

How should changes be saved?

It helps to separate two cases:

Nielsen Norman Group says a toggle should take effect immediately and should not require clicking Save. If the result cannot be instant, it recommends radio buttons or a single checkbox. It also advises separating controls that produce instant results from those that need a command button, so they are not mixed in the same form.

After saving, give visible feedback. A short confirmation message is enough. If the change can be reverted, say so in the message.

How do you write labels people understand?

Settings labels are scanned, not read closely. NN/g recommends short labels with the key term first and no question form. “Email notifications” works better than “Do you want to receive email notifications?” because it describes what happens when the switch is on.

A useful test: read the label aloud and add “on” or “off”. If the phrase does not sound natural, rewrite it.

When should you NOT add a setting?

Before creating a setting, ask whether most users will need it. Every new option is one more decision the user has to make, and one more that they can get wrong. Because most people never customize, a strong default configuration does more for them than a long list of switches.

Do not add a setting when:

• A well-chosen default already solves the case for almost everyone.
• The option only changes something the user sees once a year.
• The same decision could be made in the context of the task instead of on the settings page.

Example

Illustrative example: a booking app has a settings page. Originally, every option sat in one long list with more than thirty checkboxes. The team redesigned the page with five groups named after tasks (“My account”, “Notifications”, “Privacy”, “Payments”, “Language and region”), added a search field at the top, set booking-only notifications as the default, and moved “Delete account” into its own section with a confirmation that explains what gets erased. The biggest gain was in notifications, which now have one toggle per channel and a status line underneath.

Common mistakes

• Grouping by internal module name instead of by what the user wants to do.
• Mixing settings with immediate effect and settings that need saving in the same group, without making the difference clear.
• Choosing a default that suits the business instead of the majority of users.
• Forgetting to remember the preference the user just chose.
• Hiding destructive actions among normal options, without confirmation.
• Vague labels such as “Advanced” or “Other” that force people to open every section to find out what is inside.
• No feedback after saving, so the user does not know whether the change worked.

For actions like these, see destructive action safeguards. If you are not sure which categories users expect, start with reviewing what already exists in similar apps and then talk to the people who use them. To check the grouping before you design the screen, information architecture covers the principles to apply.

Sources

• Toggle-Switch Guidelines, Nielsen Norman Group
• Users’ Pagination Preferences and “View All”, Nielsen Norman Group
• Settings UI design: why users can’t find what they need, Setproduct