Settings pages are where a product's history shows. Every feature adds a toggle, nobody removes one, and after three years you have a wall of switches no one can navigate.
Some rules I follow.
Group by what the user is trying to do, not by where the code lives
"Notifications" is a user goal. "Integrations" is a user goal. "Advanced" is not; it is where the team put things it could not decide about.
Every setting needs a sentence
Not a label. A sentence that says what changes when you flip it. "Send me an email when someone comments on my post" beats "Comment notifications".
Show the current state, not the action
A toggle that reads "Enable dark mode" is ambiguous when it is on. "Dark mode: on" is not.
Dangerous things go at the bottom, in their own section, and ask twice
Delete account, transfer ownership, reset API keys. Separate, visually quiet, and confirmed with the current password.
Search, once there are more than about twenty
A settings search box is cheap to build and the single most used feature of a large settings area.
Save as you go, or make saving impossible to miss
Either each change saves itself with a quiet confirmation, or there is one save bar that follows you down the page. The worst option is a save button at the bottom of a long page and no warning when you leave.
I have designed six of these now. The best one had eleven settings. The worst had ninety. Ledgerly's has fourteen.
