Tokenize it
How little bits of code can improve the design process
Does this sound familiar?
A seemingly-straightforward digital project, like a website redesign or brand update, takes longer than expected and you’re not quite sure why?
I think most of us working in tech have been there. Whatever the cause, or combination of causes, maybe you’re like me, and thought “there has to be a better way.”
So you rally the team, have a retro, focus on learning, and try to iterate the process.
But progress is gradual and can feel too slow as you scan the horizon for what’s next.
When the next thing comes along, a rising wave in the distance, you turn and start paddling out to catch it.
The tools at your disposal at that moment — your surfboard, strong shoulders for swimming, knowledge of how the wave breaks, solid intuition and a clear head from years of experience — determine how likely you are to catch and ride the wave, or to wipe out.
Many organizations are now recognizing the value of design and research-based user experience, and spending a lot of time improving their design toolkit to better serve their customers.
The passion of designers and developers for design systems — synchronized UI libraries with shared design and code assets — has led to a proliferation of systems in recent years, and suggests a new path for componentizing design to ultimately make it more flexible and equip teams with the right tools at the right times.
Tokens
When you hear the word ‘token,’ you may think of a round plastic object like the chips at a casino. Maybe you’ve also heard of tokens in the context of computing, data security, authentication, or cryptocurrency.
The Oxford dictionary entry for tokens includes the following definitions:
A thing serving as a visible or tangible representation of a fact, quality, feeling, etc. E.g. ‘I wanted to offer you a small token of my appreciation’
A voucher that can be exchanged for goods or services, typically one given as a gift or forming part of a promotional offer.
(Computing) A sequence of bits passed continuously between nodes in a fixed order and enabling a node to transmit information.
What all these definitions have in common is that a token is some thing / object / code that represents a specific asset, and facilitates an exchange for something of pre-established value.
What does this have to do with design?
Stay with me, I’ll explain.
Key-value pairs
Tokens at their essence are key-value pairs, a fundamental way to represent data in computing systems and applications.
The open-ended data structure of this pairing allows for future extension without modifying existing code or data. The key remains constant in the code, while the value can be changed. This introduces numerous opportunities to automate and efficiently enable scale.
Tokens in design systems
Design systems are emerging as a way for organizations to provide a visually consistent and cohesive user experience across a large number of digital properties.
I’m currently heading up the design systems team at REI, and have found myself immersed in the world of tokens — though, a very specific flavor of tokens that help maintain and scale the co-op’s visual language.
Pioneered by early design systems going back to 2014, and popularized by the Lightning Design System team at Salesforce, design tokens have become a key deliverable from many systems. Tools such as Amazon’s Style Dictionary help with the heavy lifting to transform style properties and assets into platform-specific deliverables, so the same tokens can be used on the web as well as native iOS and Android apps.
Inspired by how other design systems are using tokens to support multiple web apps and native applications that need to feel and look the same, our Cedar Design System recently released a V1 set of design tokens for our internal digital teams and external partners.
Since the initial launch of our system last August, our subsequent releases have primarily focused on components — the core UI elements that we see the most reuse of across teams. Buttons, links, CTAs, breadcrumbs, inputs, and the like.
While driving adoption of the system and talking to our users, we saw a lot of appetite for more flexibility from the system parts to create new experiences and custom components that were on-brand, and that could be extended to support a redesign of our mobile apps.
How Cedar defines tokens
Design tokens store the visual design attributes that define the foundation of REI’s visual language, including color, typography, and spacing.
Picture it this way: If components are atoms that function as the basic building blocks, tokens are the sub-atomic particles used to build components.
Instead of using hard-coded values, such as hex values for colors or pixel values for spacing, tokens are key-value pairs that represent the design decisions encapsulated in our visual language.
For example, in Cedar:
Key: value;
cdr-text-primary-lightmode: #292929;
- The key name defines the usage or how to apply the value to a specific context, such as using text on a light background
- The key stores visual design attributes
- The key replaces hard-coded values, such as hex values for color or pixel values for spacing
- Contract of intent will not change when a variable value is updated over time
What we’ve learned
The design systems team uses tokens to build components and has found them to be crucial elements to scale our visual language in a maintainable way.
We know that Cedar does not have all of the components for everyone’s unique needs, and never will. Teams and projects have custom needs, and the aim of the system is to support only the patterns and UI elements with the greatest likelihood of reusability across at least 3 different teams.
By making tokens available to all digital teams, we can enable them to create custom experiences that are aligned to current visual standards when a component does not (or will not) exist in the design system.
Our mobile apps and third-party partners that are unable to use our standard Vue-based components will also be able to use tokens to deliver a consistent brand UI that’s easier to maintain over time.
When there’s an update to our brand colors or typography, tokens can help streamline the redesign process. Cedar will update our tokens to reflect the new values and roll out the updates to all our consuming teams, without needing them to change any code. Efficiency win!
The nuances of naming
Early on, it was clear to us that it was essential to define semantic names for tokens that describe what they were used for, and would not change over time.
Since the compounding benefits of tokens come when the code (key) doesn’t have to be changed to support the underlying value changing, it would be crucial to get the naming right.
This was more complex than we initially realized. Sometimes, our team meetings talking about token naming patterns felt endlessly puzzling, like an episode of Game of Thrones with so many characters you can’t keep the story straight.
And just when we thought we had it, we learned that iOS and Android had certain naming patterns and we went back to rework the token names so they could be as close as possible for web and native applications.
Ultimately, through the combined efforts of our designers and developers, we settled on a naming structure with the appropriate balance of structure and flexibility.
Everything should be made as simple as possible, but not simpler. – Albert Einstein
What’s next
While the Cedar team spent a lot of time and consideration to identify and name the tokens supported in our V1 release, we don’t know all of the tokens that we’ll need in the future or to support each different team’s needs.
To learn that, we plan to do collaborative discovery with designers across different product teams, focused on different foundational attributes (starting with type and color) to develop a shared understanding of needs and usage.
In addition to the Cedar token repo, we’ve also established a shared token repo where teams can create and add new tokens that they’re using on a project. As we see shared tokens used across other teams and the need for those tokens validated, we plan to pull those into Cedar as well — so we can continue to grow and evolve our system together, and paddle out more confidently to catch the next wave.