Design tokens are key parts of a design system. Managing a Design System without even basic Design Tokens is nearly impossible. Without them, you'd constantly need to make decisions, and within a team or company, these would frequently be changed and overwritten by others.

A Design Token is a standard decision everyone can rely on. For example, the Design Token "Red" might store a value like #EE4B2B, which is different from #FF0000 even though they're both red. The idea is that with the Design Token "Red," we all know it refers to #EE4B2B, and if it's changed to another shade of red in the future, everything labeled with the Design Token "Red" will automatically update. This keeps the work consistent and coherent, allowing for theming and scalability.

A good definition of Design Tokens:

Design tokens are named entities that store raw, indivisible design values like colors or sizes. They are the fundamental components of a design system. Stored in a technology-agnostic format, they can be adapted for use on any platform, replacing hard-coded values.

Design Token Tiers

Tokens are usually divided into different levels, with each level serving specific purposes and adding unique capabilities to the design system.

Tier 1 — <Foundational/Global/Core/Fundamental> Tokens

It stores basic values associated with context-free names and mainly determines the final product's appearance by defining all the values that can be used directly.

Tier 2 — <Alias/Semantic/Theme> Tokens

Inherits Tier 1 tokens to clearly explain their intended use and purpose in specific contexts, making them commonly used across various projects and products. They represent choices or intentions that show up in multiple places.

Tier 3 — <Component> Tokens

Often inherits Tier 2 tokens and is linked to specific component values (or overrides), enabling teams to be as precise as possible with their components.

Differences between Primitive Tokens, Semantic Tokens and Component Tokens

Primitive Design Tokens:

• Foundational Elements: Primitive tokens are the fundamental building blocks of a design system, representing the core design attributes like colors, typography, spacing, shadows, and other basic design properties.

• Raw Values: These tokens store raw, indivisible design values. For example, a primitive token might define a color as "red" = "#FF2800" or a font size as "font-size-large" = "24px".

• Core Consistency: Primitive tokens ensure consistency across the design system by standardizing basic visual properties used throughout the project.

Semantic Design Tokens:

• Layer of Abstraction: Semantic tokens add a level of abstraction to primitive tokens by describing design properties in more meaningful or contextual terms, often related to their use or size. For example, "border-medium" could be a semantic token that refers to a specific border width defined by a primitive token.

• Contextual Naming: These tokens often incorporate terms like "small," "medium," "large," or "primary," "secondary," to indicate relative sizes, weights, or importance. For example, "spacing-large" might reference a specific spacing value from the primitive tokens.

• Adaptability and Theming: Semantic tokens make it easier to apply consistent styles across different themes or modes (like light and dark modes) without changing the underlying primitive values. For example, "background-default" might refer to different colors in different themes but still remain consistent in meaning.

• Enhanced Communication: By using terms that describe their role or size, semantic tokens help improve communication between designers and developers, making the design system easier to understand and work with.

Component Tokens:

• Component-Specific Design: Component tokens are directly tied to specific UI components, defining design properties specific to those components, such as buttons, cards, modals, etc. For example, a button might have component tokens like "button-border-radius" or "button-padding".

• Customization and Flexibility: These tokens allow components to be easily customized or themed while maintaining consistent design principles. For example, different button styles (primary, secondary, danger) can all be managed through component tokens.

• Consistency within Components: Component tokens ensure that all instances of a particular component maintain visual consistency, even as design changes are made. This helps in managing complex design systems where a single component might be used in various contexts.

• Integration with Primitive and Semantic Tokens: Component tokens often reference primitive and semantic tokens to ensure that the design system remains consistent at every level. For example, a "button-background"component token might reference the "primary-color" semantic token, which in turn references a primitive color value.

Adapting Design Tokens to your Design System

Not everything we've discussed so far is universally true or applicable. Design Tokens vary greatly depending on the product, and not all Design Systems work for every situation. It's crucial to tailor the tokens to fit the project's specific needs and make necessary adjustments for the best results.

For instance, in some cases, you might find that the line between Semantic and Component tokens is blurred, and the distinction between Foundation and Semantic can differ too. The proposed Tier levels might not always be consistent across the board. Some products may have a wide range of Design Tokens dedicated to a single component, while others might rely solely on the Foundation and Semantic levels.

That said, having too many Tokens can complicate the system and make it hard to manage. But be careful not to trim them down too much, as that could limit your ability to customize the design system effectively.