skip to content

In a design system, why use a spacing scale built on a base unit such as 8 instead of choosing each space case by case?

level: juniorimportance: must knowfreq 55%

answer

  1. one-off values drift apart
  2. few named choices, one rhythm
  3. every step a multiple of the base
  4. 4 is finer, 8 is bolder
  5. values stored as tokens

basics

~20 s

A spacing scale replaces endless one-off guesses with a few shared steps, so screens share one rhythm and are quicker to design, build and review. A base unit such as 4 or 8 makes every step a simple multiple.

solid answer

~50 s

Without a scale, every designer and engineer picks spaces by eye, and a food-delivery app ends up with 13, 14, 15 and 17 units between a dish name and its price on four different screens. A **spacing scale** limits the choice to a handful of steps built from a **base unit**, commonly an **8-point spacing grid** with a 4-unit half-step: 4, 8, 12, 16, 24, 32, 48, 64. That buys **consistency** (one visual rhythm), **speed** (a small decision instead of a measurement), **shared language** ("stack 16" means the same thing to design and code), easy **review** (an off-scale value stands out) and **central control**, because the steps live as tokens that can be tuned in one place. Choosing 4 or 8 is a convention, not a standard: 8 gives bolder contrast between steps, 4 gives finer control for dense screens.

code

json · 12 lines
json
{
  "space": {
    "$type": "dimension",
    "$description": "Spacing scale: 8-point grid with a 4-unit half-step",
    "xs":  { "$value": { "value": 4,  "unit": "px" } },
    "s":   { "$value": { "value": 8,  "unit": "px" } },
    "m":   { "$value": { "value": 16, "unit": "px" } },
    "l":   { "$value": { "value": 24, "unit": "px" } },
    "xl":  { "$value": { "value": 32, "unit": "px" } },
    "2xl": { "$value": { "value": 48, "unit": "px" } }
  }
}

go deeper

for a junior

Recall what a base unit and a spacing scale are, and name a typical 8-point scale with its 4-unit half-step.

for a middle

Explain what the scale buys: consistency, speed, shared language, reviewability and central control through tokens, and the 4 versus 8 trade-off.

for a senior

Show how you would handle requests for off-scale values, separating genuine missing steps from one-off preferences and optical adjustments.

for a principal

Discuss how the scale's size and base unit shape a multi-product system's flexibility, and when a product family justifies its own step set.

## The problem with one-off spacing Spacing is the most frequent visual decision in any interface: every card, list row, form and button needs space around and between its parts. When each person decides it by eye, the values drift. A **food-delivery app** built this way ends up with a restaurant card that leaves 14 units above its title on the home screen, 15 on the search results and 16 on favourites. None of those is wrong alone, but together they make the product feel slightly unfinished, and every new screen repeats the debate. ## What a spacing scale is A **spacing scale** is a short, ordered list of allowed spacing values that every screen and component draws from. - The **base unit** is the smallest building block, usually **4** or **8**. - Each **step** is a multiple of the base unit. - An **8-point spacing grid** is the common name for a scale whose main steps are multiples of 8, often with a 4-unit half-step for tight spots such as an icon beside its label. - A typical 8-point scale reads: 4, 8, 12, 16, 24, 32, 48, 64, 96. The scale covers the **space between and inside** things. Many systems also size components on the same base unit (control heights of 32, 40 or 48, icons of 16, 20 or 24) so that sizes and spaces add up cleanly. ## Why a base unit of 4 or 8 | Choice | Strength | Cost | |---|---|---| | Base 8 | bold, clearly different steps; fewer choices | tight components sometimes need a half-step | | Base 4 | fine control for dense data screens | more steps to choose from, smaller visible differences | | No base unit | total freedom | drift, debate and inconsistency | Both 4 and 8 are **conventions**, not rules any standard mandates. Their popularity has practical reasons: they divide evenly into many common screen and component sizes, and they halve cleanly into smaller steps. A system could pick another base and still be consistent; what matters is that there is one. ## What the scale buys 1. **Consistency.** Every screen shares one rhythm, so the product reads as one thing even when many teams build it. 2. **Speed.** Choosing between 16 and 24 is faster than measuring and debating 18 versus 19. 3. **Shared language.** "Inset 16, stack 24" means the same in the design file, the spec and the code. 4. **Reviewability.** An off-scale value is visible in review, whether by a person or by an automated check. 5. **Central control.** Because the steps are stored as design tokens, the whole product can be retuned, for example into a more compact mode, by changing the scale rather than every screen. ## Spacing values as tokens Each step is published as a token so that design files and code reference the step, not the raw number. A token change then flows everywhere the step is used. The code example shows a scale written in the Design Tokens Community Group format, where the `dimension` type carries a numeric value and a unit and a group-level `$type` is inherited by every token inside it. ## Introducing a scale to an existing product Most teams adopt a scale after the product already exists, so the first version should be derived from what is there. Measure the spacing values already in use, find the handful that cover most of them, and snap those to the nearest multiples of the chosen base unit. In a food-delivery app this usually reveals that 16 and 24 already dominate, with a long tail of near misses. Publishing the scale together with a mapping from old values to steps lets teams migrate screen by screen instead of in one risky change, and shows everyone that the scale describes how the product already mostly works rather than imposing an arbitrary new rule. ## Where the scale stops A spacing scale is not a law of physics: - **Borders and hairlines** are thinner than the base unit and sit outside the scale. - **Font sizes** do not need to be multiples of the base unit; line heights are what align with it. - **Optical adjustments**, such as nudging a play icon so it looks centred, are legitimate when they are rare and deliberate. The goal is that almost every space is a step, and every exception is a decision someone can explain.

  • Should the base unit be 4 or 8?
    It is a trade-off. Base 8 gives fewer, clearly different steps and suits most consumer screens; base 4 gives finer control for dense data-heavy screens but more options to choose between. Many systems take 8 as the main rhythm and allow 4 as a half-step for tight spots. Either works if it is applied consistently.
  • A designer needs 10 units between two elements; what do you do?
    Pick the nearest step, 8 or 12, and check whether it reads well; it almost always does. If several teams keep asking for the same missing value, that is evidence for adding a step through the system's normal change process, not for a one-off exception on one screen.
  • Does the scale cover component sizes or only the space between things?
    Its main job is space, inside and between elements. Many systems also size controls and icons on the same base unit, such as heights of 32, 40 and 48, so sizes and spaces add up without leftovers and components line up when placed side by side.

It works like a musical key: limiting a song to the notes of one key does not stop anyone writing a melody, but it makes every combination of notes sound as if it belongs together.

saying these in an interview costs you the question

  • An 8-point grid is a mandatory standard every design system must follow.
  • Every value, including borders and font sizes, must be a multiple of 8.
  • Spacing chosen by eye stays consistent as long as designers are careful.
  • More steps always make a better scale because designers get more options.
  • A spacing scale only matters to designers, not to the code.