Figma vertical tabs components

Vertical tabs show up once a section list has outgrown its header. Account settings with eleven areas, a billing section, an admin panel where every item is a noun phrase rather than a word, a documentation page with a column of topics down the left. The axis is doing something specific here. Adding a twelfth section costs one more row, and rows are the cheap direction on a screen that already scrolls.

What the vertical arrangement buys you

Two things, mostly. Labels stop competing for horizontal room, so "Notifications and alerts" can be a label instead of a truncation problem, and a stacked list is quicker to scan because the eye travels one axis and each label starts at the same left edge. Nielsen Norman Group's work on left side vertical navigation makes the same case for site level menus, and the reasoning carries down to a section switcher inside one page.

The cost is real, since the column eats horizontal space that the content would otherwise have. A workable rule is to switch around six sections, or earlier if any label runs past two words. The settings page examples are the clearest place to see the difference, because the same screens are drawn once with a horizontal strip and once with this column.

Five types, and a column that hugs its labels

The set covers a primary filled item, a gray filled item, a bordered container, a minimal text list, and a Line type that marks the current item with a rule rather than a fill. Sizes are sm and md.

The individual rows come from the same tab button base as the horizontal set, which puts the filled and minimal rows at 36px tall at sm and 44px at md, while the Line rows are leaner at 24px and 32px. That difference compounds down a column: at sm the Line type fits a ten item list into 312px, where the bordered type needs 404px for the same list.

Column width is not a fixed number, because each list hugs its longest label under Auto Layout, so in the preview file the sm columns sit between 137px and 145px and the md columns between 149px and 161px depending on the type. Change the copy and the column follows, which is the behavior you want and a nuisance if you were hoping to pin the content area to a round number.

The mobile variant is a row

Every type also exists at the mobile breakpoint, and there it stops being vertical. The mobile variants are a single 343px wide item, 36px tall at sm and 40px at md, because a twelve item column on a phone would push the actual content below the fold before anyone read a word.

That reversal is the part worth designing on purpose rather than discovering at the end. Decide whether the phone gets a scrolling row, a select that names the current section, or a separate index screen that links into each one.

Arrow keys point down

Orientation changes the keyboard behavior as well as the layout. Under the W3C tabs pattern, a tab list with aria-orientation set to vertical moves with the up and down arrow keys instead of left and right, and a keyboard user who presses Down and watches nothing move will assume the list is a set of links.

Every type in this set carries a focus state at both sizes, so the current item and the focused item can be told apart, which is the one detail a stacked list makes obvious when you get it wrong.

When it is time to build, Untitled UI React tabs are open source, built with Tailwind CSS and React Aria, and take an orientation so the vertical arrangement arrives with the right arrow key behavior rather than the horizontal one.