Figma tree view components

A tree view answers a question a flat list cannot: what is inside this, and what is that inside of. File browsers use one, so do folder pickers, permission scopes, category managers, org charts, and the left rail of most API documentation.

The pattern survives because it lets someone open one branch six levels deep while everything else stays collapsed and out of the way. The 3 tree view components and 4 variants above give you a simple and an advanced type at two sizes, assembled from item and connector pieces you can also use directly.

Use one only when the hierarchy is real

Trees are frequently reached for by habit. If the nesting is one level deep, a grouped list with a subheading reads faster and takes less space, and if users mostly want to compare items rather than locate them, a table beats a tree outright.

The honest test is whether people arrive knowing roughly where their item lives. When they do, expanding two nodes is quicker than any search box. When they do not, they will expand everything, and at that point you have built a long list with extra indentation.

Depth has a practical ceiling too: at 280px wide, past three or four levels the labels start truncating and the tree becomes a guessing game.

Indentation, and the connector at the last child

Indentation alone tells people something is nested; connector lines tell them exactly which parent it belongs to, which matters once siblings have children of their own. This set treats those lines as a component with three types: a default vertical run for a branch that continues, an end connector for the last child in a group, and a none type for levels that need the space but not the line.

That last-child elbow is the detail that separates a tidy tree from one where a vertical line runs off past the final item into nothing. Both types come at sm and md to match the row height they sit beside.

Two sizes and four properties on the item

Rows are 32px tall at sm and 36px at md. The item component crosses three properties independently: Open for whether a branch is expanded, Selected for whether the row is the current one, and State for default and hover.

Keeping open and selected apart is the important part, because they are genuinely different facts. A folder can be expanded without being the thing you are looking at, and a selected file has no children to expand at all. Kits that collapse the two into one "active" state force designers to fake the combination later.

The simple type runs 240px wide for a plain label and chevron; the advanced type runs 280px and carries the extra content that sidebar navigation and file managers tend to need. Rename, move and delete usually sit behind a context menu on the row rather than in the row itself.

Arrows do the expanding, not Tab

The one thing worth writing on the frame before handoff. The W3C tree view pattern gives the whole tree a single tab stop, then uses the right arrow to open a node or step into its first child, the left arrow to close it or jump back to the parent, up and down to move between visible rows, and typed characters to jump to a matching name.

Each parent row behaves as a disclosure, which is exactly what the Open property is describing in design terms. Tabbing through 200 nodes is the failure mode this prevents, and it is a common one.

When it is time to build, the same trees exist in code. Untitled UI React tree views are open source, built with Tailwind CSS and React Aria, with expansion, selection, and full arrow-key navigation handled for you.