spacing

name	spacing
description	Use when a layout feels cramped or arbitrary, when whitespace is being added by guesswork, when grids are forcing awkward sizes, when content groups feel ambiguous (which label belongs to which input), or when every screen size needs different magic numbers. Covers spacing scales, max-widths, grid escape hatches, mobile-first sizing, and the "more around than within" rule.

Layout & Spacing

When to use this skill

• A layout is being assembled and whitespace is being chosen by feel one element at a time.
• The interface feels cramped, even though nothing is wrong individually.
• A 12-column grid is forcing elements to be sizes that don't match their content.
• Form fields, list items, or sections feel ambiguous — it's not clear which label belongs to which input, or where one group ends.
• Different breakpoints need totally different magic-number adjustments.

Core stance

Spacing comes from a system, not from intuition. White space is removed, not added: start too generous, then trim. The relative gap between adjacent values matters more than the absolute number.

Principles

1. Start with too much white space, then remove. Adding padding "until it stops looking actively bad" gives elements only the minimum to survive. Start way over and pull back. What feels excessive on one element is often correct in the context of the full UI.

2. Build a non-linear spacing/sizing scale. "Multiples of 4px" is not a real system — it doesn't help you decide between 120px and 124px. The values need to step at least ~25% apart, with bigger jumps as the scale climbs:

4, 8, 12, 16, 24, 32, 48, 64, 96, 128, 192, 256, 384, 512, 640, 768

At small sizes a few pixels is a noticeable jump (12→16 is +33%). At large sizes a few pixels is invisible (500→520 is +4%). Build from a sensible base (16px is good — browser default).

3. You don't have to fill the whole screen. Modern displays are 1400px+; that doesn't mean every layout needs to be that wide. Use the space the content actually wants. If you're designing a small interface on a big canvas, shrink the canvas: design at ~400px first (mobile-first), then enlarge.

4. Don't make everything full-width just because the nav is. Each region can have its own optimal width independent of its container.

5. Treat grids as a tool, not religion. A 12-column fluid grid is helpful for content blocks but actively bad for things like sidebars, login cards, and components with optimal widths. Give them fixed widths with max-width, only forcing them to shrink when the screen is genuinely narrower.

6. Don't size things relative to each other across breakpoints. A headline that's 2.5× the body size at desktop won't be 2.5× at mobile. Large elements need to shrink faster than small ones; the proportional relationship doesn't hold. Same for padding — at small button sizes, padding should tighten disproportionately, not scale linearly with the font.

7. Stick to px or rem for the type scale. em units compound when nested, which silently kicks you off the scale.

8. More space around a group than within it. This is the single most common "ambiguous spacing" trap. Apply it everywhere:

• Forms: the gap between label and input must be smaller than the gap between form groups, or it's unclear which label belongs to which input.
• Articles: more space above a heading than below it — the heading belongs with the section underneath.
• Bullet lists: if the gap between bullets equals the line-height inside one bullet, multi-line bullets visually merge.
• Horizontal layouts: an icon and its label should be tight together; the gap to the next icon-label group should be loose.

If spacing is what defines a group, the group needs more space outside it than inside.

Quick reference

• Default base spacing scale: 4, 8, 12, 16, 24, 32, 48, 64, 96, 128, 192, 256, 384, 512.
• Adjacent values should differ by ~25% or more.
• Login cards, dialogs, narrow forms: prefer fixed max-width, not column-grid percentages.
• Mobile canvas to design at: ~400px wide.
• "Around > within" — apply to forms, lists, sections, headings, and any horizontal grouping.
• Dense UIs (data dashboards) are fine when chosen deliberately, not as the default.

Attribution

Heuristics distilled from Refactoring UI by Adam Wathan & Steve Schoger (https://refactoringui.com). Independent skill package; not affiliated with or endorsed by the authors.