Since implementing their design system, the Habits team has seen more consistency in designs and no longer debates endlessly over which standards to use.

However, the Habits app is evolving and growing.

After discovering that their users track their habits before bed, the team wants to add a dark theme to ease tired eyes.

While the spatial system has sped up the design process and solved alignment issues, the team struggles to keep track of which border radius and spacing values to use.

This has led to an unpredictable and inconsistent user experience.

And, they're adding new teammates and features and want a more efficient way to manage changes and improve accuracy during the handoff process.

Kai has been learning about design tokens and believes that this could be the next step in supporting scalability of the Habits design system.

The benefits of design tokens are very similar to that of design systems.

They're a source of truth that maintains consistency between design and code.

They improve management of a scaling design system.

And they remove the guesswork when building products and help you build more efficiently.

But what exactly are design tokens?

How might this help the Habits team?

Design tokens are a method for managing design properties and values across a design system.

Each token stores a piece of information, such as color, sizing, spacing, font, animations, and so on.

To make them easier to refer to, each token also gets a name.

The tokens can be reused across your designs and become a source of truth and shared language between design and code.

For example, Kai recently handed a design file to a developer that contained spacing values of 25 points.

However, the Habits codebase uses an 8-point spatial system.

The developer assumed this was intentional and updated the codebase with the new designs.

Oops!

Kai actually meant to have spacing values of 24 points, but their file was set up incorrectly.

If the team used tokens, the design file would have included information on which spacing token to use.

The spacing token would point to a value that's already confirmed to be correct, preventing errors and ambiguity.

In addition to having a reliable source of truth, using tokens means that updating our designs and design system becomes faster and more efficient.

For example, say the Habits team has this color token being used in different areas of the product.

If they changed the value of this color token, then every asset using the token will change too.

This can be useful like when changing a color system for a product rebrand.

However, what if they only wanted the values of some assets to change?

Currently, they'd have to remap these values one by one to a different token.

This isn't a problem if only a few assets need updating, but if many assets had to be updated, the Habits team would need a lot more time and resources.

This is where aliasing comes in.

Aliasing allows any token to reference or take on the value of another token.

If a token changes, then any token referencing it will update as well.

But how does this solve the Habits team problem?

Well, aliasing lets you neatly organize tokens into categories, subcategories, and so on.

The categories communicate how a token is used.

If Habits had their tokens set up correctly, they'd be able to quickly update any category and all associated tokens downstream would get updated without unintentionally affecting others.

There's no limit to how far a series of token references can go.

And no limit to how many times a single token can be referenced, allowing us to create complex design token structures.

Keep in mind aliasing isn't always necessary, especially for assets like fonts and animations.

After realizing the benefits, the Habits team decided to implement design tokens in their system.

Before they jump in, they want to understand how tokens are organized.

The most common structure of design tokens starts with the foundation of values called primitive tokens.

From there, you can build on top of your foundation with semantic tokens and component-specific tokens.

Each type communicates a what, how, and where about the token.

Let's take a closer look at each one, starting with our foundation.

Primitive tokens tell us what properties and values exist within our designs.

Also known as global tokens, they define every value in a property system.

For example, primitive color tokens would include every color used in the app and its brand, while primitive spacing tokens would include all padding, margin, and spacing between values.

Note that primitive tokens are reference only.

They are the foundation for other tokens to build from but are never applied directly in designs.

Semantic tokens, however, can be applied to designs.

Semantic tokens gives us context on the how the token should be used.

As no ted in lesson 2, assets with semantic names convey meaning, purpose, and how and where the asset should be used.

For example, the token surfaced brand contrast references a primitive token called pink 400.

It takes on whatever value pink 400 is set to.

Surface tells us that it should be used for an object's background color.

Brand tells us that the color is central to the app's identity.

And contrast tells us that this color is saturated and should be used to grab a user's attention.

Lastly, we have component-specific tokens, which provide us even more specificity on usage by telling us where a token is used.

And yep, they're used directly in designs too.

Say we have a set of buttons, primary and secondary, each with a state, default, hover, and inactive.

We could create a token for each one.

Button primary, for example, could reference surface brand contrast, since primary buttons should grab a user's attention.

The token for this could look something like button, primary, background, default.

The rest of the button's tokens would follow the same format, asset, type, property, state.

This level of tokens is detailed and more might not be necessary for everyone.

Design token structures should always begin with the foundation of primitive tokens.

