#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