apply-progressive-disclosure

Apply Progressive Disclosure

Show only the options and information required for the primary task. Reveal additional complexity — advanced settings, optional fields, secondary actions — only when the user requests or needs it.

Why This Is Best Practice

Adopted by: Apple HIG codifies progressive disclosure as a core interaction pattern and applies it throughout macOS and iOS (Advanced settings in dialogs, More options in action sheets); Google Material Design uses progressive disclosure in its expansion panel and bottom sheet patterns; Salesforce, Figma, and Linear each apply progressive disclosure in their settings and configuration UIs to manage feature complexity without overwhelming new users Impact: NNG (2006) reports that progressive disclosure reduces task completion time by 20–40% for first-time users on complex forms and settings screens, compared to fully-exposed layouts; Miller's (1956) working memory research establishes 7±2 (now revised to ~4±1 by Cowan 2001) as the cognitive limit for simultaneously held items — interfaces that surface all options at once routinely exceed this limit; Apple's own HIG cites progressive disclosure as a key contributor to the "learnability" of its platforms Why best: Feature parity with a power user audience should not come at the cost of first-time user experience; a fully-exposed interface is the designer's mental model, not the user's — progressive disclosure presents the user's mental model first and reveals the designer's model on demand; the alternative (exposing everything at once) is equivalent to providing an API reference manual as onboarding documentation

Sources: NNG "Progressive Disclosure" (Nielsen, 2006); Miller "The Magical Number Seven, Plus or Minus Two" (Psychological Review, 1956); Cowan "The magical number 4 in short-term memory" (Behavioral and Brain Sciences, 2001); Apple HIG "Progressive Disclosure" (developer.apple.com)

Steps

1. Identify novice vs. expert tasks

For each feature, list all possible actions and options. Classify each as:

• Primary — needed by most users, most of the time (always visible)
• Secondary — needed by some users or in specific contexts (reveal on demand)
• Advanced — needed rarely, by power users or edge cases (hidden by default, accessible via Advanced settings)

Example — a file export dialog:

Primary (always show):   File format (PDF, PNG, SVG)
                         File name field
                         [Export] button

Secondary (on expand):   Resolution/DPI setting
                         Color profile (sRGB, CMYK)
                         Compression quality

Advanced (rare):         Custom ICC profile
                         Metadata embedding options

2. Choose the disclosure pattern

Pattern	When to use
Expand/collapse	Settings panels, FAQ accordions, detail rows in tables
"Advanced options" toggle	Form dialogs with optional technical settings
Progressive wizard/stepper	Multi-step flows where later steps depend on earlier choices
Tab groups	When secondary content is large enough to warrant a full panel
Contextual reveal	Show additional fields only when a checkbox or toggle is selected

Contextual reveal example:

[ ] Send confirmation email
    ↓ (shows when checked)
    Email address: ___________
    Subject line:  ___________

Showing an email address field before the "send email" checkbox is checked — and hiding it — reduces the visible field count without removing the feature.

3. Apply the 4-item rule for menus and option lists

Limit primary-level menus and option groups to 4–7 items. When a list exceeds 7 items:

• Group related items under a sub-heading or sub-menu
• Move low-frequency items to a secondary level
• Use a "More" or "Other" disclosure control for the tail

A dropdown with 20 options is a classification problem masquerading as a UI problem — classify before displaying.

4. Never hide required fields

Progressive disclosure applies only to optional, contextual, or advanced content. Required fields for completing the primary task must always be visible.

Rules:

• Required form fields: always visible
• Optional form fields: acceptable to hide behind "Add optional details" if they are genuinely rarely used
• Fields that become required based on another selection: reveal immediately when the selecting condition is met (contextual reveal)

5. Make the disclosure control obvious

The control that reveals additional content must be immediately recognizable:

• Label it explicitly: "Advanced options", "More settings", "Show N more"
• Use a chevron or arrow icon to indicate expand/collapse state
• Show the count of hidden items when quantity is meaningful: "3 more options"
• Never hide the disclosure control itself — a toggle that only appears on hover is itself a progressive disclosure violation

6. Preserve state across disclosure

When a user expands an advanced section and sets values, those values must be preserved if the section is collapsed and re-expanded. Collapsing a section should not reset the values within it — the collapse is a display choice, not a clear.

7. Test with first-time users

The test for progressive disclosure is the first-time user completing the primary task:

• Can they complete the primary task without encountering the advanced section?
• If they accidentally reveal the advanced section, can they close it without disrupting their task?
• Do they feel uncertain that a required option is hidden?

If users feel like they're missing something hidden in the advanced section, primary/secondary classification needs to be revisited.

Rules

• Required fields and primary actions are never hidden — progressive disclosure applies to optional and secondary content only
• The disclosure control must always be visible — it must not require hover or a specific sequence of actions to appear
• Expanded state must be preserved — collapsing a section does not reset its values
• Apply the 4–7 item limit before reaching for progressive disclosure — if a menu has 5 items, progressive disclosure adds overhead without benefit; use it only when the full set clearly exceeds working memory limits
• Progressive disclosure is not a substitute for good information architecture — if secondary content is always needed, the primary/secondary classification is wrong

Common Mistakes

• Hiding required fields: putting a required field under "Advanced options" because it feels technical — users will miss it and submit incomplete forms; if it's required, it must be primary
• Unlabeled disclosure controls: a chevron with no label next to a form section — users don't know if expanding it adds required fields or optional ones; label it
• Resetting values on collapse: a user sets "DPI: 300" in Advanced, collapses the section, then re-opens it to find "DPI: 72" — disclosure must be display-only, not a reset mechanism
• Progressive disclosure for 5 items: adding "Advanced options" to a form with 6 total fields, hiding 1 — the overhead of disclosure is not worth hiding a single field; use it when the secondary set is 3+ items that are genuinely rarely needed
• Disclosure as a workaround for poor IA: using advanced options to hide a conceptually primary feature because it "feels advanced" — if users frequently open the section, it belongs in the primary view

When NOT to Use

• When the secondary content is needed by > 50% of users on > 50% of sessions — frequency of use disqualifies it from progressive disclosure; make it primary
• When the primary and secondary content are equally important and of similar complexity — use tabs or a multi-step wizard instead; progressive disclosure implies a clear hierarchy that doesn't exist here
• For mobile navigation menus — progressive disclosure in navigation (hamburger + sub-menus) adds tap depth that slows navigation on mobile; prefer a flat bottom nav or tab bar for primary navigation