Progressive Disclosure Defaults And Tucking

Progressive disclosure: defaults and tucking decisions

Progressive disclosure is mostly an editorial discipline. The technical patterns (accordions, tabs, "More" buttons) are easy; the hard work is deciding which content earns primary placement and which gets tucked. This skill is about that decision.

The framework: who, when, how often

For each candidate piece of content or control, ask three questions:

1. Who is it for?

• Everyone (every user, every visit) → primary layer, always visible.
• Most users (the typical case) → primary layer, visible by default.
• Some users (specific roles or contexts) → secondary layer, disclosed by user action.
• Few users (power users, edge cases) → secondary or tertiary layer, disclosed and possibly behind labels like "Advanced."

2. When is it needed?

• Always → primary.
• Per visit, but only sometimes per session → secondary, easy to reach.
• Once during setup, never again → primary during setup, then move to settings.
• Only on error / exception → don't show by default; surface on the relevant condition.

3. How often is it used?

This is the most concrete question — answerable from analytics.

• Used by ≥ 50% of users on most visits → primary.
• Used by 20–50% of users, or by everyone occasionally → primary, possibly with tighter visual treatment.
• Used by 5–20% of users, or by power users routinely → secondary, behind one explicit affordance.
• Used by < 5% of users → secondary or tertiary, possibly worth removing entirely.

These thresholds are rules of thumb; tune to your product. The bigger point: usage data is the strongest signal for tucking decisions, and most teams don't look at it before laying out chrome.

Defaulting disclosure state

When a section can start open or closed, choose deliberately:

Default open

• The section the user is most likely to read or modify.
• The section required to complete the task (if disclosure is in a form).
• The first section in a sequence (so the user has somewhere to land).
• A single-section accordion (if there's only one, it's not really collapsed by purpose).

Default closed

• Sections that supplement the primary task.
• "Advanced" or "Optional" sections.
• Sections so long they'd dwarf the rest of the page if open.
• Sections used by < 20% of users on a given visit.

Remember user state

For settings pages and frequent surfaces, remember which sections each user opened previously and restore on next visit:

// On open, persist
sectionToggle.addEventListener('toggle', () => {
  localStorage.setItem(`section-${sectionId}`, sectionToggle.open ? '1' : '0');
});

// On load, restore
const saved = localStorage.getItem(`section-${sectionId}`);
if (saved !== null) sectionToggle.open = saved === '1';

Power users who always reopen the same section will appreciate it; novices who never expand it pay no cost.

What earns primary placement

The primary layer is finite real estate. Be ruthless. A useful triage:

Always primary

• The page's purpose-defining content. (A user lands on a Reports page; the report is primary.)
• The required actions to complete the typical task. (A checkout flow; "Place order" is primary.)
• Wayfinding chrome that orients the user.

Usually primary

• Frequently-used controls.
• Status indicators that change meaningfully (notification counts, error states).
• Recently-used items (recents accelerate frequent tasks).

Sometimes primary

• Customization options that vary by user role.
• Onboarding hints for new users (but not for veterans).
• Contextual help that depends on user state.

Rarely primary

• Advanced configuration.
• Account management (move to a separate page).
• Marketing, upsells, "what's new."

What earns tucking

Conversely, candidates for the secondary or tertiary layer:

• Optional fields in forms.
• Power-user filters in search/list UIs.
• Customization of layouts, themes, keyboard shortcuts.
• Account / billing / security controls (their own page, not a sidebar accordion).
• Help and documentation links (footer or help menu).
• Legal / compliance links (footer).
• Settings the user changes once and forgets (push to a "Preferences" page).

A worked example: a settings page audit

Imagine the current Settings page exposes 34 fields across 5 sections in a single scroll-y view. A progressive-disclosure pass might restructure as:

Profile (always visible at top)
  Display name
  Email
  Time zone

Notifications (accordion, default closed for users who haven't changed it)
  Email digest
  Mention notifications
  Quiet hours

Workspace (accordion, default closed)
  Workspace name
  Members [link to separate page]
  Default project

Security (separate page; link in nav)
  Password
  2FA
  Sessions
  API tokens

Advanced (accordion, default closed; appears only for users with the appropriate role)
  Webhooks
  Custom CSS
  Feature flags

Danger zone (separate panel at bottom; visually demoted)
  Transfer ownership
  Delete workspace

Profile (3 fields) is primary because every user changes their email or name occasionally. Security goes to its own page because it's high-stakes and benefits from its own focused surface. Advanced is conditional. Danger zone is at the bottom and visually distinct — out of the way of accidental engagement.