Settings screens used to be the last thing I touched on any project. The onboarding flow got weeks of attention, the dashboard got a whiteboard session and three rounds of review, and then on a Friday afternoon I’d throw together a list of toggles and call it done. I don’t do that anymore, and the reason has a name: Carrow.
The problem with leftover screens
Carrow was a scheduling tool for small physiotherapy clinics, built by a four-person team in Leeds. By the time I joined, the core booking flow was solid. Clients could pick a time, pay a deposit, get a reminder text. Nobody had thought much about settings because nobody thought settings mattered. There were 11 toggles scattered across three tabs, labeled things like “Enable advanced mode” and “Sync behavior.”
Support tickets told a different story. Nearly 40 percent of them traced back to settings confusion: clinics turning off notifications by accident, double-booking because a sync toggle meant something different than they assumed. The screen nobody designed was generating the most friction in the entire product.
What changed my mind
I started reading through six weeks of support transcripts before touching Figma. That alone was unusual for me. Normally I’d sketch flows first and validate later. Here, the validation came first because the evidence was already sitting in a help desk inbox, unread by anyone on the design side.
The Carrow project
What I found was that every confusing toggle mapped to a decision the team had made quickly, without asking what the clinic owner actually needed to know versus what the engineering team needed to configure. “Sync behavior” was really three separate choices bundled into one switch: calendar direction, conflict handling, and which calendar counted as the source of truth. No wonder nobody understood it.
We rebuilt the settings section from scratch over three weeks, this time first in the project order rather than last. That meant mapping every setting to a real support ticket or a real onboarding question before deciding it deserved a place in the interface at all.
A different order of operations
Now, on any new project, I ask for the settings requirements in the first week, alongside the core flows. Not because they’re equally complex, but because they reveal what the team hasn’t agreed on yet. If nobody can tell me clearly what a toggle does, that’s not a copywriting problem. It’s a product decision still waiting to be made.
Start with the edge cases
Settings screens are where edge cases concentrate. A main flow can ignore the clinic that has two locations, or the user who wants reminders in Spanish but invoices in English. Settings can’t ignore them, because that’s precisely where those people go looking for control. Designing settings early forces the edge cases onto the table before they become support tickets.
For Carrow, that meant a short list of questions before any screen got drawn:
- Who changes this setting, and how often, after the first week of use?
- What happens if we remove this toggle and just pick the sensible default?
- Does this setting affect one person, or everyone on the clinic’s account?
- If this breaks, does the support team get a ticket, or does the clinic just lose data quietly?
That last question eliminated three toggles outright. They existed because an engineer wanted a way to debug sync issues, not because any clinic needed to see them.
What this costs you
Doing this early is slower at the start. Clients want to see the exciting screen, the one that will go in the pitch deck, and settings rarely make it into a pitch deck. I’ve had to explain, more than once, why I’m spending the first sprint on toggles instead of the hero flow everyone’s excited about.
Priya Nair, who ran product at Carrow, put it well after we shipped the new settings section:
We used to think of settings as the part of the app where we apologized for complexity. Now it’s the part where we prove we understand the clinic’s actual day.
Support tickets related to settings dropped from 40 percent to under 12 percent within two months of the new release. Nobody on the team expected that number to move that much, because nobody had expected the old settings screen to be doing that much damage in the first place.
The rule I use now
I still design the exciting screens with the same care I always did. But settings go into the schedule in week one, not week six, and every toggle has to survive the same question: does a real person need to see this, or does it exist because it was easier to expose than to decide? Most products have a few toggles that fail that test. Finding them early is cheaper than finding them in a support queue a year later.
