What Are Design Tokens? And Why Should You Use Them

When it comes to your brand, consistency matters. When a brand shows up in a consistent way, it helps to build trust and connection with a user, the same way consistency in any relationship creates trust over time.

The way that consistency shows up within the relationship between your user and your brand manifests in so many ways, from the way a log-in experience behaves, to the tone of voice your brand uses within its documentation content, to the colors and typography on your website and within your product.

When you think about it that way, there are probably upwards of millions of tiny little opportunities for trust between a user and a brand, if you boil it down to every word, every color, every button, and the ways those elements add up to countless user experiences.

But, when you have a whole bunch of folks working within a brand creating those opportunities, the chances of developing inconsistencies increases. Especially as companies scale, it isn’t hard for communication siloes to develop, leading to tiny inconsistencies that grow over time.

To help ensure consistency, brands and the teams that create and maintain them — the designers, developers, marketers, product professionals, and more within a company — have turned to design systems: vast libraries of guidelines and elements for use across every part of a brand’s experience.

Within those design systems, there are design tokens, which we’ll define and discuss in this article.

Design tokens: Where the heck did they come from?

We mentioned Salesforce in our article about design system examples, and we’ll revisit them now, because design tokens as a defined concept comes from Salesforce, and specifically from Jina Anne, a former designer there who now consults widely across the design community advocating for the use of design systems.

Jina and her team developed a process by which all the repeatable experiences and elements across Salesforce’s massive brand experience were turned into discrete chunks — tokens, if you will — that included both the visual and code details for those elements, which were maintained regularly and used across teams to ensure a consistent brand experience.

So what are design tokens then?

We just defined them sort of, but to be more clear: design tokens are the atomic elements of design within a brand. They represent a named value of an agreed-up entity that both designers and developers can use to create consistent experiences within a brand.

Design tokens represent a group decision about the pairing of visual properties and the code that creates them, packaged up in a way that is usable across all platforms.

That last part is an important element of what makes design tokens useful and practical for teams, rather than an aspirational guideline that a team may agree upon but struggles to actually implement. Design tokens are platform-agnostic: that is, they exist as a common language that is usable across all of a team’s platforms and frameworks, no matter a team member’s role, and use a naming convention that is consistent across those teams.

Tokens are packaged up to store everything from color to dimensions, spacing, and padding to animation times and interaction rules. A simple example would be a team’s primary button hover color. Say it’s #FFFFFF, just for simplicity. The design token would be color.primary.background.button.hover = #FFFFFF.

Using design tokens

That all sounds great, but a concept or tool is only so useful as it is implementable, so let’s talk about some of the elements that make design tokens an actual worthwhile tool and practice for your team.

Obviously, the most important thing is universal buy-in across teams. Everyone needs to agree to use design tokens, otherwise — what’s the point?

Beyond that, the teams that will be using the design tokens need to agree on the framework by which they are developed and maintained. That means agreeing on what should be tokens in the first place, a process for developing a specific token, what is included within that token, and a consistent naming convention for all tokens as they are developed. Teams must also agree upon (and agree to use) a consistent process and storage method for maintaining tokens.

While it may seem like a lot to do and keep up with, design tokens and the design systems they are a part of actually prevent the massive amounts of reactive back-work that happens (and the frustration that accompanies it) when teams grow and begin developing inconsistent experiences that then proliferate like a virus across your brand. Learn more about creating your own design system.

‍