There's a specific kind of meeting that happens at growth-stage companies around the eighteen-month mark of a design system project. Someone from engineering asks why it takes three days to change a button color. Someone from design says the tokens aren't the problem, the implementation is. Someone from product says they don't care who's right, they need the feature shipped. And the design system lead — who has spent the better part of a year building a beautifully layered semantic token architecture — sits quietly, knowing that explaining it will only make things worse.
This meeting is not a failure of communication. It's a structural outcome. The token architecture created it.
Design tokens are one of those ideas that make complete sense in the abstract and cause real damage in practice — not because the concept is wrong, but because the gap between the concept and most implementations is enormous, and almost nobody talks honestly about what fills that gap. What fills it, usually, is complexity that serves the system's internal logic rather than the people who have to ship products with it.
The thesis here is blunt: most token architectures at startups and growth-stage companies are over-engineered relative to the problems they actually solve, and the overhead they introduce — cognitive, organizational, and maintenance — routinely exceeds the value they deliver. The solution isn't to abandon tokens. It's to understand precisely where the abstraction earns its keep and where it becomes what one practitioner has called visual bureaucracy.
The Abstraction Earns Its Keep Exactly Once
Start with what tokens actually do well, because the critique only lands if you're honest about the genuine use case.
A token system solves one real problem elegantly: it decouples visual decisions from implementation details. When your brand color is --color-brand-primary: #0066FF rather than a hardcoded hex scattered across 200 component files, you can change that color in one place and have it propagate everywhere. That's not nothing. For teams managing multiple themes, multiple brands, or a dark mode that has to stay in sync with a light mode, this single property of tokens is genuinely valuable.
The multi-brand case is where the architecture pays off most clearly. A shared component library with brand-specific token layers on top means the same <Button> component renders correctly for Brand A and Brand B without duplicating component logic — you're swapping the token layer, not rewriting components. That's a real architectural win. The claim that this approach eliminates significant redundant design work is credible on its face, even if the specific percentages cited in various enterprise case studies should be treated skeptically without knowing the baseline.
The Figma-to-code synchronization problem is also real. When designers work in one system and developers implement in another, you get drift — the button in Figma is #0066FF and the button in production is #0064FA because someone eyeballed it six months ago. A token pipeline that maps Figma variables directly to CSS custom properties consumed by your utility framework closes that gap structurally rather than relying on discipline. When every token in the Figma file maps directly to a CSS custom property, the "Figma says one thing, code does another" problem becomes a tooling problem rather than a human coordination problem.
So: tokens earn their keep when you have multiple themes or brands to maintain, when Figma-to-code drift is causing real bugs or rework, and when you have enough surface area that a single source of truth for visual decisions meaningfully reduces coordination overhead.
The problem is that most teams implement a full token architecture before they have any of those conditions. And the architecture they implement isn't the simple version that solves those problems — it's a layered semantic system that introduces a whole new category of problems.
The Layering Is Where It Goes Wrong
The standard advice for token architecture involves three tiers: primitive tokens (raw values), semantic tokens (purpose-mapped aliases), and component tokens (component-specific overrides). The W3C Design Tokens Community Group has been working toward a spec that formalizes this kind of structure. Tailwind, Radix, and other major systems have their own takes on the layering model.
In theory, the layering is elegant. --color-interactive-default aliases --color-blue-600, which aliases #2563EB. Change the primitive, the semantic updates. Change the semantic, every component that references it updates. Clean separation of concerns.
In practice, the layering creates a navigation problem that compounds with every layer you add.
When a developer needs to change the hover state of a button, they have to trace: which component token governs this? Which semantic token does that alias? Which primitive does the semantic alias? Is the primitive the right place to change this, or should I create a new semantic token? If I create a new semantic token, does it need to go through a review process? Who owns the token taxonomy?
[Robin Cannon has written about this directly](https://www.robin-cannon.com/p/the-design-