Token Engineering

Token modules

A hex value in a CSS file is not a source of truth. Tokens are contracts — between brand and product, design and code, humans and AI. They need a spec, a build, a release model. We treat them as what they are: infrastructure.

Work packages

Spec

DTCG-compliant token model with clear naming convention, tier structure (primitive → semantic → component), and explicit aliases. What applies is decided once.

Build

A single source pipeline: CSS variables, JS constants, iOS/Android resources, Figma variables. Format follows platform, not the other way around.

Release

SemVer, changelogs, breaking-change policy. Tokens are treated like an API — with deprecation paths instead of silent renames.

Migration

Lift legacy code onto the new token layer, introduce linting, ban hardcoded values. Refactoring in measurable steps, not a big bang.

Questions

Questions Token Engineering answers.

  • Single Source

    Do your tokens live in exactly one place — or do shadow definitions exist in Figma, CSS, and brand manuals?

  • Build Pipeline

    Are tokens automatically exported to CSS, JS, iOS, and Android — or is someone copying hex values?

  • Naming

    Do your tokens follow a documented convention or historical accident?

  • Versioning

    Can you say which token version is running in which app and which brand theme in production?

  • Breaking Changes

    How do you communicate token changes to downstream teams — changelog, Slack, hope?

  • Tier Separation

    Do you cleanly separate semantic tokens from primitive values — or does someone hardcode `#FF0000` directly?

Let's talk about
your token layer.

Get in touch