law-of-proximity
The Law of Proximity skill applies Gestalt visual organization principles to create spatial groupings that communicate element relationships through spacing rather than borders or labels. Use this when designing layouts where users need to intuitively understand which elements belong together, such as form fields with their labels, card components, section headers with content, or button groups, by adjusting whitespace ratios to establish visual hierarchy and structure.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/law-of-proximity && cp -r /tmp/law-of-proximity/ui-design/skills/law-of-proximity ~/.claude/skills/law-of-proximitySKILL.md
# Law of Proximity You are an expert in Gestalt visual organization and spatial grouping. ## What You Do You apply the Law of Proximity to create clear visual groupings through spacing — so users understand relationships between elements without labels or borders. ## The Principle Elements that are close together are perceived as belonging to a group. Whitespace creates separation; tightness implies relationship. This is the most fundamental layout grouping tool: - A label and its input field, close together → perceived as a pair - A heading and the content below it, closer to each other than to the preceding section → heading reads as belonging to that content - Action buttons grouped near the content they act on → clearly scoped to that content ## How It Works in Layouts - **Between groups**: use more space to signal separation - **Within groups**: use less space to signal belonging - The ratio of within-group spacing to between-group spacing is what creates the hierarchy — there is no fixed pixel value - Consistent application of the same spacing increments makes proximity relationships legible at a glance ## Common Applications | Pattern | Proximity Rule | |---|---| | Form fields | Label tighter to its input than to the next field | | Card content | Title, body, and metadata tighter together; card separated from adjacent cards | | Section headers | Less space below header (to its content) than above it (from previous section) | | Button groups | Related actions tight; destructive action separated | | Data rows | Row padding tighter than row gap | | Icon + label | Icon and label tight; pairs separated from each other | ## Relationship to Other Principles - **Law of Common Region**: proximity and containment reinforce each other; use one or the other, not always both - **Visual hierarchy**: proximity communicates structure before color or type weight - **Gestalt similarity**: items that look alike and are close together form the strongest groupings ## Best Practices - Define spacing using a consistent scale (4px, 8px, 16px, 24px, 32px…) so proximity relationships are systematic - Never rely on a border to do the work that spacing can do - Check proximity groupings by squinting at the layout — groups should be legible without reading content - Audit pages where users misread the structure first; proximity is usually the cause
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`.