Design Tokens Are More Than A Variable
5 min read

Design Tokens Are More Than A Variable

Design Tokens Are More Than A Variable

Hey everyone! It's been a really busy week for us at Arcade, with lots of our time dedicated to preparing our talk at the Knapsack Design Token Summit that happened this past Wednesday (thank you Andrew & team!).

There were about 30 industry leaders in attendance, and it was a huge honor to be able to share some of what we learned at the summit. We realize many curious people were not able to attend, so we're writing up this post to cover some of what we shared.

Keep in mind that after the summit, many of these ideas are evolving and will continue to evolve as we learn more and more. Conversations with community members (like you!) help us drive the technology we build and the opinions we form. It's always changing! But let's go into where we're at now with some of our insights.

Our Beginnings and Inspiration

Our story started this past summer when Dan presented us with a problem some of his design system teams were facing. Design tokens were powering these hugely complex software products, yet clients had no way to manage them. There was no easy way to keep track of these decisions in an effective way. Some teams were using Figma, Sketch, some were using spreadsheets in Excel or Airtable. The landscape was, and frankly still is, a mess in this regard. Dan proposed Arcade as a solution to this, to act as a single source of truth for these design tokens.

Existing solutions are... bad.

As we got talking, we started to realize the potential benefits of a single source of truth for design tokens. We figured with a properly tokenized design system and a proper documented source of truth, we could help designers and developers work more closely together. In theory we could eliminate handoff files completely from the workflow process. We could version software products based on token release. We could even control how a website looks without pushing any new code! The possibilities are limitless. So, the team is on a mission to build the best design token manager in the game, fueled by API integrations and powerful import/exports. But first we had to understand: what exactly is a design token? And that's why we're all here today.

More Than Just a Variable

When we first started, our understanding of a token starts where everyone else starts: a name, and a value. Together a name and a value form a token, and that was all of the information we were keeping track of in our first prototype versions. But as we started to see more possibilities within the interface, began having more conversations with the community, we realized a token is so much more than a variable. We began to understand each token as an entire brand decision encapsulated in a single object.

Once we developed this understanding, tokens in Arcade grew to be so much more than just a variable. We wanted to make sure a team knew the who's, the what's, the when's and why's behind a token. How was this decision made, and how did we get here? With this expanded approach, we developed our decision-context schema, which allows us to track the evolution and history of a token. We learned that the meta information that we store will unlock infinite possibilities and help provide self-authoring documentation about these tokens. Not only that, but it'll allow more robust exports from Arcade and enable better integrations with other design software and APIs.

The amount of data collected within a token is rapidly expanding.

With the amount of meta data we're keeping track of, including who created the token, timestamps, taxonomy, a description, and so much more, we're hoping this provides enough context for how a token is to get used. We want engineers and designers to be informed about the token they're using, and provide enough information to know the context a token should be used in. We think tokens should make it exceptionally clear for designers and developers how and where these tokens be used in a codebase.

What we understand to be a token is growing rapidly.

Token Tiers

It's important to note, however, that tokens are only as powerful as the engineers enable them to be. If a codebase is configured correctly, whether using a design system or not, entire suites of products can be driven by a single source of tokens. That's right, one file of tokens, or a single API call can drive millions of components across a hundred different interfaces. A properly tokenized design system can enable teams to work so fast while maintaining design consistency and produce some amazing work. The challenge here, is how do we set that up? How do we configure, architect, and name all of these tokens? What's the process for this? And how do we standardize it across the industry?

Within Arcade, we're trying to make this process as easy as possible for teams, whether it be a designer or engineer configuring tokens. But an interface can't do everything. It's our opinion that one of our biggest challenges as a community will be education regarding token configuration; enabling design systems to be driven by a single set of tokens. How do we inform both designers and engineers how to architect tokens at scale?

After talking to a bunch of industry teams and dogfooding of our own, we've learned that a tiered configuration is the best approach for tokens. Inspired by the Adobe Spectrum team's guide, our approach is very similar:

  • Tier one includes global tokens and contextual tokens. These are raw values, given an optional contextual name.
Example of Global Tokens
  • Tier two includes theme tokens, all values that you wish to be themeable. For us at Arcade, we're in the process of theming pretty much everything, from spacing to colors, to fonts and more.
Theme tokens example
  • Tier three is for component tokens and component specific values. I've seen some teams store these tokens close to the component, but we'd like to maintain control over all tokens at the highest level and that shouldn't be a problem with proper naming
Example usage of component tokens

With these three tiers in place, full control will be able to be maintained over every token. You maintain infinite flexibility with a defined hierarchy and structure. Each layer provides another opportunity to add more context and reign more control over the token. The theming layer provides an easy way to implement different visual styles.

Example of theming using the tiered tokens
You can see how easy it'd be to apply a dark mode theme, or an accessible spacious theme with the tiered token approach.

Conclusion

And that's pretty much all the new stuff for now! We talked about few more topics, some of which you can find in our other blog posts. If you have any questions or feedback regarding this stuff, feel free to reach out to us on Twitter @useArcade or me personally @MikeCarbone! Thanks for reading!

Enjoying these posts? Subscribe for more