In short
An effective spacing scale is small (typically 6-8 values), built on a consistent base unit (commonly 4px), and named or numbered simply enough that picking the right value takes no real thought — the goal is removing spacing decisions, not offering more of them.
Why spacing scales get ignored
A spacing scale with too many values, or values that don't map cleanly to a mental model, gets ignored in practice — when it takes real thought to pick between 14px and 16px in the scale, designers and engineers alike default back to whatever pixel value feels right for that specific moment, and consistency erodes immediately.
The base-unit approach
Build the scale from a consistent base unit — 4px is common and divides evenly into most common values. Values become simple multiples: 4, 8, 12, 16, 24, 32, 48, 64. This produces a scale where every value is meaningfully different from its neighbors (no near-duplicate options to agonize over) and where the underlying logic is easy to hold in your head.
Keeping it small
Six to eight values covers the vast majority of real spacing needs in a typical product. A scale with fifteen or twenty options reintroduces the original problem — too much choice, not enough clarity about which one is "correct" for a given situation. If a genuinely new spacing need arises that the scale doesn't cover, that's a signal to reconsider the scale, not to add options ad hoc.
Naming versus numbering
Some teams name spacing tokens semantically (space-xs, space-sm, space-md) rather than by raw value — this can help communicate intent ("use sm for related items, md for section gaps") but requires actually documenting what each semantic step is for, or it just becomes an extra layer of indirection with the same ambiguity as raw values. Raw, numbered scales (space-1 through space-8, mapped predictably to pixel values) are simpler and equally effective for many teams.
Applying it consistently in code
Implement the scale as CSS variables or design tokens rather than leaving it as documentation designers reference manually — when the scale exists as actual variables in the codebase, using an arbitrary value requires deliberately opting out, rather than requiring deliberate effort to opt in.
Handling genuine exceptions
Some layouts have real, deliberate reasons for an off-scale value — a specific optical alignment need, a component matching an external constraint. Allow for these as explicit exceptions rather than pretending the scale must cover every case, but keep them rare and documented, so they don't quietly become the norm.
The test for whether it's working
A spacing scale is working when new team members reach for it by default without being told to, because using it is genuinely easier than not using it. If people keep reaching for one-off pixel values instead, that's a sign the scale is either too large, too poorly named, or not actually wired into the tools people use day to day.
More from our insights: How to Build a Color System With Design Tokens.
Primary source: the W3C Design Tokens Community Group documents the specifics referenced above.
Common questions
What base unit should a spacing scale use?
4px is a common, practical default that divides evenly into most typical spacing needs, though 8px is also widely used — consistency in applying whichever base you choose matters more than the specific choice.
How many values should a spacing scale have?
Six to eight is a reasonable range for most products — enough to cover real needs without reintroducing decision paralysis from too many near-duplicate options.
Should spacing tokens be named semantically or numbered?
Either works if applied consistently — semantic names communicate intent but need documentation to avoid ambiguity, while numbered scales are simpler and equally effective if the numbering maps predictably to values.