In a design-system handoff, why should the spec name the system components and tokens it uses rather than redline raw measurements and color values?
answer
- a frame is not a rule
- literal values drift silently
- modes remap names, not numbers
- component, variant, token by name
- redline only what is off-system
basics
~20 sA raw redline records what one drawn frame measured, so engineers hardcode it and it drifts when a mode or the system changes. Naming the component, variant and token says what to reuse and keeps every theme and future update working.
solid answer
~40 sA redline reading `16` and a color code describes one drawing, not intent. The engineer either hardcodes it — so it stays put when a dark or high-contrast mode remaps everything around it, and misses every later system update — or guesses which token was meant, and a near-miss value becomes a new one-off. A system-aware handoff says *secondary button, compact size* and *gap: the medium spacing token*, and links each design component to the coded component that implements it, so the engineer reuses rather than rebuilds. Redlines still earn their place for layout between components and for pieces the system genuinely lacks — but the handoff should mark those as off-system, so the deviation is a visible decision rather than an accident.
go deeper
Recall that a redline describes one drawn frame, while a component or token name describes intent that survives themes and system updates. Say you would ask, not round, when a value is off the scale.
Explain what breaks with raw values: hardcoding, modes that remap around a literal, near-miss values and rebuilt components. Show how a link from a design component to its coded counterpart turns identification into a lookup.
Show judgement about where redlines are still right — layout between components and genuinely new pieces — and insist off-system pieces are flagged and fed back to the system team rather than hidden in one product.
Weigh how much handoff rigour to ask of designers against the cost of every engineer re-deriving intent, and how linking design components to code scales that trade across many product teams and platforms.
## What a redline is, and what handoff is A **redline** is an annotation drawn over a finished design that states measurements: widths, heights, padding, gaps, type sizes and color values. Before design systems were common it was the main way a designer handed a screen to engineering — every number the engineer needed was written on the picture. **Handoff** is the whole package that travels from design to implementation: the screens, the measurements, the notes about behaviour and accessibility, and the links from design pieces to the code that implements them. A redline answers *how big, how far, what color*. It does not answer *why this value* or *what it should be after the next system release*. ## Why raw values fail inside a design system In a design system most values already have names. A spacing value is a **spacing token**, a color plays a **semantic role** such as surface or subtle text, and a button is a **coded component** with variants and sizes. When a handoff redlines the resolved numbers instead, several things go wrong: - **Hardcoding.** The engineer types the literal. It looks right today and silently stops following the system when the token behind it changes. - **Modes break.** A literal color is correct in exactly one theme. In dark mode, a high-contrast mode or a second brand, the literal stays fixed while everything around it remaps. - **Near-miss values multiply.** A redline reading 15 where the spacing scale has 16 forces a guess. Either answer can be wrong: a new one-off value in code, or a quietly changed design. - **Components get rebuilt.** A redlined button with a height, a corner radius and a fill invites someone to rebuild a button that already exists — losing its states, its focus treatment and its accessibility behaviour. - **Review has nothing to check.** *Matches the redline* is a pixel comparison; *uses the secondary button* is a contract a reviewer can verify. ## What a system-aware handoff says instead | Raw redline | System reference | |---|---| | 36 tall, 12 side padding, 4 corner radius, fill color code | Button, secondary variant, medium size | | Gap of 16 between filter bar and table | The system's medium spacing token, by name | | Text 14, semi-bold, mid-gray | Text style for strong labels; color role for subtle text | | Small green dot beside the word Running | Status indicator component, state: running | The engineer's question changes from *what number?* to *which existing piece?* That question can have the same answer on the web and on native mobile: both platforms can consume the same component and token names, even though each renders them in its own units. ## Linking design components to coded ones Many teams go one step further than naming. The design library's component carries a **link to the coded component** it represents — its name in code, where its documentation lives, and how the variant choices made in the design map to the coded properties. When a designer places that component on a screen, the handoff inherits the link, so the engineer sees *the coded data table, dense rows, sortable name column* rather than a picture of a table. - It turns an identification problem into a lookup. - It exposes gaps: a piece with no link is either genuinely new or a lookalike somebody drew by hand, and both deserve a conversation before code is written. - It keeps the handoff honest across platforms, because each platform's coded component can hang off the same design component. Keeping the two libraries' names and properties in step is its own discipline; the handoff's job is to use the link, not to maintain it. ## Where redlines still earn their place Raw measurements are not banned; they are for what the system does not already name. - **Layout between components** — how a panel's regions stack and what fills the remaining space. Even here, a gap is usually a spacing token. - **Genuinely new pieces** the system has not built yet. Redline them, and mark them **off-system** so the gap is visible and can be proposed back to the system team rather than hidden in one product. - **Illustration and one-off artwork**, where no token applies. ## A worked example: a cloud console's instance list A designer hands off the instance list screen of a cloud provider's admin console: 1. **Filter bar:** the system search field and the system select for the region, each named with its variant. 2. **Table:** the coded data table component, dense density, sortable name column; the status column uses the status indicator component. 3. **Spacing:** the gap between filter bar and table is the medium spacing token. 4. **Quota summary strip:** new to the system — redlined, marked off-system, with a note to propose it as a contribution. The engineer reuses three components and two tokens, builds one new piece knowingly, and nothing on the screen depends on a number that will be wrong after the next theme or system release.
- If the design editor's inspect view already shows exact values, why does the handoff need token and component names at all?Inspect shows the resolved value of what was drawn. If the designer used a token or a linked component, a good inspect view can surface its name; if they typed a raw value or detached the component, it can only show the number. Names carry the role a value plays, which is what survives a theme switch or a system update — the number alone does not.
- What should an engineer do when a redlined value matches no token in the system's scale?Ask rather than round silently. It is either a design slip — the designer meant the nearest token — or a genuine need the scale lacks. The first is fixed in the design; the second becomes a request to the system team or a clearly marked local value with a recorded reason. Guessing either way hides a decision from the people who own the scale.
saying these in an interview costs you the question
- Redlining every measurement is the most precise and therefore safest handoff.
- If the build matches the mockup pixel for pixel, it is correctly implemented.
- Token names are engineering's concern; designers only need to hand over values.
- An off-scale value should be silently rounded to the nearest token.
- A lookalike component can be rebuilt locally from its redlined measurements.