Last CallLast Call Pool
Design Systems & Handoff

Is one year of design token struggles really worth it?

September 19, 2024 2:50 PM
Power Talk
🇬🇧 English
Wisła

About

The story of long and painful 12 months of introducing design token into one of my project.

- Why it took so much time?

- Why we after all didn't ship it?

- What blockers did we face along the road?

- Is it REALLY worth it?

I will more or less orbit around below bullet points to construct the final storytelling:

1. Phases description - selected phases of the journey, explanation of the general idea and execution plan

2. Good intentions, bad outcome - what went bad, why we didn't spot that we are doing circles for 12 months

3. Lessons learned - what have i learned during that period of time

4. It is still worth it - conclusion on my 12 months crusade that help me build next design tokens within a 1 month and ship it.

‍

Talk by

Photo of Daniel Wodziczka, Lead Product Designer at Software Mansion
Daniel Wodziczka
Lead Product Designer at Software Mansion

Watch the full talk

Watch this WaysConf session, then continue with related talks or explore the current programme.

Explore the 2026 agendaMore WaysConf recordings
From the recording

Talk in brief

In this WaysConf 2024 session, Lead Product Designer Daniel Wodziczka shares insights gained from a year of implementing design tokens following the launch of Figma variables. Base claims evaluate whether the organizational effort required to adopt tokens delivers proportional value. Wodziczka balances key technical benefits—such as easy setup, automated dark mode, and responsive scaling—against significant organizational red flags, including adoption friction and the hidden costs of retrofitting legacy codebases. The talk highlights why token systems thrive when built alongside new products with cross-functional support, but often struggle when forced into established systems without leadership buy-in. Ultimately, Wodziczka characterizes design tokens as a high-risk, high-reward methodology that demands early alignment, clear timing, and active team education.

Key takeaways

  1. 01

    Native Tooling Lowers the Learning Threshold

    Native software features like Figma variables make experimenting with primitive and semantic abstraction levels accessible without custom plugins. Designers can validate token architecture in real time using minimal setup.

    Watch from 2:41
  2. 02

    Organizational Buy-In Is Mandatory for Deployment

    Token initiatives developed in isolation struggle to gain traction if decision-makers and engineering partners are not actively involved. Grassroots efforts without dedicated timeline allocation often stall before reaching production.

    Watch from 7:30
  3. 03

    Semantic Tokens Automate Adaptive Layouts and Themes

    Setting up semantic aliases simplifies complex design requirements, such as generating dark modes or adjusting responsive font scales. Automated inheritance reduces manual style swapping across component variants.

    Watch from 10:52
  4. 04

    Timing Token Integration Matches System Maturity

    Building tokenized foundations works best when a new product has stabilized its initial screens and functional UI patterns. Attempting to tokenize too early during exploratory phases creates unnecessary maintenance overhead.

    Watch from 17:42
  5. 05

    Retrofitting Legacy Codebases Incurs High Re-work Costs

    Replacing established styling architectures with tokens requires overriding existing Figma libraries and refactoring production code. Teams should carefully evaluate if the refactoring overhead justifies the operational disruption.

    Watch from 18:47
Read edited transcript highlights

These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.

Lowering the Entry Barrier for Design Tokens

Reflecting on a year of working with design tokens following the launch of Figma variables, the entry barrier for building advanced systems has never been lower. Native tool support eliminates the need for custom plugins or complex workarounds, allowing designers to move directly from theoretical concepts like semantic levels and primitive structures to live testing. While initial terminology around taxonomy and governance can feel overwhelming, hands-on experimentation quickly reveals a structured, logical methodology. Tokenizing core foundations such as color palettes, border radii, and breakpoints provides robust flexibility while keeping the base system manageable.

Watch from 2:41

Why Token Systems Need Early Alignment

Building token foundations requires broad cross-functional involvement rather than working in isolated design scratchpads. Successful adoption depends on securing dedicated time from developers, collaborating with fellow designers, and gaining explicit support from team leads or executive decision-makers. In an early attempt to introduce tokens, the structural work was completed in isolation without leadership buy-in or developer alignment, resulting in the initiative getting deprioritized in project backlogs. Design tokens represent an operational model for the entire team, meaning single-person implementations rarely succeed without shared ownership from the start.

Watch from 7:30

Streamlining Dark Mode and Typography

The practical value of semantic tokens becomes clear through the elimination of tedious manual styling tasks, particularly surrounding dark mode and responsive design. Rather than creating separate component variants and tracking color changes manually, semantic mapping allows components to re-theme automatically based on active variable modes. Similarly, typography tokens can be linked to responsive breakpoints so that a single header style automatically scales down from desktop to mobile screens. Establishing these rules at the foundational level guarantees speed and visual consistency throughout all downstream components.

Watch from 10:52

Training Teams Amid Delivery Deadlines

Reaching production deployment with a tokenized system is only half the battle; ensuring team adoption requires dedicated onboarding time. During a second implementation effort, tokens successfully landed in both design files and production code, yet full adoption stalled due to aggressive project deadlines. Team members lacked the time and bandwidth to learn the updated token structure, preventing them from applying the variables correctly in daily work. Technical deployment must be paired with structured training and operational support, or teams will default to familiar legacy habits.

Watch from 13:43

Determining the Ideal Phase for Tokenization

Introducing design tokens yields the highest return on investment when applied to newly emerging products that lack an established design system. During early product exploration, heavy system construction should be paused until core UI patterns and initial screens solidify. Once a product passes this preliminary stage and functional flows take shape, building tokenized foundations alongside growing features creates a clean, scalable setup with minimal risk. Aligning system growth directly with product maturity ensures low overhead and smooth adoption across engineering and design.

Watch from 17:42

The Hidden Costs of Refactoring Legacy Systems

Retrofitting an established design system with tokens presents severe technical and organizational challenges. Replacing existing foundations in a live project demands extensive re-work across complete Figma libraries, full component sets, and uncomponentized code instances. Unless an organization deliberately halts feature development to focus entirely on refactoring, forcing tokens into mature codebases generates frustration, breaking changes, and wasted effort. Teams should weigh these substantial migration risks carefully before attempting to tokenize existing legacy systems.

Watch from 18:47
Explore WaysConf 2026

View the agenda

Get tickets