Figma settings page examples

Settings is the one area of an application where information architecture is the entire design. Nobody browses settings.

They arrive with one thing to change, having already guessed which category it lives under, and the whole experience is decided by whether that guess was right. Profile and account screens, billing, notification preferences, team permissions and integrations all end up in the same drawer, and they have almost nothing in common except that people find them by hunting.

Two shells, and where the settings navigation lives

These screens are drawn in two application shells, and the difference is instructive. In the first, a 280px sidebar navigation holds the app while the settings sections sit in a row of horizontal tabs under the page header.

In the second, a 108px header navigation runs across the top and the settings sections move into vertical tabs beside a narrower content column.

Vertical tabs scale better, since a fourteenth label costs one more row instead of forcing a scrolling tab strip, and the W3C tabs pattern handles them properly with up and down arrow keys once aria-orientation is set to vertical. Horizontal tabs are the better choice when you genuinely have five or six sections and want them all visible.

The two column form row

Inside the sidebar shell the main area is 1,160px wide with a 32px inset, giving a 1,096px content column. Form rows split it: a 280px section label on the left, a 784px field column on the right, with dividers between rows and a section footer holding the actions at the end of each block.

That left label column is what makes a settings form scannable, because the labels form a vertical index you can run your eye down without reading a single field. It also means a save button lands at the bottom of a long page, which is a bet that the user scrolled. If a section can save on change, let it, and keep the explicit save for forms where a half finished state would be worse than no change at all.

What the screens cover

The set works through the screens a real product needs: personal details with an avatar upload and a rich text bio field, a company profile with a logo upload, a members list built from avatar rows, a plan screen where a pricing tier card and a usage progress bar sit above a table, notification preferences built from checkbox and radio grids with toggles, an appearance screen with a color picker and preview cards for light and dark, a list of sign in locations with a device icon and a status badge, and integrations shown both as rows and as cards.

Roughly half the screens lean on a table, several with pagination underneath, which is a reminder that most settings work is really list management wearing a different hat.

Deciding what belongs on the first screen

The hard part of settings is not layout, it is deciding what a user sees before they click anything. Progressive disclosure is the principle worth applying: show the few controls people change often, and put the rest one clearly labelled level down.

Every screen here exists at 1,440px and at 375px, where the sidebar collapses to a 56px bar and the content narrows to 343px, and the whole set is duplicated in dark mode. Building the mobile version early is a useful forcing function, because a settings screen that will not fit a phone is usually a settings screen with too many options.

When it is time to build, Untitled UI React settings pages are open source, built with Tailwind CSS and React Aria, with tab navigation, form state and keyboard behaviour already handled.