{"slug":"surface-dont-bury","meta":{"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."}]},"body":"## The formula\n\n\u003e **Prominence = frequency × importance.**\n\nRank features by how often they are used and how much it matters when they are.\nThe top of that list earns space in the main navigation. Everything else earns\ndepth.\n\nThe formula's real work is the **multiplication**. Frequent and trivial (a\nfilter) does not deserve the same prominence as rare and critical (issue a\nrefund). Neither does rare and trivial, which is most of what accumulates in a\nnavigation bar.\n\n## Burying is a legitimate outcome\n\nThe goal is not to surface everything. One-time setup, admin configuration,\naccount settings and destructive maintenance operations *should* be deep. Depth\nis a design decision that says \"you will not need this often, and you will not\nhit it by accident.\"\n\nThe failure is not depth. The failure is **depth that does not match usage** —\nand the only way to know is to look at what people actually do, not at what the\nfeature list looks like.\n\n## How it goes wrong\n\n- **The org chart in the navbar.** Sections named after the teams that built\n  them. Every user has to learn your internal structure to find their task.\n- **The fourteen-item flat menu.** Everything promoted, so nothing is. Past\n  about seven items a navbar stops being navigation and becomes a list to read.\n- **The daily task at depth three.** Admin ▸ Settings ▸ Meetings, used every\n  morning. Usually the result of the feature arriving late and being put\n  wherever there was room.\n- **Dashboard disease.** Everything becomes a dashboard, even though people came\n  to do work, not to look at work.\n\n## The relationship to progressive disclosure\n\nThese two are the same judgment at two scales. **Surface, don't bury** decides\nwhat is reachable from the top of the *app*. **Progressive disclosure** decides\nwhat is visible at the top of a *screen*. Both are about deferring, not\ndeleting, and both have the same failure mode: a lower layer with no visible\ndoor.\n\nInternally the layering skill states the screen-level version as a hard budget —\nfive elements at the glance layer, and to promote a sixth you must demote one.\nThat budget is worth borrowing for navigation, because it forces the ranking to\nbe real rather than aspirational.\n\n## The test\n\nList the five things people on this product do most. Count the clicks to each\nfrom a cold start. If any of them is more than two, either the ranking is wrong\nor the navigation is.\n"}