Progressive disclosure | LlamaPress Pattern Catalog
LlamaPress
Pattern Catalog
Principle

Progressive disclosure

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.

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.

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

Related

Cookbook recipe
Progressive Disclosure for Dense Detail Pages
The implementation guide — layer budgets, tabs, collapsed rows.
Wiki guide
UX Principles Guide for Building Web Software
The customer-facing version, with a working slide-out panel demo.
Pattern
Master–Detail Drawer
Disclosure that keeps the overview on screen instead of trading it away.