Foundations: spacing systems that survive product work

Spacing systems usually begin with a scale and end with arguments. The scale says 4, 8, 12, 16, 24, 32. The product says the sidebar needs to breathe, the table needs density, and the mobile card cannot afford that much vertical padding.

The answer is not more numbers. The answer is a clearer model for rhythm and density.

Start with rhythm

Spacing is how an interface tells the eye what belongs together. Small gaps create groups. Larger gaps create separation. Repeated gaps create rhythm.

I like to define spacing by job:

• Inline gap: space between small peers.
• Stack gap: space between related vertical elements.
• Section gap: space between distinct ideas.
• Page gap: space between major layout regions.
• Inset: padding inside a surface.

Those names are easier to use than a raw scale because they describe intent. The values can still point to primitive tokens, but designers and engineers should be choosing the job first.

Density is a product mode

Some products need roomy marketing pages and dense operational tools. One spacing system can support both if density is treated as a mode, not as a series of one-off overrides.

A table row, settings page, dashboard card, and onboarding step should not all use the same vertical rhythm. The question is how much comparison, repetition, and reading the screen requires.

Dense does not mean cramped. It means the space is allocated to the work. In an admin table, extra whitespace can slow scanning. In a checkout confirmation, extra whitespace can improve confidence. The system should make both decisions available.

Component padding is not page layout

A common mistake is using component padding to solve page composition. Cards get more padding because the page feels empty. Buttons get extra margin because the form feels crowded. Soon the component library carries layout decisions it should not own.

Keep component inset tokens local to the component's comfort and touch targets. Use layout primitives for page rhythm. If a card needs to sit farther from a sidebar, the grid should own that space, not the card.

Exceptions need names

Every spacing system has exceptions. The mature version names them.

Maybe compact density is allowed in tables, menus, and command palettes. Maybe editorial pages use a wider section gap. Maybe mobile checkout has a sticky action area with its own safe-area padding. Those are product realities, not failures of the system.

The problem is unnamed exceptions. When exceptions are unnamed, they spread as screenshots and copied CSS.

A practical starter

For most product teams, I would start with:

• Primitive scale: 0, 2, 4, 8, 12, 16, 20, 24, 32, 40, 56, 72.
• Semantic gaps: gap-inline, gap-stack, gap-section, gap-page.
• Insets: inset-control, inset-card, inset-panel, inset-page.
• Density modes: comfortable, compact.

That is enough structure to prevent chaos without requiring a token for every possible gap.

The review exercise

Take one shipped screen and annotate every spacing decision. Ask which gaps are grouping, which are separating, which are padding, and which are accidental. If nobody can explain a gap, either remove it or name the reason it exists.

Spacing systems work when they help teams make those calls under deadline pressure. They fail when they become a prettier way to memorize numbers.