Design tokens are the bridge artefact between brand and product engineering — the structured layer that turns a brand decision into a value the codebase can read. Brand teams that have not yet learned to specify them are quietly handing that authority to whoever in product happens to set up the system. The result is brand expression governed by engineering convenience, not brand intent.

What design tokens actually are

A design token is a named value that represents a single design decision: color.brand.primary, type.heading.lg.size, radius.button.default, spacing.section.outer. The token is the canonical reference. The value behind it can change; everything that consumes the token updates without rework. That decoupling is the entire point. Tokens are organised in tiers. The first tier — sometimes called primitive or core — holds the raw values: a palette of hex codes, a scale of font sizes, a set of spacing units. The second tier — semantic or alias — assigns those primitives to roles: background.surface.elevated uses color.neutral.50; text.body.primary uses color.neutral.900. The third tier — component — pins specific tokens to specific components: button.primary.bg resolves to background.action.brand resolves to color.brand.primary resolves to a hex code. The reason this matters to a brand lead is not the architectural diagram. It is that the brand decision lives at the primitive layer. If a brand team specifies the palette, the type system, and the editorial tone, those decisions propagate cleanly through the semantic and component layers without being re-litigated. If they do not, the same decisions are made by whoever is closest to the keyboard, in whatever order the next ticket happens to require.

Why this is brand territory, not engineering territory

The case for brand teams treating tokens as their concern is straightforward: tokens are how the brand actually appears in the product. A brand book that defines a brand colour and a product that hardcodes a slightly different hex are two different brands operating under one name. Engineering teams will produce something — they have to — but unless brand specifies the primitives, brand inherits whatever values were chosen for technical reasons. This is not a complaint about engineering. Engineers building a new component need a colour to render it; if the brand has not provided one, they will pick one. The fix is upstream: brand provides the primitives, structured as tokens, before product needs them. The shift required is conceptual. A brand book that describes colour as "PMS 2945, RGB 0/74/171, hex #004AAB" is providing values, not tokens. A brand book that describes colour as "Brand Primary — used for primary action surfaces, branded highlights, and key calls to action; value #004AAB; available as color.brand.primary in the token set" is providing both. The second version travels into the codebase intact; the first does not.

What brand leads need to specify

The handover from brand to engineering, when it goes well, includes a set of artefacts at the primitive and semantic tiers. Engineering owns the component tier — they should — but the upstream layers belong to brand:

• Colour primitives — the full palette in named form, including neutrals, semantic colours (success, warning, error, info), and any contextual variations. Each named colour has a value and a stated purpose. The set should be small enough to memorise; if there are 47 named greys, the brand has not yet made a decision.
• Type primitives — the typeface families, the size scale, the weight set, the line-height pairings. The brand book specifies the editorial scale; the token set encodes the application scale. Both are needed.
• Spacing scale — the rhythm unit of the brand: 4-pixel grid, 8-pixel grid, the multiplier set. This is brand territory because spacing is part of how the brand feels — generous or compact, formal or relaxed.
• Radius and elevation — the brand's posture toward sharpness and depth. A brand that uses 2-pixel radii reads differently from one that uses 16. Specify the set.
• Motion primitives — durations and easing curves the product uses for transitions. Brand has a tone in motion as well as in static; if engineering picks the curves, the tone is engineering's.
• Semantic mappings — the named roles that connect primitives to context: action colours, surface colours, text hierarchy. This is the layer where brand intent becomes something the design system can implement.

Component-level tokens — the button.primary.bg layer — are engineering's to set, in collaboration with product design. Brand's authority ends at the semantic layer. Trying to legislate component tokens from the brand side is the most common mistake in handover; it makes the brand book read as design-system documentation and irritates engineering without improving consistency.

Three patterns recur in failed handovers

Brand specifies values, not tokens. The brand book lists hex codes and font sizes but never names them or describes their semantic role. Engineering imports the values into the codebase as primitives. Six months later, when the brand decides primary should warm slightly, every component that uses primary has to be hunted down because the link between brand intent and code value was never structured. Engineering invents the semantic layer. Without brand input, engineering creates names that reflect implementation rather than brand decision: color.blue.500 rather than color.brand.primary. The naming becomes load-bearing in unexpected ways. When marketing produces a campaign featuring an accent colour the brand has long called "midnight", engineering has it filed as color.indigo.700, and the alignment conversation is now also a renaming conversation. The brand book and the design system tokens drift. The brand book ships with one set of values. The token set ships with another, slightly different. Each was authoritative within its own remit. Neither was reconciled. Six months later the visual identity in the product is meaningfully different from the visual identity in the brand book, and nobody is sure which version is correct.

What a clean handover looks like

A clean handover is not a single document. It is three:

• A token specification — the primitive and semantic layers, named and described, with values, in a structured format the engineering team can import directly. JSON or a similar machine-readable file is the modern default; a Figma variable set is the equivalent for design tooling.
• A short rationale document — for each token name, one or two sentences explaining the brand decision behind it. This is the artefact that survives team turnover; values can be regenerated from a tool, but rationale lives in writing.
• A working session with the engineering and product design leads — to walk through the set, agree the boundary at the semantic layer, and resolve any naming mismatches before the tokens land in the codebase.

The third is non-negotiable. Tokens that arrive over the wall will be re-interpreted in transit. A 90-minute conversation prevents the most expensive of those misreadings.

What This Looks Like in Practice

When we worked with BGR, the brand handover included not just the brand book but a structured token specification — primitives, semantic mappings, and a rationale layer. The product team's design system consumed the tokens directly; there was no translation step where a designer manually picked hex codes off a brand PDF and typed them into a Figma library. When the brand evolved a year later — a small refinement to two semantic colours — the change propagated through the product without a remediation project, because the primitives were already structured and named. That is the value of doing token specification at the brand layer rather than discovering it has to happen during the next refresh.

Closing

Design tokens are not a piece of engineering arcana the brand team gets to ignore. They are the contract between a brand decision and how that decision shows up in the product. The brand teams that learn to specify them keep authority over how the brand looks in software. The brand teams that do not, hand that authority to engineering — politely, accidentally, and permanently. If you are about to hand off a brand programme to a product engineering team and you are not sure whether the token layer is structured the way it needs to be, we are happy to walk through what should be in the spec.