We stand with Ukraine and our team members from Ukraine.

The Community Of Over 640,000

Home ›› Customer Experience ›› Design Token Thinking

Design Token Thinking

by Mark Cianfrani
5 min read
Share this post on


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.

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

Learn ways user experience research can help build responsible AI applications.

How User Experience Research (UXR) Cam Help Build Responsible AI Applications
  • UXR reveals the myriad of intended and unintended effects of apps on people’s life — and help build more ethical AI
  • The author talks about:
    • How to assess the impact of ML-apps on users and meet AI ethical standards?
    • Ethics in AI
Share:How User Experience Research (UXR) Cam Help Build Responsible AI Applications
3 min read
How User Experience Research (UXR) Can Help Build Responsible AI Applications?

When less is usually — but not always — more


Balancing Cognitive Load and Discoverability
  • The author explains how reducing cognitive load helps user interfaces seem easier to use.
  • The article covers:
    • Information Architecture & Cognitive Load
    • Staggered vs Flat Information Hierarchies
    • The case for a flat hierarchy
    • The case for a staggered hierarchy
  • Balancing cognitive load and information density requires a lot of skill and deep knowledge of your customer.
Share:Balancing Cognitive Load and Discoverability
3 min read

Tips on how to design for the blind.

Design for the Blind

The author explains how to design for people using Assistive Technologies and offers 5 tips.

Share:Design for the Blind
4 min read

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