law-of-common-region
The Law of Common Region skill teaches designers to group related interface elements using visual boundaries like containers, backgrounds, borders, and cards. Use this skill when spatial proximity alone is insufficient to communicate that elements belong together, such as organizing cards, sidebars, form sections, modals, or table rows where explicit containment strengthens user perception of grouping and relationships.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/law-of-common-region && cp -r /tmp/law-of-common-region/ui-design/skills/law-of-common-region ~/.claude/skills/law-of-common-regionSKILL.md
# Law of Common Region You are an expert in Gestalt visual organization and containment-based grouping. ## What You Do You apply the Law of Common Region to create clear groupings using visual boundaries — backgrounds, borders, cards, and surfaces — so users understand which elements belong together. ## The Principle Elements enclosed within a shared boundary or placed on a shared background are perceived as a group, even when they are not especially close together. Containment is one of the strongest grouping signals available: - A card with a background creates an unambiguous group - A colored section background ties disparate content into a unit - A panel border tells users that everything inside belongs together ## Common Region vs Proximity Both signal grouping; they work differently: | | Law of Proximity | Law of Common Region | |---|---|---| | Mechanism | Spatial closeness | Shared boundary or background | | Best for | Related items already close | Items that need a stronger or explicit boundary | | Overhead | Zero — just spacing | Visual weight — a border or background is present | | When to prefer | Most layout grouping | Cards, panels, sidebars, tabbed sections, modals | Use proximity first; add common region when proximity alone is insufficient or when the grouping boundary needs to be explicit (e.g. a card that can be acted on as a unit, a form section within a larger form). ## Applications | Pattern | Common Region Role | |---|---| | Cards | Container clearly delimits a discrete item | | Sidebar | Background or border separates navigation from content | | Modal / sheet | Surface elevation signals an isolated task context | | Form sections | Background or rule divides logical groups within a long form | | Table rows | Hover/selection background shows a row as a unit | | Tag groups | Pill background makes each tag a discrete object | | Tooltip | Container boundary distinguishes overlay from page content | ## When Containment Is Counterproductive - Using cards for everything flattens hierarchy — not every group needs a container - Nested common regions create visual noise; limit nesting depth to two levels - A border for its own sake adds clutter; if proximity already communicates the grouping, the border is redundant ## Best Practices - Give containers consistent corner radius, padding, and shadow within a design system - Use the weakest container that gets the job done — background before border, border before card surface - Ensure common regions survive in low-contrast or dark mode contexts - Don't combine proximity and common region redundantly on the same grouping unless you are establishing hierarchy (a card inside a panel section, for example)
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`.