Settings as a directory, not a wall of tabs

The most honest thing you can say about a settings screen is that nobody wants to be there. People open settings to change one thing and leave. So the measure of a good settings screen is how fast it gets someone to the one row they came for, and how little else it asks them to hold in their head on the way.

Ours had drifted from that. As the product grew, so did the number of things to configure, until a single screen carried more than a hundred fields behind a set of tabs and pills. It was complete, and it was searchable, and it still felt like walking into a hardware store with no signs. The problem was not the amount of settings. It was that everything on the screen had the same visual weight, so the eye had nothing to grab.

When a heading looks like a button

The specific failure was subtle and, once you see it, obvious. A group like Essentials sat at the same size and colour as the items inside it. So Essentials read as a thing you could tap, not as a label for the things below it. The hierarchy was there in the markup and invisible on the screen. People told us they could not tell the categories from the items, and they were right.

The rebuild starts from a different mental model: settings is a directory. A short list of named destinations, grouped, each with a one-line description of what lives there in plain language. Business details is "Name, contact details and address." Opening hours is "When clients can book you." You should be able to find the right row without opening anything.

Rows are items, headings are not

The thing that fixes the heading-looks-like-a-button problem is making items unmistakably items. Every row now carries a small leading icon and a trailing chevron, and it lights up on hover. Group labels carry none of that: no icon, no chevron, no hover, and a hairline rule opens each new group. Before you read a single word, the shape of the page tells you which things are destinations and which are just labels.

That is the whole trick, and it is worth saying plainly because it is easy to reach for cleverer answers. We did not need collapsible accordions or a nested tree or a redesigned navigation model. We needed the items to look like items and the labels to look like labels. Consistency of affordance, not novelty.

One thing at a time

Tapping a row does not scroll you to a section on a long page. It replaces the directory with just that section and its save button, plus a quiet "All settings" control to go back. You are looking at opening hours and nothing else. The reduction in on-screen options is the point: someone changing their hours is not also being shown their tax configuration and their loyalty rules.

The engineering constraint we set for ourselves was that none of the actual settings could change. Every field, every save action, every server-side validation had to keep working exactly as before; only the way you navigate to them was allowed to change. So under the hood the whole form is still there and still submits as one unit. The directory and the focused view are two states of the same data, and a direct link to a section still lands you straight in it. It is a navigation change wearing the clothes of a rewrite.

We did not simplify the settings. We simplified the finding.

The general lesson

Density is not the enemy; undifferentiated density is. A screen with a hundred controls can be calm if it has a clear structure and only shows you one part of it at a time. A screen with twenty controls can feel like a wall if they all shout at once. When a screen feels overwhelming, the first question is not "what can we remove" but "what has the same weight that should not." Fix that, and a lot of the overwhelm goes with it.