Layout that communicates structure
Layout communicates before a single word is read: position, spacing, and alignment carry hierarchy on their own, and generous space beats decoration. A good layout also survives stress: resize it, translate it, mirror it for RTL, and it should still hold together. Apply these principles when building or reviewing UI code, and express every change in the project's existing styling system (Tailwind, plain CSS, CSS-in-JS); never introduce a second styling approach.
Hit-area sizes and focus behavior are covered by the
skill; visual polish (radius, shadows, animation) by the
skill; line length and text spacing by the
skill.
Quick Reference
| Category | When to Use |
|---|
| Grouping & Alignment | Space vs separators, alignment edges, logical properties, importance ordering |
| Spacing & Adaptivity | Spacing between targets, layout margins, progressive disclosure, full-bleed content, breakpoints, i18n growth |
Core Principles
1. Group with Space, Not Lines
Negative space is the primary grouping tool; background shapes second; separator lines last, only where space alone can't carry the structure. The gap between groups must be at least 2× the gap within a group (
intra-group →
+ inter-group), or the grouping reads as noise.
2. Keep Controls Distinct from Content
Interactive elements must look interactive: a background shape, a border, or a consistent placement zone. Never style a control identically to adjacent static text.
3. Align to Shared Edges
Pick alignment edges and stick to them; every stray edge reads as noise. Indent exactly one step (
) to signal subordination. Use logical properties (
,
), never physical left/right, so RTL mirrors for free.
4. Order by Importance
The most important content sits near the top and the leading edge; reading order flows top-to-bottom, leading-to-trailing. Think in leading/trailing, not left/right.
5. Hint at Hidden Content
Progressive disclosure needs a visible affordance: let the next item peek
past the scroll edge, or show a disclosure control. Content hidden with zero cue may as well not exist.
6. Breathing Room Between Targets
Keep at least
between adjacent bordered or filled controls, and
of clearance around borderless text- and icon-only controls. Hit-area sizes themselves are covered by the
skill.
7. Inset Buttons from the Edges
No edge-to-edge, full-width buttons pressed against the viewport. Keep buttons inside the layout margins (at least
inline margin on mobile) with a visible radius.
8. Content Bleeds, Controls Float
Backgrounds and media extend to the viewport edges; controls and text stay inside the layout margins and safe areas (
). Sticky chrome floats above the content layer, it doesn't dam it.
9. Hold Structure Until It Breaks
Breakpoints come from the content, not device presets. Keep the expanded layout as long as it genuinely fits and collapse late; prefer container queries for component-level adaptation. Test the smallest and largest sizes first.
10. Plan for Growth and Clipping
Translated strings run 30–40% longer: no fixed widths or heights on text containers, and let rows wrap. Never park critical actions where resizing or scrolling clips them; keep primary actions in stable chrome.
Common Mistakes
| Mistake | Fix |
|---|
| Separator line where spacing would do | Remove the line, double the gap between groups |
| / in a localizable layout | / |
| Full-width edge-to-edge button | Inset within layout margins ( minimum on mobile) |
| Carousel/scroller that looks complete | Let the next item peek past the edge |
| Adjacent controls with no gap | minimum between bordered controls, around borderless ones |
| Breakpoints at 768/1024 because they're the defaults | Break where the content actually stops fitting |
| Fixed-width text container sized to English strings | + wrapping; translations run 30–40% longer |
| Primary action at the clip-prone bottom of a pane | Sticky positioning or stable chrome with safe-area padding |
Review Output Format
Present every review in two parts.
Findings
Group findings by principle. Use a markdown table with Severity, Location, Before, After, and Why columns. Include every change made or proposed, not a subset. Never use separate "Before:" / "After:" lines.
- Severity: blocks content or an action at a supported viewport; harms hierarchy, reading order, or adaptability; is isolated alignment or spacing polish.
- Location: cite . If the artifact has no source files, cite the exact screen and component instead.
- Before / After: show the current layout and an actionable replacement.
- Why: name the violated principle and its effect on comprehension or adaptability.
Consolidate a repeated systemic issue into one row and list every affected location. Omit principles with no findings.
Example
Group with space, not lines
| Severity | Location | Before | After | Why |
|---|
| LOW | | on every settings row | Remove borders; use within groups and between groups | Spacing communicates grouping with less visual noise |
| LOW | | between form sections | Replace with on each section heading | Section hierarchy should not depend on repeated rules |
Align to shared edges
| Severity | Location | Before | After | Why |
|---|
| LOW | | Card text at , card icon at | Align both to the same edge | Shared edges create a legible structure |
| MEDIUM | | | margin-inline-start: 16px
| Physical properties break direction-aware layouts |
Verification and Verdict
After the findings:
- Verification: list the exact checks run and their observed results across the relevant viewport widths, reading order, zoom, and RTL state. If a check was not run, state what still needs verification.
- Verdict: if any finding remains, if only or findings remain, and only when no actionable findings remain.
When there are no findings, omit the tables, state "No actionable layout findings", report verification, and end with
.