---
title: Progressive disclosure
slug: progressive-disclosure
kind: principle
summary: Show the essential few things up front and reveal the rest when it becomes relevant. You are deferring detail, not deleting it — and every deferred layer needs a visible door.
problem: >-
  A screen gets built from the data outward — the model has twenty fields, so
  twenty fields go on the page, each with equal weight. Nothing on it is wrong
  and the page is still unusable, because with no hierarchy the eye has no entry
  point, so you must read everything to find anything.
principles: [progressive-disclosure]
status: stable
visibility: public
related:
  - title: Progressive Disclosure for Dense Detail Pages
    url: /cookbook/progressive-disclosure-detail-page
    summary: The implementation guide — layer budgets, tabs, collapsed rows.
  - title: UX Principles Guide for Building Web Software
    url: /wiki/ux-principles-for-web-software
    summary: The customer-facing version, with a working slide-out panel demo.
  - title: Master–Detail Drawer
    url: /patterns/master-detail-drawer
    summary: Disclosure that keeps the overview on screen instead of trading it away.
---

## Design from the job inward

The failure this principle prevents is **designing from the data outward** — you
have the fields, so you ask where to put them. The result has no hierarchy, and
extraneous load falls on every person who uses the screen afterwards.

The alternative starts with one sentence: *a [who] doing [what, when] needs to
decide [one thing]*. Then one question the screen must answer without scrolling,
reading prose, or clicking. Everything that does not answer that question is a
lower layer **by default**. Most of the work is demoting things.

## Four layers, and a budget that does the work

| Layer | Cost to the user | What belongs there |
|---|---|---|
| **Glance** | free | The answer to the one question |
| **Scan** | reading | Supporting context, in place |
| **Demand** | one click | Full bodies, history, internals |
| **Elsewhere** | navigation | Anything that already has its own page |

The glance layer holds about **five elements**, and that cap is the mechanism.
To promote a sixth, you must demote one. Without a fixed budget, every
stakeholder's favourite field ends up at the top and the page is a data dump
again — this time with a design review attached.

## Demote, never hide

Progressive disclosure is not hiding. The distinction is mechanical: **every
lower layer needs a visible door.** A chevron, a count, a "12 earlier messages"
row, a tab. Hidden-with-no-affordance is the classic mistake, and it produces
software where the useful part is folklore.

A hover-only control is a door only for things a person already knows exist. It
may reveal *elaboration* of something visible; it must never be the only carrier
of a fact.

## Applications worth naming

- **Kill the sideways scroll.** A table you scroll horizontally has hidden half
  its data with no door at all. Cut columns to the ones people scan and put the
  rest in the record — see [dense operational table](/patterns/dense-operational-table).
- **Overview plus detail on demand.** A drawer or expandable row gives the full
  record without a page jump, and keeps the overview — the strongest form,
  because it defers detail without trading away context.
- **Reveal on relevance.** A copy button does not need to sit on screen at all
  times; show it when someone hovers the thing they would copy — and then tell
  them it worked.

## The tests

- **Squint.** Blur your eyes or shrink the browser to 25%. Uniform grey mush
  means no hierarchy. Confetti means too many colours.
- **Five seconds.** Show someone the screen for five seconds, hide it, ask what
  it is for and what needs doing. If they cannot say, the glance layer is wrong.
- **Subtraction.** Name what you removed or demoted this round. If the list is
  empty, you did not design — you accumulated.