Design Tokens: The Source of Truth in 2026

This is Part 3 of the The 2026 Developer Stack series: 11 posts on the tools, workflows, and architectural patterns that define modern frontend engineering.

The Colour That's Never Quite Right

There are two versions of your brand's primary colour in your codebase. The designer has a third version in Figma. The marketing site has a fourth. Nobody's sure which one is canonical. The last engineer who "fixed" it changed three of them and missed the fourth.

Design tokens solve this, but only if they're automated. A token system that requires manual copy-paste from Figma is just moving the problem one step upstream. The architecture worth building is one where a designer publishes a Figma variable, and the change propagates to CSS, TypeScript, and every platform automatically.

The Architecture of Consistency

Design tokens are the atomic elements of a design system: colors, spacing, typography, shadows, and animation timings, expressed as data (typically JSON). Treating them this way, rather than as values scattered across component files, is what turns "keep the brand consistent" from a design-review checklist item into something a CI pipeline can actually enforce.

By treating design variables as code, the marketing site and the enterprise-scale dashboard stay in sync with the brand's evolution automatically, because they're both generated from the same source file rather than maintained by two teams independently copying values. When a design director updates a token in Figma, that change propagates through the product stack via the same pull-request review process as any other code change, so a developer verifies the diff, but nobody has to manually retype a hex value into three different config files.

Automation via GitHub Actions

The modern design token workflow connects Figma's API to GitHub Actions, so a design change flows to code without a manual step. The process typically looks like this:

1. Figma Update: A designer publishes a new version of the design system variables in Figma.
2. Webhook Trigger: Figma sends a webhook notification to our GitHub repository.
3. Token Transformation: A GitHub Action is triggered that fetches the latest variables via the Figma API. Using tools like Style Dictionary, these tokens are transformed into multiple formats: SCSS variables, Tailwind CSS configurations, and even TypeScript constants for React components.
4. Pull Request: The action automatically creates a new PR with the updated token files, allowing developers to review the visual changes before they go live.

This automation removes the specific human error that causes brand drift, someone manually retyping a value and getting a digit wrong, or updating three of four files and missing the fourth. It doesn't remove every failure mode: a bad transform in the Style Dictionary config, or an incorrectly-scoped Figma variable, still propagates through the pipeline just as fast as a correct one. The PR review step exists specifically to catch that class of error before it ships, not as a formality.

Multi-Platform Delivery

The strongest argument for this approach is its platform-agnostic nature. The same set of tokens can style a Next.js web application, a Flutter mobile app, and even email templates, because the token values are decoupled from any specific language's syntax, and Style Dictionary's job is exactly that translation layer.

By decoupling the value of a design property from its implementation in a specific language, maintaining consistency across platforms at scale stops being a coordination problem between teams and becomes a build step. It also makes complex features like dark mode, high-contrast themes, and multi-brand support meaningfully cheaper to implement: a new brand theme is a new token file mapped through the same transform pipeline, not a parallel set of hardcoded values maintained by hand across every platform.

Naming: The Decision That Outlasts the Tooling

The tooling around design tokens will change, Style Dictionary might get replaced, Figma's variable API will evolve, but a token naming convention, once components across the codebase depend on it, is effectively permanent. Get this wrong early and you're stuck maintaining backward-compatible aliases indefinitely. The convention that scales is semantic-first, not value-first: color-text-primary describes what the token is for, color-gray-900 describes what it currently is. A component should reference the semantic name, and the semantic name maps to a primitive value that can change (a full rebrand, a dark mode variant) without touching a single component. Naming a token after its current value is the token-system equivalent of naming a variable x: it works until the thing it's tracking changes, and then every reference is wrong.

Conclusion

The first step doesn't require the full pipeline. Export your Figma variables to a JSON file, run Style Dictionary over it, and replace one hardcoded colour in your codebase with the generated token. Once the path from design decision to shipped CSS exists, even manually triggered, automating the trigger is the easy part, but get the naming convention right before that first token ships, because that's the decision you won't get to redo cheaply later.

Next in the series: Notion as a Developer OS →. Tokens handle the design layer of your source of truth. Next: the knowledge layer, building a Notion system that stays alive instead of becoming the wiki nobody reads.

Sources & References

• Style Dictionary Documentation — official docs on token transforms and multi-platform build output
• Figma API Reference: Variables — official reference for reading and writing Figma variables programmatically
• W3C Design Tokens Community Group — cross-tool design token specification drafts
• Jina Anne — design systems practitioner and educator, an early advocate for the design tokens concept