How to Align Design Tokens with the Real Product Roadmap

TH

Lessons from Managing a UX/UI Team

Many people may know “Design Tokens” as a system for storing all design variables, such as spacing, colors, and typography, so that the UI design team and developers can work with the same values consistently, reducing duplication.

But in reality, turning tokens into something actually used in production, especially in a context where the roadmap changes every month and deadlines drive every decision, requires far more than just creating a Figma library and handing it off to developers.

In this article, I want to share insights from the perspective of a UX/UI team lead—how to plan strategically, design the system, and enable the design team to produce scalable, high-standard work without falling out of sync with the product timeline.

Design Tokens Are a Long-Term Investment, Not an Instant Win

Speaking from experience, starting a Design Token initiative can feel like a “big, heavy project” in a reality where almost everyone in the team already has projects on hand. Picking up a Design Token project might seem like an extra burden—one that doesn’t feel urgent or show immediate results.

This kind of “behind-the-scenes” investment is often seen as “not a priority,” especially when compared to work that must be delivered before a deadline.

But what made us commit was the belief that tokens are a system-level tool, a structural investment that allows the product to scale efficiently, and enables the design team to work faster in the long run, without having to repeatedly re-code or re-design every time the CI changes or a feature expands.

Learn from Others, Define for Ourselves

Before we started, our team researched Design Token systems from multiple companies, such as Atlassian, Material, Tailwind, and also explored community and open-source approaches.

We studied naming conventions, categorization, and developer pipeline integration, then adapted them to our context.

What we learned was:

“The best plan is the one that fits your team and context.” There’s no need to copy someone else’s model exactly, every team has different needs and constraints.

Examples:

• We based our token structure on Tailwind CSS, which our devs were already using.

• We used Figma plugins and export formats that devs could implement right away, like JSON, reducing manual handoff and speeding up implementation.

Pilot Projects Changed the Team’s Mindset

We began with an internal project we fully owned, which became our pilot for serious Design Token implementation. Our goals were to:

• Create tangible use cases.

• Show stakeholders and other teams that tokens aren’t just an “invisible system,” but something that delivers faster releases, easier edits, and scalable results.

The results:

• Dev implemented faster.

• Designers could move forward without rework.

• UI consistency remained intact even with multiple designers working in parallel.

How We Embedded Tokens into the Roadmap

1. Integrate Tokens into Real Features — Not in Separate Sprint

Instead of creating a separate epic just for tokens, we embedded them into features already in active development, making token creation part of the product’s evolution, not a side task.

Example:

• Designing a new UI card → use this opportunity to define color, spacing, shadows, and radius as tokens.

• Updating existing UI → collaborate with devs to refactor and replace hardcoded values with tokens.

• Changing a client’s CI → update the token set to instantly refresh the entire system without redesigning from scratch.

2. Establish a Shared Language with Developers from the Start

We created conventions together with devs, based on Tailwind-like naming:

size/scale-0.5 = 2px  

size/scale-1   = 4px  

size/scale-2   = 8px  

Then we connected tokens to the actual dev pipeline using tools like Token Studio and Style Dictionary, exporting directly into dev-ready formats and eliminating manual conversion and misalignment.

Validation: Tokens Deliver Measurable Time Savings

To validate impact, we compared features using tokens vs. those without.

Finding: In the same design phase timeframe, tokens reduced design work time by ~10% per FTE.

Note: This is from one feature; we plan to validate two more to get a more accurate dataset.

Other benefits we saw:

• Better-structured work.

• Faster communication between devs and designers.

• Quicker and non-repetitive changes.

• Easier scalability for both new and existing projects.

What We Learned

• Tokens shouldn’t be separated into special sprints; they should be embedded in real work and the actual roadmap

• Setting conventions with devs early drastically reduces friction.

• Don’t wait for perfection—Design Systems are never “done.” They evolve alongside the product.

Conclusion

Good Design Tokens are not just about Figma or code; they are a strategic framework for building a standardized, scalable product ecosystem.

While they may not pay off in the first sprint, they return value by sprint 3, 5, and 10—especially when the team needs to change a client’s CI, onboard new developers, or launch features faster than ever.

One project where we officially applied Design Tokens was Sertis KMAI / Private LLM—an enterprise-grade intelligent assistant platform that connects internal data to AI securely and precisely. Our team was responsible for UX/UI design and implementing a ready-to-use token system for enterprise environments.

Curious what KMAI can do? Read more here → Sertis KMAI: Enhance your Company’s Knowledge Management Cycle with AI

Design Tokens may seem like a back-end, invisible system, but when implemented strategically, they can accelerate product development and build team confidence.

If you see tokens as an “extra” task, try reframing them—they could be the tool that makes your team move faster and your pro