Settings page design: how 96 SaaS products organise settings

By Screenrove editorial · 22 October 2026

Settings page design data from 316 screens in 96 SaaS products: sidebar vs modal navigation, section mix, avatar uploads, rare danger zones and inline rules.

Of 316 settings screens we captured across 96 SaaS products, 78 open in a modal over the app rather than on a page of their own, and only 24 show a danger zone. Those two numbers frame this study of settings page design: the settings area is lighter and more ambient than the classic admin template, and the red delete block that every template includes is missing from most of what we saw.

Below we count how those screens are organised and how the best ones put the rule or the consequence beside the control. Every screen is on the Settings & account pages wall, filterable by the same attributes we count here.

Settings page design by section: the numbers

Each screen is tagged with one main section. The table counts screens, with products in brackets; the navigation columns say how each screen is reached.

Read the section mix with one caveat. Workspace (86 screens) and appearance (59) lead partly because our research flows renamed a workspace and switched the theme in most products, so we hold several screens per product there. Billing is the more telling number: 52 screens from 44 products, close to half the set, because billing is where a free account is reminded what it lacks. Security (7), notifications (7) and integrations (4) are thin, which reflects what a fresh research account has to look at.

Navigation: sidebar by default, modal for preferences

137 screens (43%) sit behind a dedicated settings sidebar, 78 (25%) in a settings modal, 61 (19%) behind tabs and 40 (13%) on a single page. Counted by product, 52 of 96 use a settings sidebar somewhere and 42 use a modal; 39 products use more than one pattern.

The split follows the section. Appearance is the only section where the modal wins (26 screens against 17 in a sidebar), while billing almost never opens in one: 36 of 52 billing screens are sidebar pages and just 3 are modals. Preferences float over the work; money gets a page with a URL.

The products that do put everything in a modal give it a full two-level rail, not a single page of toggles. Kittl stacks personal items (Account, Notifications) above the team's own (General, Members, Security, Plan & Billing) under the team name. Mermaid Chart groups Personalization, Connections and Account. Krea's appearance modal carries the same Account, Workspace and Developer groups as its full-page settings.

Whatever the container, the clearest navs split personal from shared settings in the headings. Dub groups Workspace, Developer and Account; Amplitude runs Personal, Workspace, Permissions and Product Configuration; Shortcut has My Account, Workspace Settings and Workspace Features.

The nav is also where upsells live. Retool puts seven "Enterprise" or "Business" pills in its settings sidebar, Runway marks four of seven workspace tabs (Analytics, SSO, Audit Logs, Model Configuration) with an upgrade arrow, and Toggl stars premium items in its admin nav.

Avatar and logo upload is a workspace job

56 screens from 35 products show an avatar or logo upload. 38 of them are workspace screens and only 9 are profile screens: in this set, the image people are asked for is the team's, not their own. Empty slots fall back to an initial on a coloured tile.

The useful detail is the rule beside the button. Dub lists "Square image recommended. Accepted file types: .png, .jpg, .webp, .avif. Max file size: 2MB." Runway says "Min. 200x200px, .PNG or .JPG" and Kittl "less than 1MB". Toggl goes a step further and says where the image ends up: "Use your organization image as a logo on invoices and PDF exports."

Rules and consequences next to the control

The habit that most separates good settings pages from average ones is a line of copy beside the control that states the rule, or what will happen. No attribute counts it, so here are the clearest examples.

• Rules in a card footer. Dub puts "Max 32 characters." under the workspace name and "Only lowercase letters, numbers, and dashes. Max 48 characters." under the slug.
• Effects under each toggle. Amplitude: "If disabled, CSV exports will include a leading space to prevent injected code execution."
• Settings written as sentences. Checkly sets escalation in prose with inline selects: "When a check has failed [1] time(s)." and "Send out a maximum of [0] reminders, with a [10 minutes] interval."
• Defaults spelled out. VEED opens each privacy toggle with "By default…" and then says what turning it off changes.
• Timing and reach. Toggl's Enforce 2FA card: "This takes effect the next time they log in." Shortcut: "Enabling or disabling features is effective immediately for the entire workspace. Data is preserved for disabled features." Grafana confirms because "This will update the preferences for the whole organization."
• A consequence per option. Kapwing gives each workspace-visibility choice its own line, such as "They can request to join but need approval from an admin."

