Surface, don't bury | LlamaPress Pattern Catalog
LlamaPress
Pattern Catalog
Principle

Surface, don't bury

Prominence equals frequency times importance. The work people do every day should be the easiest to reach, and rarely-used things should live deeper — that is correct, not a bug.

Navigation gets organised around how the team thinks about the system rather than around what people do with it, so a daily task ends up three levels inside a settings menu and a one-time setup screen sits in the main nav.

The formula

Prominence = frequency × importance.

Rank features by how often they are used and how much it matters when they are. The top of that list earns space in the main navigation. Everything else earns depth.

The formula's real work is the multiplication. Frequent and trivial (a filter) does not deserve the same prominence as rare and critical (issue a refund). Neither does rare and trivial, which is most of what accumulates in a navigation bar.

Burying is a legitimate outcome

The goal is not to surface everything. One-time setup, admin configuration, account settings and destructive maintenance operations should be deep. Depth is a design decision that says "you will not need this often, and you will not hit it by accident."

The failure is not depth. The failure is depth that does not match usage — and the only way to know is to look at what people actually do, not at what the feature list looks like.

How it goes wrong

  • The org chart in the navbar. Sections named after the teams that built them. Every user has to learn your internal structure to find their task.
  • The fourteen-item flat menu. Everything promoted, so nothing is. Past about seven items a navbar stops being navigation and becomes a list to read.
  • The daily task at depth three. Admin ▸ Settings ▸ Meetings, used every morning. Usually the result of the feature arriving late and being put wherever there was room.
  • Dashboard disease. Everything becomes a dashboard, even though people came to do work, not to look at work.

The relationship to progressive disclosure

These two are the same judgment at two scales. Surface, don't bury decides what is reachable from the top of the app. Progressive disclosure decides what is visible at the top of a screen. Both are about deferring, not deleting, and both have the same failure mode: a lower layer with no visible door.

Internally the layering skill states the screen-level version as a hard budget — five elements at the glance layer, and to promote a sixth you must demote one. That budget is worth borrowing for navigation, because it forces the ranking to be real rather than aspirational.

The test

List the five things people on this product do most. Count the clicks to each from a cold start. If any of them is more than two, either the ranking is wrong or the navigation is.

Related

Wiki guide
UX Principles Guide for Building Web Software
The customer-facing version, with demos of a buried daily workflow and an over-full navbar.
Cookbook recipe
Progressive Disclosure for Dense Detail Pages
The same judgment applied inside one screen instead of across the app.