Summarize with AI
The settings page is the most ignored UX surface in most SaaS products. It is designed last, receives the least design attention, and generates a disproportionate number of support tickets. Users who are actively trying to configure a product to fit their workflow should not have to search for basic settings. But on most products, they do.
A well-designed settings page communicates that the product was built by people who thought carefully about every part of the experience, not just the exciting features. A poorly designed settings page signals the opposite, regardless of how good the rest of the product is.
The fundamental mistake: designing for the database, not the user
Most settings pages are structured around how the settings are stored in the database or organised in the codebase. Account settings contain everything to do with the account. Advanced settings contains everything the engineering team considered too complex for general users. General settings contains everything else.
Users do not think about settings in terms of database categories. They think about settings in terms of tasks: I want to change how often I receive email notifications. I want to add a new team member and set their permissions. I want to connect our CRM to this product. I want to cancel my subscription.
A settings page organised around user tasks instead of technical categories is more discoverable, faster to navigate, and generates fewer support tickets. The navigation labels should describe what the user is trying to accomplish, not what the engineers named the module.
Information architecture that works
The most effective settings navigation in 2026 follows a consistent pattern across B2B SaaS products. Profile and account covers individual user settings: name, email, password, profile photo, notification preferences. Team and workspace covers organisation-level settings: team members, roles and permissions, workspace name and branding. Integrations and connections covers third-party tools and API access. Billing and subscription covers plan management, payment methods, and invoices. Security covers two-factor authentication, login history, and session management.
This structure maps to how users think about configuration tasks. Someone who wants to change their notification preferences goes to Profile. Someone who wants to add a team member goes to Team. The mental model matches the information architecture.
The failure pattern is the settings page that has a Profile section, a General section, a Preferences section, and an Account section with overlapping content between them. Users who cannot predict which section contains what they need have to search through multiple sections for every setting. Every unsuccessful prediction is a small friction that adds up to a poor overall experience.
The findability test
Run a simple test on your current settings page: ask someone who is familiar with the product but has not recently used the settings to find five common settings. Time each one. If any takes more than thirty seconds, the information architecture has a findability problem.
Common high-priority settings that users should find instantly: how to change their email notification frequency, how to invite a new team member, how to connect a common integration, how to change their password, and how to access billing information. These are settings that generate support tickets when they are hard to find. Getting them in obvious locations is directly correlated with reduced support volume.
Immediate effect vs save actions: removing ambiguity
One of the most common sources of confusion on settings pages is the inconsistency between settings that take effect immediately and settings that require an explicit save action. Users who change a setting and are not sure whether it has been applied are left in a state of uncertainty that generates follow-up questions and sometimes accidental duplicate actions.
The convention that works: toggles and switches take effect immediately and show a confirmation state, like a brief success indicator, after the change. Form fields that involve typing, like changing a name, email, or password, use an explicit save button that applies all changes in that section at once. Mixing these patterns without clear visual differentiation creates the ambiguity that generates most settings-related support tickets.
Role-appropriate settings: showing the right things to the right people
A team member who sees admin-only settings that are greyed out and labelled requires admin permission gets a message that the product has capabilities they cannot access rather than a clear view of what they can actually control. This creates unnecessary questions and reduces the perception of the settings page as a useful tool.
Better design: show each role only the settings they can actually change. If it is genuinely useful to communicate to non-admins that a setting exists, show it in a read-only state with a clear explanation, not as a disabled control that creates uncertainty about whether the limitation is temporary or permanent.
According to Nielsen Norman Group's visibility of system status heuristic, interfaces should always keep users informed about what is going on through appropriate feedback within reasonable time. A settings page that shows controls users cannot use without explaining why violates this principle. The user is not informed about their actual capabilities.
How Studio Maydit approaches settings page design
We treat settings pages as first-class product design surfaces, not as afterthoughts. The work starts with a content audit of every setting, organisation by user task rather than technical structure, and a findability test before any design work. The result is a settings page that reduces support tickets, communicates product polish, and gives users confidence that every part of the product was designed with the same level of care.
If your settings page is generating support tickets or if users are regularly asking where to find things, book a free 30-minute call with Studio Maydit.
