---
title: "Law of Common Region"
source: "/reference/law-of-common-region"
description: "Elements enclosed by the same visible boundary are usually interpreted as belonging together."
---
# Law of Common Region
Elements enclosed by the same visible boundary are usually interpreted as belonging together.
### Principle
Elements enclosed by the same visible boundary are usually interpreted as belonging together.
### Why it matters
Containers, cards, fieldsets, panels, tinted backgrounds, and bordered regions create strong grouping signals. They help people understand which labels, values, controls, and actions belong to the same conceptual unit. Used excessively, containers produce a wall of boxes and flatten hierarchy because every group receives equal visual weight. Layr should inspect whether boundaries clarify information architecture or merely decorate it.
### Deeper design interpretation
A visible boundary is one of the strongest claims an interface can make about ownership. Cards, tinted surfaces, bordered panels, fieldsets, inset sections, and drawers tell users that the things inside them belong to the same conceptual object or task. This is valuable when the content contains several nearby relationships that whitespace alone cannot communicate reliably.
The cost appears when every piece of content receives a container. Excessive enclosure removes contrast between levels of structure and produces “card soup”: a screen where everything looks equally grouped and users must read headings to reconstruct the hierarchy. Nested regions can also create false ownership. An action placed inside the wrong card may appear to affect only that card even when it changes the whole page.
Layr should therefore evaluate region boundaries as semantic statements. The right question is whether the enclosure matches the scope of the data and actions inside it. A region should help answer “what belongs together?” and “what will this action affect?” without forcing the user to inspect implementation details.
### What the agent should reason about
Compare visual enclosure with DOM/component ownership, data relationships, headings, and action scope. If the data model is unavailable, reduce confidence rather than guessing. Pay particular attention to actions located at the edge of a region, because their visual ownership may be ambiguous.
A missing border is rarely a problem by itself. Strong spacing, headings, background rhythm, or alignment may already provide sufficient grouping. Recommend enclosure only when the existing cues fail to preserve the intended relationship.
### Common failure patterns
- Independent settings are wrapped in one card because they share a column.
- A destructive action sits inside a local panel even though it affects the entire workspace.
- Cards are nested three or four levels deep, making hierarchy difficult to scan.
- A summary visually appears inside one step but actually describes the entire multi-step process.
- Responsive layouts remove a boundary without replacing it with another grouping cue.
### Audit questions
- What semantic relationship does each visible boundary communicate?
- Does the action placement imply the correct scope of effect?
- Are there enough hierarchy levels to explain the page without creating a wall of containers?
- Would the grouping remain understandable if borders were removed or the layout stacked on mobile?
### Example agent finding
> **Medium — The “Delete workspace” action is visually scoped to the Billing card.** Its placement inside the billing region suggests that the action affects subscription data, while the handler removes the entire workspace. Move the action into a dedicated danger region with explicit workspace-level labeling so visual ownership matches actual consequence.
### Agent directive
> Use boundaries to express real semantic groups. Flag regions whose visual enclosure implies a relationship the content does not actually have, or where missing enclosure makes a complex group difficult to parse.
### Apply this when
- Forms with multiple sections.
- Dashboards made of modules or cards.
- Settings pages, inspectors, side panels, checkout summaries, filters, and grouped controls.
- Any interface where proximity alone is insufficient to communicate grouping.
### Observable signals
- A border or background encloses controls with unrelated purposes.
- A label visually sits outside the region it describes.
- Nested cards create several competing container levels.
- Related controls are split across separate containers without a clear reason.
- A complex cluster lacks any boundary or heading and is difficult to distinguish from adjacent content.
### Recommended actions
- Align containers with semantic ownership and interaction scope.
- Prefer spacing and headings before adding another nested card when grouping is already clear.
- Use a stronger boundary only where the grouping must survive scanning, responsive reflow, or dense content.
- Keep actions inside or immediately adjacent to the region whose state they change.
### Do not over-apply
A visible border is not required for every group. Whitespace, alignment, typography, and proximity can establish grouping more quietly. Recommend a container only when it improves comprehension.
### Example
**Weak:** A dashboard places unrelated account controls, billing status, and recent activity inside one bordered card because they fit in the same column.
**Stronger:** Billing controls occupy one clearly labeled region, while recent activity is a separate section with its own heading and interaction scope.
### Evaluation notes
- **Default severity:** Medium when grouping causes wrong interpretation or action; low when it is mostly scan friction.
- **Typical confidence:** High when boundaries and semantic relationships are visible in the DOM or rendered layout.
- **Primary evidence:** DOM grouping, headings, borders/backgrounds, component ownership, action targets.
- **Related rules:** Law of Proximity, Law of Similarity, Law of Uniform Connectedness, Chunking
### References
- [Laws of UX — Law of Common Region](https://lawsofux.com/law-of-common-region/)
## Related rules
- [Law of Proximity](/__layr/pages/reference/law-of-proximity.md)
- [Law of Similarity](/__layr/pages/reference/law-of-similarity.md)
- [Law of Uniform Connectedness](/__layr/pages/reference/law-of-uniform-connectedness.md)
- [Chunking](/__layr/pages/reference/chunking.md)
## Agent guidance
Review criteria, the finding contract a report must use, and worked examples.
Established principle; Layr interpretation and agent guidance. Category: Perception & Visual Hierarchy.
## Retrieve
- Canonical page: https://layr.design/reference/law-of-common-region
- Markdown for agents: https://layr.design/__layr/pages/reference/law-of-common-region.md
- Reference map: https://layr.design/llms.txt
- Route index: https://layr.design/__layr/routes.toon
## Rule object
```yaml
rule:
id: "law-of-common-region"
title: "Law of Common Region"
category: "Perception & Visual Hierarchy"
origin: established
canonical_url: "https://layr.design/reference/law-of-common-region"
principle: "Elements enclosed by the same visible boundary are usually interpreted as belonging together."
directive: "Use boundaries to express real semantic groups. Flag regions whose visual enclosure implies a relationship the content does not actually have, or where missing enclosure makes a complex group difficult to parse."
applies_when:
- "Forms with multiple sections."
- "Dashboards made of modules or cards."
- "Settings pages, inspectors, side panels, checkout summaries, filters, and grouped controls."
- "Any interface where proximity alone is insufficient to communicate grouping."
observable_signals:
- "A border or background encloses controls with unrelated purposes."
- "A label visually sits outside the region it describes."
- "Nested cards create several competing container levels."
- "Related controls are split across separate containers without a clear reason."
- "A complex cluster lacks any boundary or heading and is difficult to distinguish from adjacent content."
audit_questions:
- "What semantic relationship does each visible boundary communicate?"
- "Does the action placement imply the correct scope of effect?"
- "Are there enough hierarchy levels to explain the page without creating a wall of containers?"
- "Would the grouping remain understandable if borders were removed or the layout stacked on mobile?"
recommended_actions:
- "Align containers with semantic ownership and interaction scope."
- "Prefer spacing and headings before adding another nested card when grouping is already clear."
- "Use a stronger boundary only where the grouping must survive scanning, responsive reflow, or dense content."
- "Keep actions inside or immediately adjacent to the region whose state they change."
avoid_when:
- "A visible border is not required for every group. Whitespace, alignment, typography, and proximity can establish grouping more quietly. Recommend a container only when it improves comprehension."
common_failure_patterns:
- "Independent settings are wrapped in one card because they share a column."
- "A destructive action sits inside a local panel even though it affects the entire workspace."
- "Cards are nested three or four levels deep, making hierarchy difficult to scan."
- "A summary visually appears inside one step but actually describes the entire multi-step process."
- "Responsive layouts remove a boundary without replacing it with another grouping cue."
evidence_types:
- "DOM grouping"
- "headings"
- "borders/backgrounds"
- "component ownership"
- "action targets"
default_severity: "Medium when grouping causes wrong interpretation or action; low when it is mostly scan friction."
typical_confidence: "High when boundaries and semantic relationships are visible in the DOM or rendered layout."
related_rules:
- { id: "law-of-proximity", title: "Law of Proximity", url: "https://layr.design/reference/law-of-proximity" }
- { id: "law-of-similarity", title: "Law of Similarity", url: "https://layr.design/reference/law-of-similarity" }
- { id: "law-of-uniform-connectedness", title: "Law of Uniform Connectedness", url: "https://layr.design/reference/law-of-uniform-connectedness" }
- { id: "chunking", title: "Chunking", url: "https://layr.design/reference/chunking" }
```
## What to reason about
Compare visual enclosure with DOM/component ownership, data relationships, headings, and action scope. If the data model is unavailable, reduce confidence rather than guessing. Pay particular attention to actions located at the edge of a region, because their visual ownership may be ambiguous. A missing border is rarely a problem by itself. Strong spacing, headings, background rhythm, or alignment may already provide sufficient grouping. Recommend enclosure only when the existing cues fail to preserve the intended relationship.
## Routing
Route a review here when the evidence is primarily visual: grouping, emphasis, state differentiation, alignment, salience, relationship, or scan hierarchy. Pair these rules with accessibility checks when color, contrast, focus, or motion affects perception.
## Review procedure
For every finding:
1. Identify the exact component, state, route, or interaction.
2. State the observable evidence.
3. Name the principle that applies.
4. Explain the user consequence in the current context.
5. Estimate severity from the consequence, frequency, and reversibility.
6. Recommend the smallest change that addresses the issue while preserving the product's existing design system.
7. Lower confidence when intent, frequency, audience, device, or product constraints must be inferred.
8. Do not produce generic advice such as "improve hierarchy" or "make this clearer" without specifying what is wrong and why.
## Finding contract — emit exactly this shape
```yaml
finding:
rule_id: string
location: string
evidence:
- observable fact
impact: string
severity: low | medium | high | critical
confidence: low | medium | high
recommendation:
change: string
rationale: string
preserve:
- existing design-system behavior
- valid product constraints
```
## Example finding for this rule
Medium — The “Delete workspace” action is visually scoped to the Billing card. Its placement inside the billing region suggests that the action affects subscription data, while the handler removes the entire workspace. Move the action into a dedicated danger region with explicit workspace-level labeling so visual ownership matches actual consequence.
## Code reference
The same principle as markup. Compare the structure, not the class names.
```html
SettingsAccount
Account
Billing statusActive
Next invoice1 Oct · $24
Change passwordLast set 4 Mar
API tokens2 active
Recent activity8 events
Delete workspaceDelete
One boundary · six scopes · workspace deletion inside the account card