Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Get exclusive access to thought-provoking articles, bonus podcast content, and cutting-edge whitepapers. Become a member of the UX Magazine community today!

Home ›› Customer Experience ›› Design Token Thinking

Design Token Thinking

by Mark Cianfrani
5 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

Design token thinking

Design tokens aren’t just something that you can easily retrofit into your existing wardrobe. They require an entirely new way of thinking and working. Learn how to start thinking in design tokens by completely changing the way you work with design systems.

Everybody’s talking about design tokens — how to name them, how to organize them, how to use them, but design tokens aren’t just something that you can easily retrofit into your existing wardrobe. They require an entirely new way of thinking and working. If you want to start using design tokens, you need to start thinking in design tokens, and to start thinking in design tokens, you need to completely change how you think about design systems.

How we got here

Let’s step back and talk about design systems. What is a design system? Webster’s dictionary defines a design system as “I have work I need to get done and I don’t want to have to think about what color I should make this button.” Design systems are just a bunch of decisions (keyword, this will be on the test) that have already been made for you. Yeah, and they enforce consistency, promote brand awareness, empower users, save you millions of dollars, yadda yadda. So how do you make one?

The old way

Design Token Thinking. The button in Figma, developers, designer, color palette.

A typical workflow might look something like this:

Somebody wakes up one morning and says “we need a common design for buttons”. This feature then starts with a design team. The design team mocks something up in their design tool. They iterate. They turn in their deliverable. Somebody signs off on it. Now the design file is handed off to a development team, who will translate it into some code that somebody will use in an application. Sound familiar?

This baton-passing is how we’ve been doing it for years. It’s great. It makes sense, except design systems are never finished. They are living, breathing things. So in six months when we change our button color, now the development team needs to update their button code. And what happens if we change our primary color, which is what the button was using? Maybe we add a new state or a new variant. More batons, more chances for them to be dropped.

Adobe refers to their design tokens as “DNA”. I think that is a perfect name and a perfect analogy. Every time DNA replicates, there is a chance for a mutation to occur, an error in the copying process. Every time you change a design decision, you have the same risk for mutation when that decision gets copied downstream to other consumers. We want to reduce the number of times our design decisions are replicated.

Reframe your source of truth

In this example, our source of truth is the design file. Until design tokens came around, we haven’t had a great way of representing a design system as a tangible “thing”. Design files were the best implementation, but a design file is not the design system. It’s just one of many implementations. Design files serve designers. Design systems serve everybody.

In our example, in order to access the design system, a user must now:

1. Have access to the design file’s software
2. Have access to a device that is capable of running the design file’s software — operating system, minimum hardware requirements, etc.
3. Have some basic understanding of how to operate the design file’s software.

Next, they need to:

1. Decode the design decisions made in the design file.
2. Potentially translate some values to their specific platform, for example, a web developer may want units in rems while the design file defines them in pixels.
3. Encode the design decisions to their specific platform.

All of these things are barriers to entry for people who just want to know what color to make their button. Yes, you can and should be documenting your design system, but the documentation will always be a step behind your design file. What if there was a better way?

The way of the future, (the way of the future)

Design Token Thinking. Button, Figma, design token, color palette, designer.

When a designer is working in a design file, they’re implicitly making dozens of design decisions. “The background color of this button is #f3f3f3. The padding is 20px. It should have a 3px border-radius”.

But what if they documented those design decisions at the time they made them? Instead of using the design tool to capture these design decisions implicitly, what if they captured them explicitly using something that was more accessible?

Imagine if they kept a notepad on their desk and every time they made a new design decision, they recorded it in their notepad in plain English. Now they can hand that notepad to all consumers of their design system and completely eliminate the decoding step because there is a shared language.

Now, recording design decisions in a notepad on your desk probably aren’t the best method though. You might use a third-party service, a google doc, a separate Figma page, or some JSON on GitHub. We use the Figma Tokens plugin and found it to be the least friction for designers because it allows them to work within the tool they are most comfortable with. The most critical piece is that your design tokens become the primary method for how you talk about and interact with your design system, both internally and externally.

It’s all about a shared language

Design Token Thinking. Design tokens. Happy people walking, dancing. Tools like Adobe, Figma, Sketch. IOS, Android.

A funny thing happens when you start thinking about design tokens. When you shift your source of truth to something that is more universal, now you’ve opened up the lines of communication. Developers can have a more active role in the design system. Outside contributors can propose new changes. Everybody shares a common language.

