Experiment
Design systems have a synchronization problem. Designers update tokens in Figma. Developers maintain different tokens in code. Over time, they drift. Colors become inconsistent. Spacing values multiply. The single source of truth becomes... two sources of truth that don't quite match.
At BrightHR, I felt this acutely. Our BrightUI design system lived in two places - design tokens in Figma and implementation tokens in code. When designers changed colors, developers had to manually update CSS variables. When developers needed new tokens, they'd message designers for values. Manual. Error-prone. Slow.
There had to be a better way to centralise this.
So I built an experimental sync system. Design tokens published to npm. Figma pulls from npm. Vite project consumes from npm. Single source of truth, readable from both sides. Changes propagate automatically instead of manually.
Demoed it to stakeholders involved with BrightUI. Not production-ready, but it proved the concept. Bi-directional token sync is achievable without complex pipelines or enterprise tooling.
Built it fast - proper vibe coding session. Sometimes you just need to prove an idea works before investing in proper infrastructure.
The Problem I Was Solving
Manual token synchronisation doesn't scale. Every color change means updating Figma, then updating CSS variables, then updating documentation. Miss one step and things drift. Multiply that across dozens of tokens and frequent updates? Unsustainable.
What I needed:
- Centralise color tokens in one shareable format
- Enable Figma to pull tokens automatically (no manual updates)
- Enable code projects to consume same tokens (single source)
- Support bi-directional reading (both sides reference the same data)
- Prove the concept without building complex infrastructure
The technical challenge was finding the right intermediate format. Tokens needed structure that both Figma plugins and build tools could parse. They needed semantic meaning (not just key-value pairs). And they needed to support token references and composition.
What It Does
The solution centers on npm as the distribution mechanism. Design tokens live in jamie-tokens package as structured JSON following the Design Tokens Format Module specification. Publish once, consume everywhere.
On the Figma side, Tokens Studio plugin points at the published npm package. When tokens update, Figma syncs automatically. Designers work with the same color palette that developers use. No manual copying of hex values.
On the code side, a Vite project imports jamie-tokens directly. Tailwind configuration extracts token values and maps them to utility classes. Change a token in the source, publish to npm, both Figma and code pick up the update.
Token structure supports references - values can point to other tokens. Spacing scales can reference base dimensions. Color variants can reference primary colors. Composition and semantic relationships preserved across both tools.
The implementation is deliberately simple:
- JSON tokens following W3C design tokens spec
- npm package for distribution
- Tokens Studio plugin for Figma integration
- Vite + Tailwind for build-time token extraction
- Helper functions to flatten token structure into usable values
What you get is bi-directional sync without custom infrastructure. Publish tokens. Both sides update. Done.
Why This Actually Matters
For BrightUI specifically, this demonstrated a pragmatic path toward token centralisation without requiring enterprise design system platforms or complex CI/CD pipelines. Just npm, standard JSON, and existing plugins.
Eliminates manual synchronisation completely. Designers and developers reference the same token source. Update once, propagate everywhere. That alone saves hours of coordination and prevents drift.
Reduces errors. No more typos when copying hex values. No more missing token updates. No more checking whether Figma matches code. If they're both pulling from npm, they match.
Design tokens become a shared language between design and development. Same names. Same values. Same semantic structure. Conversations shift from "what's the value of primary-500?" to "should this use primary or accent?"
The npm-based approach is practical and lightweight. No specialised platforms required. No complex authentication or APIs. Tools already exist that can consume npm packages. You just wire them together.
Pattern is reusable beyond colors. Spacing scales, typography tokens, border radius, shadows - anything that needs synchronisation works the same way. Prove it with colors, expand to the full design system.
Most importantly, this validated that centralised token sync is achievable without massive infrastructure investment. For teams looking at design system maturity, this shows you can start simple and prove value before building complex automation.
What I Built It With
Token Management:
- Design Tokens Format Module (W3C spec)
- JSON token structure with references and composition
- npm for distribution and versioning
Figma Integration:
- Tokens Studio plugin for Figma
- Automatic sync from npm package
- Token application to Figma styles and variables
Development Environment:
- Vite for fast development and HMR
- Tailwind CSS with custom token integration
- Helper functions to extract and flatten token values
- PostCSS for CSS processing
Token Structure:
- Dimension tokens (base scaling values)
- Spacing scales (xs, sm, md, lg, xl)
- Border radius scales
- Comprehensive color palette (grays, reds, oranges, yellows, and more)
- Token references using
{token.name}syntax
The architecture is deliberately minimal. No custom servers. No databases. No APIs. Just JSON, npm, and plugins that already existed. Sometimes the right solution is the one that uses what's already there.