Design tokens were supposed to make our lives easier—but now they’re eating us alive. What started as a way to create harmony between design and code has turned into an endless maze of abstractions, debates, and JSON files nobody understands. This is the story of how our obsession with consistency turned design systems into bureaucracies.

In theory, design tokens were supposed to save us. They were the missing link between design and code, a neat way to abstract decisions—colors, spacing, typography, motion—into a unified language that both designers and developers could understand.

No more manually updating hex codes or tweaking border radii by hand. Instead, tokens would ensure consistency and scalability across entire ecosystems. Beautiful idea. Elegant in a slide deck.

But in practice, something went sideways. The same abstraction that promised harmony has started to suffocate creativity, clarity, and even the purpose of design systems themselves. We’ve entered the era of token fatigue—a point where the layers of abstraction have become so recursive, so self-referential, that the system spends more time describing itself than designing anything. Let’s unpack how we got here.

The concept of design tokens originated as a pragmatic response to chaos. Large teams—think Salesforce, IBM, Google—needed a way to manage visual consistency across multiple platforms. CSS variables, JSON files, and style dictionaries made it possible to express design decisions as code: color-primary, font-size-sm, spacing-md. These weren’t just labels; they were single sources of truth.

Tokens solved several problems at once. They bridged design and engineering by providing a shared vocabulary. They simplified scaling across multiple platforms and brands. They reduced entropy by codifying aesthetic choices into reusable values.

When used well, tokens helped teams move faster and stay aligned. They were the connective tissue between Figma components and React codebases—a kind of design Esperanto. But somewhere between “shared vocabulary” and “meta-system of nested abstractions,” we crossed a threshold. The focus shifted from using tokens to express design decisions to designing the tokens themselves.

At first, the appeal of tokens was clarity. But like any abstraction, once you start nesting abstractions inside abstractions, the clarity erodes. Instead of color-primary, you end up with color-background-surface-secondary-inverse-hover. Instead of a few key primitives, you have thousands of derived tokens that map to other tokens, which map to variables that reference yet more tokens.

It’s turtles all the way down, and none of the turtles remember what “blue” actually looked like.

The problem isn’t that abstraction exists—it’s that the abstraction has become the end goal rather than the means. Teams now spend weeks debating whether a variable should be “semantic” or “functional,” whether it belongs to the “core” set or the “alias” layer, and which naming schema will survive the next Figma release. This is what happens when a system becomes self-aware: it stops serving its creators and starts optimizing for itself.

You can sense the fatigue when designers start saying things like: “Can we just pick a color without checking the token hierarchy?” or “I don’t know which padding token is correct anymore.” These aren’t jokes—they’re cries for help.

Tokens were sold on the promise of consistency, but consistency itself is a slippery goal. You can have consistent colors and inconsistent experiences. You can have pixel-perfect grids that fail emotionally. The fetishization of consistency often masks a deeper anxiety: that without it, the system will unravel.

In large organizations, this anxiety is amplified by scale. The more products, teams, and markets you manage, the more tempting it becomes to build an abstraction so rigid that no one can break it. Tokens seem like the perfect solution—objective, measurable, and version-controllable.

But what happens when every decision must be routed through layers of token governance? You end up with visual bureaucracy. Designers stop designing and start requesting exceptions. Developers stop coding and start mapping. The friction tokens were meant to remove comes back in a new form—this time with better documentation and a JSON schema.

This is how abstraction eats itself: in trying to simplify the system, you add so many layers of management that the simplicity becomes theoretical. Consistency survives, but only as an aesthetic corpse—perfectly embalmed, utterly lifeless.

If you’ve spent time in a mature design system, you’ve probably seen this pattern: core tokens define fundamental values like colors, spacing, and typography; semantic tokens describe contextual meanings like button-primary-background or text-error-color; and alias tokens allow alternate mappings for themes, modes, or brands.

In theory, this hierarchy adds flexibility. In practice, it creates indirection hell. Changing the color of a button involves tracing three or four layers deep into token ancestry, deciphering whether a value was overridden by a theme or remapped by an alias. Each change requires a mini investigation.

You get systems so abstracted that even the people who built them can’t tell what’s going to change when a token updates. It’s abstraction so deep it starts resembling metaphysics.

Developers have a term for this: leaky abstraction. It means the details you tried to hide eventually seep back through, but now they’re harder to debug. In design systems, leaky tokens show up as mysterious color shifts, broken contrast ratios, or spacing inconsistencies that require archaeological digs to explain.

When you need a PhD in tokenology to update a button style, something’s gone wrong.

Behind every abstraction is a human trying to understand it. And as the mental model gets more complex, cognitive load skyrockets. Junior designers are intimidated. Senior designers are frustrated. Developers waste hours trying to locate which file defines the actual value of $border-radius-sm.

