progressive-disclosure-defaults-and-tucking

Guides decisions on which UI content to surface by default and which to tuck behind disclosure.

8|3|Updated May 3, 2026
One-click install
npx skills add https://github.com/Deibler/universal-design-principles --skill progressive-disclosure-defaults-and-tucking-deibler
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: progressive-disclosure-defaults-and-tucking
Source: https://github.com/Deibler/universal-design-principles/tree/main/plugins/cognition-and-learnability-principles/skills/progressive-disclosure-defaults-and-tucking
Command: npx skills add https://github.com/Deibler/universal-design-principles --skill progressive-disclosure-defaults-and-tucking-deibler

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Designers and developers struggle to decide which controls, fields, and sections deserve primary placement on a screen and which should be hidden behind accordions, tabs, or separate pages, often resulting in cluttered interfaces or buried required functionality. ## Core Features & Use Cases - Triage framework: Classify each element by who needs it, when it is needed, and how often it is used, with concrete usage thresholds (e.g., <5% usage is a tuck candidate). - Default state guidance: Rules for when accordions and sections should start open or closed, including persisting user toggle state via localStorage. - Worked audits: A settings-page restructuring example showing how 34+ fields redistribute across primary, secondary, and tertiary layers. - Use Case: When redesigning a settings page, apply the audit method to inventory every control, tag it with analytics data, group the long tail into coherent disclosed sections, and migrate existing users carefully. ## Quick Start Ask the agent to audit your settings page layout and recommend which fields should stay visible and which should move behind accordions or separate pages.

Frequently Asked Questions about progressive-disclosure-defaults-and-tucking

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide which settings to show by default on a page?▼

Classify each control by who uses it, when it is needed, and how often. Controls used by over 50% of users per visit stay primary; those under 5% move behind disclosure or to a separate page. Usage analytics is the strongest signal for these decisions.

When should an accordion section start open versus closed?▼

Default open for the section users most likely need, required form sections, and the first section in a sequence. Default closed for supplementary, advanced, or rarely used sections. For returning users, persist and restore their previous toggle state.

What usage threshold justifies hiding a UI control?▼

Controls used by fewer than 5% of users per visit are strong tucking candidates, and those under 1% are candidates for removal. Controls in the 5-20% range belong behind one explicit disclosure affordance like an accordion or Advanced section.

Should error states be placed inside collapsed sections?▼

No. Never bury error states inside collapsed accordions. If a form section contains an error, that section must be open or auto-open on submit failure so the user can see and fix the problem.

When is labeling a section Advanced a bad idea?▼

The Advanced label fails when it becomes a dumping ground for unrelated controls or feels condescending for merely unusual settings. Keep it focused on power-user tools, ensure it is findable, and consider alternatives like Optional or More options.