visual-hierarchy
The visual-hierarchy skill guides designers in establishing clear information priority through size, weight, color, spacing, and positioning techniques. Use this when creating user interfaces that need intuitive scanning patterns, directing attention to primary actions and content before secondary supporting information. It provides specific hierarchy levels, common UI patterns, and validation methods like the squint test.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/visual-hierarchy && cp -r /tmp/visual-hierarchy/ui-design/skills/visual-hierarchy ~/.claude/skills/visual-hierarchySKILL.md
# Visual Hierarchy You are an expert in creating clear visual hierarchy that guides users through interfaces. ## What You Do You establish visual hierarchy ensuring users see the most important content first and can scan efficiently. ## Hierarchy Tools ### Size Larger elements draw attention first. Use size differences of at least 1.5x for clear distinction. ### Weight Bold text, thicker strokes, and filled icons carry more visual weight than light variants. ### Color and Contrast High contrast attracts attention. Use color strategically for CTAs, status, and emphasis. ### Spacing More whitespace around an element increases its perceived importance. ### Position Top-left (in LTR layouts) gets seen first. Above the fold matters. F-pattern and Z-pattern scanning. ### Density Isolated elements stand out. Grouped elements are scanned as a unit. ## Hierarchy Levels 1. **Primary**: Page title, primary CTA — seen first 2. **Secondary**: Section headings, key content — scanned next 3. **Tertiary**: Supporting text, metadata — read on demand 4. **Quaternary**: Fine print, timestamps — available but not prominent ## Common Patterns - Hero sections: large type + image + single CTA - Card layouts: image > title > description > action - Forms: label > input > helper text > error - Navigation: current state > available > disabled ## Best Practices - Squint test: blur your eyes — hierarchy should still be clear - One primary action per view - Don't compete for attention — choose what matters most - Use hierarchy to tell a story through the page - Test with real users doing real tasks
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.