Progressive disclosure

Problem Context

• The interface supports both common users who need a clear default path and expert users who need optional control.
• Advanced controls are useful but not required for most successful completions.
• The product can keep hidden state, changed advanced values, summaries, validation, and reset behavior synchronized.
• Users need to understand when a hidden option affects output, cost, permissions, safety, or final commitment.

Selection Rules

• Choose progressive disclosure when the task benefits from a simple default path plus optional advanced controls or details revealed on demand.
• Use disclosure details when there is only one short optional explanation beside a local field or paragraph.
• Use accordion when several peer sections should each be independently opened, scanned, summarized, or expanded together.
• Use conditional reveal fields when a selected form answer owns a short follow-up field that becomes part of submitted data.
• Use wizard when the task has sequenced dependencies, draft preservation, tests, review, cancel, and finish behavior.
• Use details panel, preview panel, or full page when hidden content is selected-object inspection, rendered content preview, or deep reading.
• Do not hide primary completion actions, required answers, severe warnings, or legal consequences behind an advanced reveal.
• Do not hide advanced changes once made; summarize them near the primary action and provide reset or edit access.
• Avoid stacking several reveal levels unless each level has a specific purpose, predictable label, and escape path.
• Prefer defaults, presets, or simpler options over hidden expert settings when most users cannot safely judge the advanced controls.

Required States

• Simple default state with essential controls, visible primary action, and recommended defaults.
• Advanced closed state with a specific trigger that names what is hidden and whether any hidden values differ from defaults.
• Advanced open state with grouped secondary controls, context copy, and reset or restore recommended settings.
• Changed advanced state with visible summary near the primary action.
• Hidden validation blocker state that opens or points to the responsible revealed control before submission fails.
• Troubleshooting or diagnostics revealed state after a problem occurs.
• Collapsed-after-change state where the changed summary remains visible.
• Reset advanced state that returns hidden controls to recommended defaults without clearing essential answers.
• Narrow-screen state that keeps the default path and reveal trigger reachable without burying the primary action.

Interaction Contract

• The default path remains usable without opening advanced or secondary sections.
• Reveal triggers use specific labels such as Advanced retention settings or Troubleshooting details, not vague More labels.
• Opening a section reveals controls in place or in a clear secondary route without moving users away from the owning task context.
• Closing a changed advanced section keeps a visible summary of hidden changes and an edit path.
• Submission or commit validation opens, links to, or clearly names any hidden control that blocks progress.
• Reset advanced returns only secondary controls to recommended defaults unless the user explicitly resets the whole task.
• Revealed controls use ordinary form, menu, table, or disclosure semantics rather than a custom invisible interaction model.

Implementation Checklist

• Classify each control as essential, secondary, expert, diagnostic, dangerous, or required before deciding what can be hidden.
• Design recommended defaults so the simple path is genuinely complete for common users.
• Write reveal labels that name the hidden control group and its consequence.
• Track whether hidden values differ from defaults and expose that state near the primary action.
• Open or link to hidden fields when validation, errors, search results, or deep links target them.
• Provide reset, restore recommended, or clear advanced controls without clearing the main task.
• Test novice completion, expert reveal, collapse-after-change, validation on hidden controls, reset behavior, keyboard access, screen-reader announcements, and small viewport layout.
• Measure whether hiding a control increases support, search, abandonment, or wrong submissions before leaving it hidden.

Common Generated-UI Mistakes

• Hiding required fields or primary actions to make a page appear shorter.
• Using vague More or Advanced labels that do not tell users what kind of control is hidden.
• Hiding changed advanced settings after collapse with no summary near the final action.
• Treating progressive disclosure as a substitute for information architecture, section headings, or a wizard.
• Stacking several nested reveals until users cannot predict where an option lives.
• Hiding warnings, consent, destructive scope, or cost changes users must understand before committing.
• Creating a reveal control that looks like a link, menu, tab, or drawer but does not follow that pattern's behavior.

Critique Questions

• Which controls are essential for a common successful completion?
• What advanced, rare, expert, diagnostic, or risky controls can safely wait for user intent?
• Can users tell from the trigger what will appear and what it affects?
• What hidden values are changed, and where are those changes summarized before commit?
• What happens when validation, search, or an error targets a hidden control?
• Would this be clearer as one disclosure detail, an accordion, conditional reveal field, wizard, or separate page?