The Settings Page Is Where Good Design Gets Lazy

Every product has a settings page, and in a surprising number of them, it looks like it belongs to a different product. A long list of toggles with technical labels, options added over years in no particular order, and a save button that may or may not be needed. Nobody designed it as a whole. It accumulated.

It's easy to see why. Settings aren't part of the sales pitch. They don't appear in screenshots or demos. They get built at the end of each project, often by whoever is adding the feature that needs a new option.

Why settings matter

People visit settings at important moments. They want to change their email address, stop notifications that are annoying them, update a payment card or cancel. Many of those visits come from frustration. If the page is confusing, a minor annoyance turns into a support request, or a reason to leave.

Settings also shape how the product behaves every day. A notification preference that's hard to find means people get interrupted more than they want. A privacy option that's hard to understand means people either worry or give up.

Organising by what people want

The most common problem is organisation. Settings tend to be grouped by how the product was built, with technical categories that make sense to the team but not to anyone else. We regroup them by what people are trying to do: their account, notifications, privacy, billing and so on.

Within each group, the most used options come first. Rarely used and advanced options go further down or into a clearly labelled section. Search helps in large products, because people often know the name of the setting they want even if they don't know where it lives.

Labels people understand

Settings are full of jargon. Labels like "Enable sync" or "Allow third-party integrations" mean little without context. We write labels that describe the outcome and add a short line explaining what each option does. "Email me when someone replies to my post" is clearer than "Reply notifications".

Toggles are worded so their meaning is obvious both on and off. Double negatives, such as "Disable hiding of inactive items", have no place on a settings page.

Saving clearly

People need to know whether a change has taken effect. Some products save each change immediately. Others need a save button. Both can work, but mixing them on one page is confusing. We choose one approach per page and make it visible: a brief "Saved" confirmation for instant changes, or a clear save button that shows when there are unsaved changes.

Handling the serious stuff

Settings often include serious actions like changing a password, deleting an account or cancelling a subscription. These need extra care. They should be easy to find, because hiding a cancel option is frustrating and increasingly against consumer rules. They should explain clearly what will happen, and where an action can't be undone, they should ask for confirmation in a way that makes people read.

Fewer settings

The best settings page is often a shorter one. Every option is a decision passed to the user, and many settings exist because the team couldn't agree on a default. Where we can choose a good default and remove the option, we do. It makes the page easier to use and the product easier to maintain.

The same standard

We apply the same design system, with the same type, spacing and components, to settings as to everything else. It makes the product feel whole and costs very little extra once the system exists. It's a standard part of our app development process.

If your settings page has grown into a junk drawer, it might be worth an afternoon of attention. We can help.