Design tokens have revolutionized how we build and maintain design systems, offering a structured way to ensure consistency and scalability across digital products. They help teams align on colors, typography, spacing, and other design decisions in a way that works for both product designers and developers. While they offer great benefits, they can also introduce unnecessary complexity if not thoughtfully implemented.

In this article, I will explore some common challenges teams face with design tokens, supported by examples of when they can backfire — and how to fix them.

Unnecessary complexity if over-engineered

Problem: Too many layers of abstraction can make tokens difficult to use.

Example: A design team introduces five levels of color tokens:

  • Core tokens: color-blue-500, color-blue-700
  • Semantic tokens: brand-primary, brand-secondary
  • Component tokens: button-primary-background, card-background
  • Platform-specific tokens: ios-primary, android-primary
  • Contextual tokens: marketing-banner-background, dashboard-primary

When a designer or developer needs a blue color, they now have to trace multiple levels to find the right token. This slows down decision-making, increases confusion, and makes the system harder to maintain.

Solution: Keep the number of abstraction layers minimal. If a single level of semantic tokens (e.g., brand-primary) is enough, don’t add extra layers unless necessary.

Harder to maintain when not well-structured

Problem: Inconsistent naming and redundant tokens make updates a nightmare.

Example: A company’s design system has these tokens for colors:

  • primary-color
  • main-color
  • primary-500
  • button-primary-bg
  • brand-main
  • base-color-1

Over time, different teams start using different names for the same color, leading to confusion and duplicate tokens. When the brand color changes, updating these scattered tokens becomes an overwhelming task.

Solution: Establish a clear naming convention from the start and maintain a single source of truth. A better approach might be:

  • color-primary-500
  • background-primary
  • text-primary

Cognitive load for designers & developers

Problem: Too many tokens make it difficult for teams to choose the right one.

Example: A design system introduces multiple sets of spacing tokens:

  • spacing-xs, spacing-sm, spacing-md, spacing-lg, spacing-xl
  • spacing-md-ios, spacing-md-android, spacing-md-web
  • button-spacing-md, card-spacing-md

A developer working on a mobile component is now uncertain which token to use. Should they go with spacing-md, spacing-md-mobile, or spacing-md-ios? This decision fatigue slows down work and increases the risk of inconsistencies.

Solution: Limit the number of tokens and keep them consistent across platforms unless absolutely necessary. Stick to one override level (e.g., spacing-md vs. spacing-md-mobile).

Redundancy & bloat

Problem: Too many similar tokens lead to unnecessary duplication.

Example: A design team creates typography tokens for different use cases:

  • heading-primary
  • heading-secondary
  • heading-tertiary
  • title-1
  • title-2
  • h1, h2, h3
  • page-title, card-title, modal-title

Many of these tokens serve the same function, leading to unnecessary duplication. Some teams use h1, while others use page-title, creating inconsistencies in usage.

Solution: Stick to a core typography scale (e.g., text-xl, text-lg, text-md). If necessary, use semantic tokens only for specific use cases (e.g., heading-primary instead of separate tokens for page-title, modal-title, card-title).

Adoption challenges

Problem: Teams struggle to adopt design tokens when they are introduced abruptly.

Example: A design team renames colors:

  • blue-500 becomes primary-surface
  • gray-300 becomes secondary-border
  • black becomes text-dark

Developers now need to refactor their entire codebase to match the new token names. Without proper documentation, some developers continue using hardcoded values, creating inconsistencies.

Solution:

  • Introduce tokens gradually with proper documentation.
  • Provide a migration strategy to help developers transition smoothly.
  • Conduct training sessions to educate teams on how to use tokens effectively.

Design tokens are powerful tools for ensuring consistency and scalability in design systems, but they must be implemented thoughtfully. When over-engineered, poorly structured, or introduced without proper adoption strategies, they can create more problems than they solve. The key is to strike a right balance, and this should be guided by the needs of the stakeholders and the product supported by the design system.

Want to discuss anything and everything design? Let’s connect on LinkedIn, or explore my work on my portfolio.

#NeverStopLearning 🚀

Design tokens: A double-edged sword in design systems was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.