Design tokens that survive a year of product growth
Most token libraries don't survive contact with the second product surface. Here are the four rules we follow so ours do — and the one trade-off they force.
The first time I built a "design system" was 2017. It was a Sketch file with shared styles. It survived three months. The second was a Figma library — six months. The current one, for a Slym-style platform, is past 14 months and still expanding without major rewrites.
The difference isn't the tool. It's four rules we now follow before a single color gets a name.
Rule 1: Two layers, never one
Primitives are raw values: purple-500, space-4, font-lg. They describe what they are. Nothing in product code touches them directly.
Semantic tokens are jobs: color-action-primary, space-section-y, font-title-display. Product code consumes only these.
When the brand inevitably shifts purple → indigo in month 8, you change color-action-primary once and the entire product follows. Without that semantic layer, you'd be doing a global find-and-replace on hex codes.
Rule 2: Light/dark is a value, not a separate library
We see teams maintain two parallel token sets. It's a death spiral — every new component doubles the work.
Instead, every semantic token has two value modes baked in. Figma variables and Tailwind dark variants handle the resolution. One token, two modes.
Rule 3: Code-mirrored, Code-Connect-bound
Tokens that only exist in Figma break the moment a developer ignores the spec. Tokens that only exist in code make designers blind.
Our flow: tokens authored in Figma → exported to a JSON file → compiled into Tailwind config + CSS custom properties. Then Figma Code Connect binds each component to the React/Vue implementation, so a designer hovering a button sees the exact JSX a developer should ship.
This sounds expensive. It's about 6 hours of setup and it eliminates 90% of design-spec disputes for the rest of the year.
Rule 4: Components own their semantic tokens, not the other way around
Resist the temptation to make tokens like color-button-primary-bg. Components get their semantic, not the other way around. Define color-action-primary; the Button component reads it.
Why? When you add a Banner component or a NavChip, they want the same action color. If your token is named after Button, those components have to either steal Button's token (confusing) or get their own (system bloat).
The trade-off
Designers hate the constraint at first. "I just want this one card to be a tiny bit darker." Two-layer tokens force the conversation: either we're adding a new semantic (it's a real new job, justified), or this is a one-off override that doesn't deserve a token.
That friction is the point. It's what keeps the system from sprawling into chaos by month four.
We build token-first design systems as part of our Design Systems engagement. Average timeline: 3–6 weeks for a full Figma library + code mirror + docs. Submit a brief if you want one for your team.