Settings pages are where trust is won or lost
People open settings when something has gone wrong. What they find there decides whether they stay.
Nobody opens a settings page because they're happy. The bill was higher than they expected, a teammate can see something they shouldn't, or the emails won't stop. Settings is where people go to fix a product that has let them down a little.
That makes it the most emotional screen in most products, and the one we design last. Over the past year I rewrote about 200 settings for Saltmarsh Freight. Here's what I learned, in the order I'd do it again.
The most emotional screen
Think about the last time you went looking for a setting. You probably weren't browsing. You had a specific worry and a little irritation, and you wanted to be sure that whatever you changed would actually fix it.
A settings page has one job in that moment: to let someone leave sure of what they changed. Every decision below follows from that.
The best settings page is the one people leave sure of what they changed.
Write the sentence first
Before drawing anything, I write every setting as one plain sentence, in the words a customer would use. "Email me when an invoice fails." "Let drivers see the customer's phone number."
If I can't write the sentence, the setting isn't ready. Usually that means it's doing two things at once, or nobody on the team can say what it does. Both are worth finding out before there's a switch.
- Say what will happen, not what the feature is called.
- Say who it affects: only you, or the whole team.
- Say when it takes effect, and whether it can be undone.
Group by the job, not the database
Saltmarsh had eleven settings pages, named after the tables in their schema: Accounts, Entities, Preferences, Integrations. Customers had to guess which one held the thing they wanted, and they guessed wrong about half the time.
We moved to four pages named after jobs: your account, your team, billing and notifications. Then we added search that works from anywhere: press / and type what you want to change.
Show the consequence before the change
The settings people regret are the ones with consequences they didn't see. So for anything that affects other people, money or data, the page says what will happen before it happens.
| Setting | What we show first |
|---|---|
| Remove a teammate | The 14 shipments they own, and who takes them over |
| Change billing plan | The new monthly price and the date it starts |
| Turn off driver alerts | Which drivers stop getting texts, by name |
None of these need a dialog. A sentence under the control, updated as you change it, does the job and doesn't interrupt.
Errors are settings too
An error message is a setting you didn't choose. It's the product telling you something is configured wrong, often at the worst moment. We rewrote every one of Saltmarsh's 60 errors with the same rule as the settings: say what happened, then say what to do.
Support tickets about settings fell by about 30% in the two months after launch. Most of that, I think, came from the errors, not the layout.
Where to start on yours
- List every setting and error in one document.
- Write each one as a sentence a customer would say.
- Group the sentences by the job someone came to do.
- Only then open your design tool.
It's slow at first and quick by the end. And it's the cheapest way I know to make a product feel trustworthy, because it's mostly words.