---
title: Surface, don't bury
slug: surface-dont-bury
kind: principle
summary: 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.
problem: 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.
principles: [surface-dont-bury]
status: stable
visibility: public
related:
  - title: UX Principles Guide for Building Web Software
    url: /wiki/ux-principles-for-web-software
    summary: The customer-facing version, with demos of a buried daily workflow and an over-full navbar.
  - title: Progressive Disclosure for Dense Detail Pages
    url: /cookbook/progressive-disclosure-detail-page
    summary: The same judgment applied inside one screen instead of across the app.
---

## 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.