by Format-3

Share article

{
"@graph": [
{
"@type": "Article",
"image": {
"url": "https://csuxjmfbwmkxiegfpljm.supabase.co/storage/v1/object/public/blog-images/organization-13731/1788207063238_Designer-reviewing-a-design-token-workflow.jpeg",
"@type": "ImageObject",
"caption": "Designer reviewing a design token workflow"
},
"author": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"headline": "Ship Rebrands in an Afternoon With Design Tokens for Product Teams",
"publisher": {
"url": "https://format-3.co",
"name": "Format-3",
"@type": "Organization"
},
"inLanguage": "en-GB",
"description": "Design tokens turn palettes into product infrastructure. A practitioner guide pairing DTCG and USWDS with CI/CD workflows to speed rebrands.",
"dateModified": "2026-08-31T20:12:10.067Z",
"datePublished": "2026-08-31T20:12:10.067Z"
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"item": "https://format-3.co",
"name": "Format-3",
"@type": "ListItem",
"position": 1
},
{
"item": "https://format-3.co/design-tokens",
"name": "Ship Rebrands in an Afternoon With Design Tokens for Product Teams",
"@type": "ListItem",
"position": 2
}
]
}
],
"@context": "https://schema.org"
}

Ship Rebrands in an Afternoon With Design Tokens for Product Teams

Design tokens are named, reusable values, colour, spacing, type, motion, stored once and referenced everywhere. That single detail is why a rebrand that once took weeks of hand-edited CSS can now ship in an afternoon. The real win isn’t the token itself; it’s the fact that design and code finally read from the same source of truth, propagating changes across web, iOS and Android without anyone touching a component file.

TL;DR:

Table of Contents

• What are design tokens, exactly?
• Primitives, semantic tokens and component tokens
• Why bother with tokens at all?
• Getting the naming right
• The toolchain: Figma, plugins and Style Dictionary
• Shipping tokens without breaking production
• Colour, spacing and type in practice
• Keeping tokens alive: governance that actually works
• Format-3’s perspective: tokens as infrastructure, not decoration
• How Format-3 builds token systems that survive contact with production
• Sources

What are design tokens, exactly?

A design token is a name→value pair. color.brand.primary might resolve to #5B21B6 today and something else entirely after a rebrand, without a single component knowing or caring. The USWDS defines tokens as the discrete palettes of colour, spacing and typography values that underpin a design system, and that framing matters: tokens aren’t decoration, they’re the vocabulary designers and engineers finally share.

They differ from a Figma style or a raw CSS variable in one crucial way: a style lives in the design tool, a CSS variable lives in the codebase, but a token is the abstraction that connects both. Change the token once, and the style updates in Figma while the variable updates in production.

• A colour style says “this text is purple.” A token says “this text uses text.emphasis, which happens to be purple right now.”
• That indirection is what makes theming and rebrands cheap instead of catastrophic.

Primitives, semantic tokens and component tokens

Most token systems fail because teams skip the hierarchy and tokenise everything at the component level from day one. Martin Fowler’s architecture proposes three layers instead:

1. Primitive tokens hold raw values: purple.600 = #5B21B6. No meaning, just palette.
2. Semantic (alias) tokens give primitives a job: color.action.primary = purple.600.
3. Component tokens apply semantics to a specific UI part: button.background = color.action.primary.

The reference chain should always run component → semantic → primitive, never the reverse. Introduce component tokens only when a component genuinely needs to diverge from the semantic default, not as a default habit.

Pro Tip: Start with just two layers, primitive and semantic, on most projects. Component tokens are a scaling tool, not a starting point; adding them too early is how teams end up maintaining three token systems instead of one.

Why bother with tokens at all?

Tokens earn their keep the moment a brand touches more than one platform or theme; see how brand kits map to reusable style tokens in content tooling contexts. A dark mode toggle, a rebrand, a new client white-label, all become a single JSON change instead of a grep-and-replace nightmare across three codebases.

• Cross-platform parity: one primitive change reaches web, iOS and Android simultaneously.
• Faster rebrands and dark-mode rollouts, since the semantic layer absorbs the change.
• Fewer design-to-dev handover regressions, because there’s no “is this the right shade of grey?” debate.
• USWDS deliberately limits its measure tokens to seven values, proving that constraint, not abundance, is the point.

None of this pays off for a marketing microsite with one page and no roadmap. Tokens are an investment in a system’s future, and a system with no future doesn’t need infrastructure.

Getting the naming right

A token nobody can predict the name of is a token nobody adopts. The pattern that scales is category.role.variant, for example color.action.primary or space.component.tight. Category tells you the domain, role tells you the job, variant tells you the state.

• Name by role, never by appearance: text.critical, not text.red, because red might change to orange for accessibility reasons and the name shouldn’t lie.
• Components should only ever consume semantic or component tokens, never primitives directly. That discipline is what lets you swap a whole palette without touching a single component.
• Handle modes (light, dark, high contrast) as alternate value sets on the same semantic token, not as separate token families.
• Keep the taxonomy shallow. Three levels of nesting is a naming convention; six is a maze nobody will maintain.

The toolchain: Figma, plugins and Style Dictionary

Figma’s variables system is where most design token workflows now begin. Designers define primitives and semantic tokens as variables, group them into collections, and use modes to handle light/dark or brand-specific theming without duplicating layers. Figma’s own documentation shows how those variables surface to engineers through Dev Mode, closing the gap that used to require a “redline” handoff document nobody read properly.