Beyond that is entirely up to the unique needs of your system and organization.

You might only need semantic tokens or component-specific tokens added on.

You might need both in any order that you need.

They could be on the same level.

You might even want to have multiple levels of each type.

Whatever the format, take the time to thoughtfully plan what your token structure will look like.

This will save hassle in the long run, as any future restructures could require significant time and effort.

Now that we've gotten a better grasp on design tokens, let's check back in with the Habits team.

They decided to set up both semantic and component-specific tokens on the same level.

Since their design system already lives in Figma, they can use two key Figma features to implement their tokens, styles and variables.

Before we continue, check out our resources on styles and variables to get an understanding of how they work.

You might be wondering, why should the Habits team use both styles and variables?

Variables can support complex token structures because they can be used to define other variables and styles.

They can also support multiple modes for theming, scoping for specifically where a variable can be used, and code syntax for a better handoff experience.

Meanwhile, styles can support color gradients and composite values, like multiple fills or multiple shadow effects.

For many, implementing design tokens means a combination of styles and variables.

To get more insight on the difference between styles and variables, check out the article linked below.

Kai is interested in diving into migrating colors first.

If you followed along in lesson 3, you'll know that the Habits app color system is connected to color styles, each organized by their purpose or usage.

The Habits team decided to migrate all of their color styles to variables except for one gradient, which they'll keep as a style since variables can't capture gradients.

They create a new variables collection called Primitives for their primitive tokens and copy each color value over.

Each color variable is organized by their base color.

Within each base color, a ramp is created based on their tint and shade using a numbering system.

The more white a base color contains, the lower its number.

The more black it contains, the higher the number.

Tip!

To prevent primitive tokens from being used directly in designs, you can scope and hide them from getting published to team libraries.

From the Primitives collection, select all the variables, right-click, and choose Edit Variables.

From the Edit modal, uncheck the Show in all supported properties box and check the Hide from publishing box.

Next, they want to direct how and where the colors can be used, so they create a second variables collection called Tokens for their semantic and component-specific tokens.

The team conducted an audit to document every color used in the product and identified a few areas that use color.

Surface, Button, Text, Border, and Icon.

Within each area, they further identified color categories like Brand, Toast, User Colors, and more.

From there, they established tokens within each category and gave them names that communicate how or where the color can be used.

For example, a semantic token might include the word Primary to communicate its use on the most common elements or actions on a page.

Secondary, on the other hand, are for less common elements.

After creating these tokens, they organize them into variable groups based on their categories and apply them to their designs.

Now that our color primitives and semantic tokens are set up, how might they approach Dark Mode?

Remember that every semantic and component-specific token is assigned a job and communicates a function.

To add a Dark Mode or any other theme, you need to create a separate set of tokens.

Within this set, they can change any aliases or references as needed by connecting them to different tokens.

In Figma Design, the Habits team is able to account for a Dark Mode theme through variable modes.

They create a new mode in the tokens collection and update references to variables in the primitives collection as needed.

And that's it!

No need to change the names of tokens since they already communicate information on how and where they're used.

Changing a design to Dark Mode can be quickly done from the right-side bar.

The Habits team is all done setting up their color tokens, so they tackle their spatial system using number variables next.

We cover creating number variables for spatial systems more in our Intro to Variables tutorial, so be sure to check it out.

Tips for Naming Tokens If you're ready to set up tokens for your design system, here's a few tips to help you with naming.

Make sure tokens are easy to understand.

Creating language-neutral names makes them approachable across different teams.

You may want to factor in people from different countries as well.

Use full words instead of abbreviations.

Abbreviations can be unclear and open to interpretation.

Be consistent with prefixes.

For example, token names for background colors should start with background instead of appearing in a different part of the name.

Use single or plural names based on the context for which they're being used.

If you have multiple products or brands, avoid using the brand's name in a token.

Instead, choose a more generic name so that tokens can be used in broader contexts.

Future-proof tokens by anticipating potential growth of your design system.

Token names should be able to accommodate new additions and modifications without causing confusion.

Now that the tokens are set up to go, Kai and the Habits team are looking forward to building Dark Mode for their users and experiencing the efficiency that this shared language provides.

Are you ready to dive even deeper into design tokens and variables?

Check out our resources below or let us know what you want to learn about next.

And be sure to like and subscribe to keep up to date with the latest product and community news.

We'll see you in the next one.