[_Doug ordering from the Honker Burger for the first time_] 
Doug: Hi, I’d like three double cheeseburgers, one all the way, one no pickles, one no onions, a fish sandwich, four large fries, and four grape sodas. 
Honker Burger Lady: What on Earth are you trying to say? 
Doug: What do you mean? 
Honker Burger Lady: I can’t understand you. 
Doug: Listen, my family is starving…. 
Skeeter: Yo, man, let me take care of this. The new kid wants three moo cows, one no cukes, one no stinkers, one wet one, four cubers, and four from the vine. Want anything else? 
Doug: Well, how do you order a salad from the salad bar? 
Skeeter: One salad from the salad bar.”
 Mosquito ‘Skeeter’ Valentine, Doug, S01E01

Design Tokens are our Mosquito Valentine. They allow users of multiple platforms and backgrounds (Doug, who doesn’t know anything about Figma) to communicate with our design system (the Honker Burger).

And sometimes, you really can’t come up with a better name than one-salad-from-the-salad-bar.

The Cost of Design Tokens

Design tokens have a real cost though. You’re offloading the encoding/decoding work that is required from end users of your design system onto the designers themselves. There is no getting around that, but the work is significantly less and the rewards are immense. In the end, you get a design system that is 1. Future proof 2. Accessible 3. Able to be easily changed.

Design tools change. We had Photoshop, then Sketch, then Figma. Platforms change. We had desktop computers, mobile devices, iOS and Android, watches, tablets, TVs, and refrigerators. Everything changes, but a button will always be a button.

post authorMark Cianfrani

Mark Cianfrani

UX developer focusing on Design Systems, Design Tokens, and all things Web Components.

Tweet
Share
Post
Share
Email
Print
Ideas In Brief
  • Design tokens require an entirely new way of thinking and working.
  • Designers can be documenting their design system, but the documentation will always be a step behind their design file.
  • The author unpacks the idea of an alternative design system and names it “the way of the future.”
  • Design tokens need to become a primary method for how you talk about and interact with your design system, both internally and externally.
  • In the end, you can get a design system that is:
    1. Future proof
    2. Accessible
    3. Able to be easily changed.

Related Articles

Struggling with PowerPoint’s design limitations? This step-by-step guide shows you how to build systematic design solutions, from mastering slide layouts to using sticker sheets for patterns. Learn to create polished, professional presentations with smart workarounds and helpful tips.

Article by Jim Gulsen
A Step-by-Step Guide to Creating a “Design System” in PowerPoint
  • The article gives a step-by-step guide to building systematic patterns in PowerPoint. It talks about the program’s limitations and gives essential tips like mastering slide layouts and customizing text settings.
  • It suggests using PowerPoint’s automated features carefully and advocating for manual workarounds to elevate quality.
  • The piece introduces creating sticker sheets for reusable design components and highlights strategies for successful workflows.
Share:A Step-by-Step Guide to Creating a “Design System” in PowerPoint
5 min read

Publishing in HCI and design research can feel overwhelming, especially for newcomers. This guide breaks down the process — from choosing the right venue to writing, submitting, and handling revisions. Whether you’re aiming for conferences or journals, learn key strategies to navigate academic publishing with confidence.

Article by Malak Sadek
A Guide to Publishing Human-Computer Interaction (HCI) and Design Research Papers
  • The article provides a guide to publishing in Human-Computer Interaction (HCI) and design research, sharing insights from the author’s PhD experience.
  • It explains the significance of publishing in academia and industry, offering an overview of peer-reviewed journals and conferences.
  • It breaks down the two main types of papers — review and empirical — detailing their structures and acceptance criteria.
  • The piece emphasizes strategic research planning, collaboration, and selecting the right venue for submission.
  • The piece also outlines practical steps for writing, revising, and handling rejections, encouraging persistence and learning from reviewer feedback to improve publication success.
Share:A Guide to Publishing Human-Computer Interaction (HCI) and Design Research Papers
8 min read

Accessibility isn’t just about compliance — it’s about inclusion. A deaf developer shares what UX designers need to know to create better experiences.

Article by Tamara Sredojevic
Designing for Deaf Users
  • The article talks about a deaf developer who shares insights on digital barriers, assistive tech, and inclusive design.
  • It presents a candid conversation on UX challenges, assistive technology, and advocating for better accessibility.
  • The piece dives into the challenges and solutions for creating truly accessible experiences.
Share:Designing for Deaf Users
11 min read

Join the UX Magazine community!

Stay informed with exclusive content on the intersection of UX, AI agents, and agentic automation—essential reading for future-focused professionals.

Hello!

You're officially a member of the UX Magazine Community.
We're excited to have you with us!

Thank you!

To begin viewing member content, please verify your email.

Tell us about you. Enroll in the course.

    This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and