Skip to main content
ClaudeWave
ES, Spanish
Skill3k estrellas del repoactualizado 1mo ago

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.

Instalar en Claude Code
Copiar
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-region
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.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)
a-b-test-designSkill

Design an A/B experiment — hypothesis, variants, primary metric, and sample size. Use when a change can be measured quantitatively at scale. For observing behaviour qualitatively, use `test-scenario`.

accessibility-auditSkill

Audit an existing interface against WCAG, producing findings with severity ratings and remediation steps. Use when you have a design or build to assess now. Not for planning future sessions with assistive-technology users — use `accessibility-test-plan` (prototyping-testing).

accessibility-test-planSkill

Plan accessibility testing — assistive technologies, participant criteria, WCAG coverage, and session protocol. Use when scheduling testing with real AT users. Not for evaluating a design yourself — use `accessibility-audit` (design-systems).

aesthetic-usabilitySkill

Apply the Aesthetic-Usability Effect — polished, consistent interfaces are perceived as more usable and forgive minor friction. Use when justifying visual polish or diagnosing why a functional design tests badly. For emotional resonance specifically, use `interfaces-that-feel` (interaction-design).

affinity-diagramSkill

Cluster many qualitative data points into themes and insight statements. Use when synthesising across multiple sessions or sources. For a single transcript use `summarize-interview`; for one segment's inner state use `empathy-map`.

animation-principlesSkill

Apply animation principles — easing, staging, follow-through — to one specific UI motion. Use when tuning how an animation feels. For product-wide duration and easing tokens use `motion-system` (design-systems); for a full interaction spec use `micro-interaction-spec`.

business-designSkill

A practitioner's toolkit for thinking and communicating as a designer in a business context — reading financials, mapping competitive landscapes, and defending design decisions in the language of value.

card-sort-analysisSkill

Analyse open or closed card sort results into a proposed grouping and label set. Use after running a sort study. For turning that evidence into a full structure, use `information-architecture` (ux-strategy).