Token plugins add bidirectional sync, pulling tokens out of Figma as JSON and pushing code changes back in. From there, Style Dictionary and similar build tools transform that JSON into platform-specific artefacts: CSS custom properties, Android XML, iOS Swift constants, generated from one source file.

• Figma variables + modes handle authoring and theming.
• Plugins handle the JSON export/import loop.
• Style Dictionary (or an equivalent) generates the platform code.
• The DTCG’s vendor-agnostic JSON format exists precisely so none of this locks you into one vendor’s proprietary schema.

That interoperability isn’t a nice-to-have. The DTCG’s entire premise is that a token file authored in one tool should be readable by any other, which is the only thing standing between design systems and total vendor lock-in.

Shipping tokens without breaking production

Tokens only deliver value once they’re treated as code, not design assets. That means storing token JSON in Git, running it through the same CI pipeline as everything else, and letting automation, not a designer exporting a spreadsheet, generate the platform artefacts.

• Store token source files in version control alongside components, not in a separate design repository nobody checks.
• Automate the build: CI pulls the JSON, runs it through Style Dictionary, and publishes CSS variables, Android resources and iOS constants as a single step.
• Fowler’s practitioner accounts describe publishing the output to an artifact registry, so component libraries pull a versioned token package rather than a moving target.
• Stage adoption: bump the token package version in one product surface first, watch for regressions, then roll wider.

Pro Tip: Coordinate token releases with component library releases using semantic versioning. A breaking token change (renaming color.action.primary, say) should force a major version bump on the component package that consumes it, otherwise teams update blind.

Colour, spacing and type in practice

The clearest way to see the layering is in code. A colour token chain typically looks like this:

Layer: Primitive | Token name: purple | Value: #5B21B6 | Consumed as: Raw palette entry

Layer: Semantic | Token name: color.action.primary | Value: {purple} | Consumed as: --color-action-primary in CSS

Layer: Component | Token name: button.background | Value: {color.action.primary} | Consumed as: Applied directly in the button component

Spacing follows the same logic on a numeric scale: a primitive space.4 = 16px becomes a semantic space.component.gap = {space.4}, which a card component then consumes as its internal padding. Typography chains a family, size and line height into a single semantic token, text.body.default, so a font-size change never requires touching twenty components individually.

Once defined, Style Dictionary exports the same source into a CSS custom property for web, an XML resource for Android, and a Swift or Kotlin constant for native, from one JSON file.

Keeping tokens alive: governance that actually works

A token system without ownership rots within two release cycles. Separate private tokens (raw primitives, internal naming, implementation detail) from public tokens (the semantic layer other teams and, in some organisations, external partners consume). Fowler’s argument for keeping option tokens private is really an argument for minimising your public surface area, since fewer public tokens mean fewer breaking changes down the line.

• Assign a named owner or small working group for the token library, not “the design team” as a vague collective.
• Deprecate tokens with a migration window, not a silent removal; give consuming teams a release or two to move off the old name.
• Review token usage quarterly and prune anything with zero references, dead tokens accumulate faster than anyone expects.
• Audit colour tokens against WCAG contrast requirements every time a theme or mode changes, since a semantic rename can quietly break accessibility that nobody re-tested.

Format-3’s perspective: tokens as infrastructure, not decoration

Most teams still treat tokens as a styling convenience, something a designer sets up in Figma and forgets about. That’s the wrong mental model. Tokens are product infrastructure: the layer that determines how fast your organisation can respond when a client demands a white-label theme, or when a rebrand lands on your desk with a two-week deadline.

The projects where this pays off aren’t the ones with the prettiest token names. They’re the ones where a rebrand or platform expansion, work that used to touch dozens of files, became a change to a handful of semantic values. The right moment to introduce tokens is during discovery, before the first component ships, not as a retrofit once technical debt has already compounded. Retrofitting a token system onto an established product is possible, but it costs roughly what building it correctly the first time would have.

— Martin

How Format-3 builds token systems that survive contact with production

There are other paths here: hire a full-time design systems engineer, buy an off-the-shelf UI kit and hope it fits, or muddle through with Figma styles and no code sync at all. None of those give you a token architecture that’s actually maintained past the first six months, because none of them pair the design decisions with the engineering discipline to enforce them.

Format-3 builds token strategy, layered architecture and CI/CD pipelines as one connected engagement, not a design deliverable handed to engineering to interpret. That means the semantic layer engineers consume is the same one designers authored in Figma, with no translation loss between the two. Clients typically see faster rebrand turnaround, fewer visual regressions between releases, and genuine platform parity across web and native, because the token pipeline enforces it automatically rather than relying on someone remembering to update three codebases by hand.

If your product is heading toward multiple themes, platforms, or a rebrand you can already see coming, look at how Format-3 approaches digital product design and engineering or browse the project portfolio for examples of systems built to scale rather than patched together. Get in touch to scope a token strategy before the technical debt writes itself.

Sources

• Design tokens | U.S. Web Design System (USWDS)
• Design Token‑Based UI Architecture — Martin Fowler
• Design Tokens: How to sync design and code in Figma | Figma

By Format-3

Press & Media

More thoughts

Thought leadership creates value, builds knowledge and takes a stand, bridging the gap between traditional and digital platforms