The sharpest example is a confirm step for a change that does not look dangerous. Renaming a URL feels cosmetic; Superthread stops you to say it "will break any links to cards, pages, and boards that you've shared outside of Superthread (for example in emails, Slack, or external sites)."

Danger zones are rarer than templates suggest

Only 24 of 316 screens (8%) show a danger zone, from 17 products, and 18 of those 24 are workspace screens. Of the 52 products with a workspace screen, 14 showed one. The styling ranges from loud to almost silent:

• Netlify uses the full template: "Danger zone / Irreversible and destructive actions", "Once you delete a team, there is no going back. Please be certain." and a solid red button. Its delete dialog lists three consequences, asks for up to three reasons from twelve checkboxes and makes you type the team name.
• Sanity labels it "Potentially destructive actions" and uses red text on a pale pink button for "Leave project", with the effect spelled out: "You will lose access immediately and an administrator will need to re-invite you to rejoin."
• Mixpanel counts the loss in coral chips ("0 Events", "0 User Profiles") and warns "1 Project members will lose access."
• Whimsical treats it as one more row: "Workspace deletion" with a red-outlined "Delete workspace".

Tables: billing first, sessions never

22 screens from 19 products use a table. Ten are billing or usage, five are members and two are notifications. Hygraph lays usage out as Resource, Used, Limit and Percentage columns; Superthread colours each usage bar by severity, red for "2/2 (Limit reached)". Not one screen in the set shows an active-sessions or login-history table, and only one developer screen is tabular (Cloudinary's upload presets). Token pages such as Mermaid Chart's open on an empty "Create new token" card.

Members tables are short and wide. Plane splits Members into People and "Agents and apps" tabs and adds Billing Status and Auth columns. Penpot keeps its Invitations, Role and Status headers over the empty state. For notifications, the matrix wins: Gumroad lists events against Email and Mobile toggle columns, and Lucidchart adds a master toggle to each group.

Dark mode share

42 screens (13%) are dark, from 26 products. Seven products (Bolt, CodeSandbox, Penpot, StackBlitz, Rive, Opus Clip and Leonardo) were dark in every settings capture. The other 19 appear dark only after we switched the theme, which is why 15 of the 42 are appearance pages.

How we counted

We captured these screens in desktop browsers with research accounts in October 2026, mostly on free plans or trials. A vision model recorded each screen's section, navigation type and features, and every attribute is checkable on the screen's own page. Counts are screens unless we say products, and the section mix reflects the tasks we ran (renaming a workspace, switching theme) as much as what each product offers. We record what we saw, not how any layout performs.

What to steal

1. Group the nav by who a setting affects: personal, workspace, developer. Dub, Amplitude and Shortcut do it in the headings.
2. Put the rule under the field before the error: character limits, allowed characters, file types and sizes.
3. Give every toggle one line that says what changes, for whom and when, like "This takes effect the next time they log in."
4. Add a confirm step for changes that break things quietly, such as URLs and slugs, not only for deletes.
5. In a delete flow, show what will be lost in numbers, as Mixpanel does, and ask for the typed name, as Netlify does.
6. Use a matrix for notifications: events as rows, channels as columns.
7. If settings live in a modal, give it the full rail, as Kittl and Mermaid Chart do, and keep billing on a page with its own URL.

Filter the wall to workspace screens with a danger zone or connect the Screenrove MCP server and ask your agent for "workspace settings in a modal" while you build yours.