Instead of empowering people to think creatively, tokens can trap them in a maze of indirection. They become guardrails so high that no one can see over them.

This leads to a paradox: teams build systems to reduce decision fatigue, but the systems themselves become a new source of it. The abstraction that was supposed to liberate becomes a kind of cognitive tax.

And because no one wants to break the sacred design system, small acts of rebellion start to appear—hard-coded values, unapproved variants, local overrides. The shadow systems proliferate quietly in product files until they eventually outnumber the official ones. The design system remains pristine in the docs but irrelevant in reality.

One of the most visible symptoms of token fatigue is the ratio of documentation to design. A healthy system helps designers create faster. A fatigued system spends more time describing itself than helping people make decisions.

You know you’re there when the design system’s changelog is longer than the product roadmap, the documentation site has 300 pages and zero illustrations, and every component spec links to another spec that links to another layer of token definitions.

Designers are natural system thinkers, so it’s easy to fall into the trap of infinite refinement—wanting every rule to have a reason, every variable to be mapped. But the pursuit of total abstraction is like chasing the horizon: the closer you get, the further it moves away. What was supposed to clarify design now abstracts meaning itself.

At some point, you realize the tokens aren’t serving the product—they’re serving the documentation.

Why do teams keep doing this? Because scale is seductive. Abstraction makes us feel in control. It’s comforting to believe that by adding one more layer of hierarchy, you’re future-proofing the system. After all, who wouldn’t want a token structure that can handle ten brands, five platforms, three dark modes, and whatever AR/VR variant comes next?

But here’s the uncomfortable truth: you can’t abstract your way out of uncertainty. Every new abstraction is a bet on the future—and most of those bets don’t pay off. The future always arrives differently than expected, and suddenly your “future-proof” token structure feels like legacy debt.

The irony is that by over-optimizing for flexibility, you actually reduce it. When everything is parameterized, nothing feels fluid. The system becomes so generic that it can no longer express anything specific. It’s like trying to paint with variables instead of colors.

The result: products that are perfectly consistent but emotionally sterile.

The solution to token fatigue isn’t to abandon tokens altogether—it’s to rediscover their purpose. Tokens were meant to encode decisions, not defer them. They should capture design intent, not replace it.

In other words, bring design back to the surface. Tokens should support creativity, not constrain it. If the system can’t adapt quickly, it’s not a system—it’s a shrine.

There’s a quiet movement forming among design system veterans: a shift from maximalism to minimalism. Instead of 5,000 tokens, maybe you just need 50. Instead of 12 spacing values, maybe 4. Instead of 20 button variants, 3. The goal isn’t to encode every possibility—it’s to make the most common ones effortless and the rare ones possible.

This shift mirrors what happened in software engineering decades ago. After the over-engineering craze of the early 2000s, developers rediscovered simplicity through agile, lean, and component-based design. Design systems are going through the same adolescence.

The next evolution won’t be about more tokens, it’ll be about smarter defaults—systems that encode principles rather than parameters. For instance, instead of defining every possible color role, define contrast rules. Instead of spacing tokens, define rhythm systems. Instead of static naming conventions, define relationships between visual elements.

That’s not abstraction for abstraction’s sake; that’s abstraction in service of clarity.

The ultimate lesson of token fatigue is that abstraction always has a cost. Every layer you add distances you from the raw material of design—color, texture, light, rhythm, emotion. Too many layers, and you lose sight of why you were abstracting in the first place.

Tokens, in moderation, are an elegant way to communicate structure. But when they become an ideology, they start eating their own tail. The result is a system obsessed with describing design rather than experiencing it.

Maybe the healthiest design systems aren’t the ones with the most tokens, but the ones that know when to stop abstracting.

Because at the end of the day, the goal isn’t to create perfect consistency—it’s to create meaningful experiences. And that will always require a little bit of chaos, a little bit of imperfection, and a lot less JSON.

Let’s get this out of the way: AI doesn’t have taste. It has statistics. It knows what’s popular, what’s trending, what’s most likely to earn a double-tap — but it…

It’s easy to laugh at the 90s web now — the blinking GIFs, Comic Sans banners, table layouts held together with duct tape and hope. But beneath all that chaos…

There are so many new – and good – tools for designers out there right now. From tiny bits of artificial intelligence to icons that delight, there’s something to help…

We like to pretend that creativity thrives in total freedom — blank canvas, infinite possibilities, pure artistic autonomy. But if you’ve ever actually tried to design with no brief, no…

For a phrase that sounds harmless, “Is this on brand?” might be the quietest creativity killer in modern design. It’s the meeting-room equivalent of a wet blanket — a way to smother…

Cards are one of the most enduring UI patterns in digital design. They promise modularity, clarity, and adaptability—containers that can hold anything from product listings to social posts, news articles,…