Sidebars fit deep, item-heavy structures
Aliases: navigation rail · hierarchical sidebar
What it is
Sidebar navigation is a vertical inventory glued to one side of the content, built to hold more destinations than a tab bar or top-bar slots can, including the children under those destinations. It is not for “looking like an admin tool”. It is for an information architecture that is both deep and wide: too many items for one row, too many levels to flatten into a single layer. Cramming that tree into a bottom bar, or hiding it behind one button, puts the tree in the wrong container.
Why it happens
A vertical list grows with screen height. Items can scroll; groups, indents, and expand/collapse all sit on one visual spine. People scan a scrollable catalogue, not a handful of icon slots. Depth is said with indent and disclosure: the parent stays in view, children appear beneath it, and place itself states belonging. Width is spent on words, so long names need not collapse to icons on contact.
The mechanism assumes someone will give up a strip of horizontal space and will switch repeatedly between catalogue and content. Workbenches, document libraries, settings hubs, and admin consoles match that assumption — the job is to find a place in a stable tree and work there. Consumer feeds do not: few destinations, shallow depth, and a sidebar becomes an empty decoration that also pinches the content. Capacity is not a licence to pour rare links, account settings, and in-context actions into the same column. The sidebar holds places one can remain in, not a toolbox.
Where it stops holding
A phone in portrait has almost no width to spare; the same tree usually becomes a push-in drawer or a stacked list, and it is false to claim the sidebar fits every width. When the tree is shallow and has only four or five items, a tab bar or top-level tabs scan cheaper. When the tree is very deep (four or five levels), successive disclosure inside the sidebar becomes a second page stack and people get lost in the indent; drill those levels in the content pane instead of adding more indent. Rapidly changing personal shortcuts also sit poorly as a frozen sidebar structure.
Applying it
- Count top-level destinations and typical depth first. Choose a sidebar only if the top level exceeds what a tab bar can show at once, or if two or more stable levels exist. Do not add a sidebar for admin atmosphere.
- Put only remain-able spaces in the sidebar. Group titles are labels, not links. Actions (new, import) live inside a group or at the content top, not competing in the same column as destinations.
- Expand by default along the path to where the user is. Do not open the entire tree on arrival, and do not leave icons alone to carry hierarchy.
- How to check: print the sidebar copy as a table of contents and ask someone new to the product how they would reach a deep function. A wrong path means that depth should become a content drill, not more sidebar indent. Then check the narrowest viable desktop width: the main task must still fit.