Show people everything at once and they’ll see nothing.
This is the entire premise behind progressive disclosure, and it’s so obvious it barely feels like a design principle. Sequence information. Reveal complexity when it becomes relevant. Start simple. But “obvious” principles are the ones people ignore most reliably, which is why every enterprise app I’ve ever used hits me with 40 form fields on page one.
What It Looks Like
A settings panel shows basic options. An “Advanced” section exists for the people who need it (and they know who they are). A signup form asks for an email. Just an email. The rest comes later, after you’ve committed the tiny psychological act of typing your address into a box. A dashboard shows three numbers. You want the other forty? Drill down.
The pattern is everywhere once you notice it:
- “Show more” buttons
- Multi-step wizards
- Tooltips on hover
- Layered navigation (overview → category → detail)
Why It Works (When It Works)
Fewer choices per screen means fewer opportunities to bail. Cognitive load is real; people don’t read interfaces, they scan them, and if the scan returns “this is complicated” they leave. Progressive disclosure front-loads the scan with something manageable.
It also flatters the user. “Here’s the simple version” implies they’re smart enough to find the complex version if they want it. Whether that’s true is between them and God.
When It Doesn’t
You’re gambling that you know what “essential” means for your users. Get it wrong and you’ve buried the thing they came for behind two clicks and an expandable section. Every layer you add is friction. Friction you chose on their behalf.
I’ve watched people spend 90 seconds hunting for a setting that was hidden under “Advanced” because a designer decided it wasn’t important enough for the default view. It was a checkbox. The user needed it every single time. The designer had never spoken to the user.
The Honest Version
Progressive disclosure is easy to understand and hard to do well. The “what should be visible first” question can’t be answered at a whiteboard. It requires watching people use the thing, which is expensive and unflattering and reveals that your intuitions about user needs were wrong in ways you’d rather not document.
Most teams skip the research and guess. The guesses are usually informed by what the team finds interesting about their own product, which correlates weakly with what users need.