I redesigned a client’s contact form last month. The old version had eleven visible fields. Name, email, company, role, company size, budget range, project type, timeline, how-did-you-hear, message, and a little checkbox for the newsletter. The form sat at the bottom of the homepage looking like a tax document. The conversion rate, when we measured it, was about 0.6%.
The new version has three visible fields on first paint: name, email, what do you need. After you click into “what do you need” and start typing, two more fields appear (timeline and budget, with friendly defaults). The rest – company size, role, the newsletter checkbox – only show up after you’ve filled the basics, in a sort of “a few more details” reveal. Same eleven fields. Same data captured. Conversion rate after four weeks is 2.1%. I am not exaggerating that number, I checked it twice because I didn’t believe it the first time.
That, in one example, is why progressive disclosure is the UX pattern I keep stealing.
What it actually is
Progressive disclosure means showing only what’s necessary right now, and revealing more as the user signals they want it (or as the situation requires it). The opposite is what I’d call the everything-bagel approach: every option, every field, every menu item visible at once because hiding things is somehow rude.
The everything-bagel feels generous to the designer. It feels overwhelming to the user. There’s a real cognitive load to scanning a screen and figuring out what matters, even if you, the designer, think it’s all clearly laid out. People bounce from cluttered interfaces, they don’t read carefully, and they form a quick gut judgment about whether your thing is going to be a hassle.
Three examples I keep going back to
Linear’s command bar. If you’ve used Linear (the project management tool that took over a chunk of the dev world the past few years), the cmd-K command bar is the cleanest example of progressive disclosure I can point to. You hit cmd-K. A single text input appears. That’s it. Type “new” and now you see a list of relevant actions. Type “new issue” and the action surfaces with a sub-form. The interface unfolds based on what you ask for, instead of confronting you with eight panels of buttons. The whole product follows this principle, but the command bar is the most visible bit.
Stripe’s checkout. Watch what happens when you start typing your card number on a Stripe-powered checkout. The CVV and expiration fields appear after the card number is plausibly entered. The billing address sometimes auto-collapses based on the card type or the merchant config. Apple Pay and Link buttons surface only if your browser supports them. It’s a checkout that grows around your situation rather than presenting you with the full possibility space upfront. I looked into the details when I was building a payments page and got really into the small choices Stripe makes here. Almost nothing is shown before it’s needed.
The classic “Show advanced” toggle. Boring, ancient, still works. Configuration screens that hide the 47 niche options behind “Advanced settings” are doing this. WordPress’s screen options dropdown does this. Apple’s System Settings does it (badly, but the intent is right). The principle: 80% of people need 20% of the controls. Make those obvious. Make the rest available, but quiet.
Forms specifically
Forms are where progressive disclosure pays the most. There’s a fairly well-known piece of UX folklore that every additional form field reduces completion by some percentage – the exact number varies depending on whose deck you’re looking at, but the direction is real. People scan a form, count the fields, and decide whether they have the energy.
Here’s the trick though: people are counting visible fields, not actual fields. A form with three visible fields and an “add details” reveal that ends up gathering eight pieces of data converts better than one with all eight visible from the start. The total work is the same. The perceived work is much less.
Some patterns I use for this:
- Show the absolute minimum to get started. Usually name plus the one piece of information that defines the request (“what are you looking for”).
- Reveal context-dependent fields. If they pick “web project”, show the timeline and budget questions. If they pick “just have a question”, don’t.
- Group secondary stuff under an explicit “a few more details (optional)” expander.
- Don’t ever surprise-add a required field after the user thinks they’re done. That’s the one variant where progressive disclosure feels like a trick rather than a kindness.
The fourth one matters a lot. The whole pattern rests on trust. Users will tolerate (and actually appreciate) a form that gets larger as they engage with it, but only if they don’t feel ambushed. Make the optional stuff genuinely optional. Don’t bait-and-switch.
Where I’ve seen it done badly
Progressive disclosure is not the same as hiding important things. I’ve used a few SaaS dashboards where the most useful action was buried three levels deep behind “More” menus, and the homepage of the dashboard was full of charts I didn’t ask for. That’s not progressive disclosure, that’s just bad information architecture wearing a costume.
The test I run, mentally: if a new user lands on this screen, can they do the one most likely thing without exploring? If yes, you can hide the rest. If no, the most likely thing has to be visible. Progressive disclosure isn’t license to hide your primary action.
Tooltips and contextual hints are part of this same family of ideas, by the way – revealing information when the user is in a position to use it, rather than dumping it on them upfront. Adding hints to forms is basically the same impulse: don’t pre-explain everything, explain when they’re at the field that needs explaining.
The cargo-cult bit
There’s a vocal segment of UX opinion that argues for “transparency” – show everything, let users decide. I get the appeal, especially as a reaction to dark patterns and forced funnels. But “show everything” usually means “the designer didn’t make decisions about what’s primary”. Designing is choosing what to hide, in a way. A landing page that lists 24 features is not respecting your time, it’s offloading the work of figuring out what matters onto you. The designer should have done that work.
Same with admin panels. Same with onboarding flows. Same with that tax-document contact form I started this post with. The eleven fields all genuinely needed to be captured. The mistake was capturing them all at the same time.
I’m going to keep stealing this pattern as long as it keeps working. Which seems to be indefinitely.