Design Tokens: Unlocking the Power of a Unified Design Language

As companies like Kimberly-Clark continue to expand and evolve, the need for a streamlined and efficient design process becomes increasingly important. With brands in 175 countries, maintaining a consistent look and feel across all products is crucial for success. However, as any designer or developer knows, achieving that consistency can be a challenge.

To address these challenges, we at Kimberly-Clark decided to implement a design system in Figma, complete with cataloged components, patterns, and design tokens. The use of design tokens in particular has been instrumental in improving our workflow and addressing issues such as conflicting priorities and time-consuming QA processes.

What are Design tokens?

In simple terms, they are the atomic units of a design system — they represent visual elements such as colors, typography, and spacing. By using design tokens, we are able to establish a clear and consistent visual identity for our products and brands. This not only makes our job more efficient, but it also reduces confusion and inconsistency in the design process

Design tokens can be stored in a central repository, such as a JSON file. This allows them to be easily accessed and shared by designers and developers, ensuring that everyone is working with the same set of design elements.

At Kimberly-Clark, Figma is the one source of truth for component Library, brand styles, design tokens, documentation, page template

Design tokens can be used in a variety of ways, including:

• Defining colors: Design tokens can be used to define a color palette for a product or brand. This includes primary and secondary colors, as well as shades and tints of those colors.
• Defining typography: Design tokens can be used to define the font family, font size, line height, and other typographic styles for a product or brand.
• Defining spacing: Design tokens can be used to define the spacing between elements, such as the padding and margin around buttons or the space between lines of text.
• Defining other design elements: Design tokens can also be used to define other design elements, such as border-radius, shadow styles, and animation timings.

Design tokens Naming Convention

Semantics and naming conventions are important aspects of design tokens, as they provide a way to clearly communicate the meaning and purpose of each token. Semantics refers to the meaning of a design element, while naming conventions provide a standardized way to name and refer to those elements.

There are several approaches to naming design tokens, and here are some of the suggestions for considering before you start writing design token naming conventions:

Compatibility: Consider whether the naming convention is compatible with your team’s workflow and tools. For example, if your team is already using a particular naming convention for CSS classes, you may want to choose a design token naming convention that is compatible with that convention.

Scalability: Choose a naming convention that is scalable and can grow with your design system. As your design system evolves, you will want to be able to add new design tokens and update existing ones in a consistent and organized way.

Intuitiveness: Choose a naming convention that is intuitive and easy to understand for your team. A clear and descriptive naming syntax can make it easier for designers and developers to understand the purpose and use of each design token.

Consistency: Consistency is key when working with design tokens. Choose a naming convention that is consistent and easy to follow, and make sure that all team members are aware of and follow the convention.

At Kimberly-Clark, we preferred using the Amazon dictionary style for design token semantics because it offers a clear and intuitive structure for organizing and naming design variables. This style is effective because it utilizes a hierarchical structure to arrange design tokens, which helps to illustrate the connections between various design elements. For instance, design tokens for colors might be placed in a “color” category, while tokens for fonts could be placed in a “font” category. This type of organization helps to make the design system more orderly and simpler to navigate.

Divide your Design tokens into levels

I recommend dividing tokens into levels to provide a clear hierarchy and to make the design system more organized and easier to understand. We divided into three levels which we are referred to as raw, alias, and defined tokens:

1. Raw tokens: The base level token is called raw token and it includes the most fundamental design elements, such as colors, typography, and spacing. These design elements are typically used throughout the entire design system and are considered to be the building blocks upon which all other design elements are based.
2. Alias tokens: The Alias level includes design elements that are derived from the raw level elements, such as buttons, forms, and layout grids. These design elements are more specific and are used to create the basic structure of the user interface.
3. Defined tokens: The defined level includes design elements that are specific to a particular product or feature, such as a homepage layout or a login form. These design elements are built using the alias and raw level elements and are used to create the final visual appearance of the product.

Custom Design Token Tool

Figma may not provide native support for design tokens is that design tokens are often used to manage design elements that are used across multiple projects or products, rather than just within a single project. This may require a more centralized and standalone tool for managing design tokens, rather than a design tool like Figma that is focused on individual projects. There are many tools and plugins out there to quickly get design tokens. However, there are a few potential issues to consider when using a design token management tool that already existed:

• Dependency: Using a design token management tool can create a dependency on that tool, which can make it more difficult to migrate to a different tool or process in the future.
• Complexity: Some design token management tools can be complex to set up and use, which can be challenging for teams that are new to using design tokens.
• Overhead: Using a design token management tool can add an additional layer of complexity and overhead to the design and development process, which can be time-consuming and may not be necessary for smaller or simpler projects.
• Limitations: Gets detached from Figma native styles and most let you export in JSON ONLY then the developer manually has to convert it to the site core environment.

Therefore, we made the decision to develop a custom design token plugin for Figma by partnering up with the external team. Using a custom design token plugin within Figma offered us a number of benefits, such as:

1. Customization: Building your own design token plugin allows you to tailor the tool to your specific needs and requirements. Such as the ability to import and export design tokens in various file formats.
2. Control: By building your own plugin, you have more control over how it works and how it integrates with your existing tools and processes. This can be helpful if you want to ensure that the plugin fits seamlessly into your workflow. such as easy to export in the preferred format for developers (.Scss, JSON, etc)
3. Ownership: Creating your own plugin gives you ownership over the tool, which can be beneficial if you want to make changes or updates to it over time. Version control and history tracking to enable rollbacks and changes to design tokens
4. Automation: Increases design automation and provides a quick, simple approach for developers to assign defined tokens, raw tokens, and pre-linked tokens from the component library. You can also take Figma to next level by Integration it with development tools, such as web-based tools.

Kimberly Clark’s Workflow

In-house design token plugin can be a useful investment for organizations that want to have more control and customization over their design system tools. However, it is important to carefully consider the resources and expertise that will be required to build and maintain the plugin, as well as the potential benefits it will provide.

Organizing Design Tokens in the Development Environment

At Kimberly-Clark, our approach to organizing design tokens follows a component-based folder structure. This structure ensures that all relevant design tokens and CSS are kept together for each component. This makes it easy for team members to understand the structure and naming conventions used for the design tokens and CSS files, and also makes it easy to find and maintain the design-related files for a specific component. When working with design tokens in the development environment, it’s important to keep them organized in a way that makes them easy to find and use. Here are a few suggestions for how to organize the component-based folders:

1. Create a Raw design token file that includes all the raw design tokens that are used across the entire website. This file should be referenced by all the component-specific files to ensure consistency.
2. Create a subfolder for each component, such as “header”, “footer”, “banner”, etc.
3. Within each component subfolder, include all the other levels of design tokens files such as alias tokens and defined tokens.
4. Also include the CSS file and HTML file specific to that component within the same subfolder. This will keep all the design-related files for a component together, making it easy to find and maintain.
5. Use a consistent naming convention for the files within each component subfolder. For example, name the CSS file “header.css” and the design token file “header-tokens.scss”
6. Make sure to add comments or documentation in the root folder to explain the structure and naming conventions used for the design tokens and CSS files. This will help other team members understand how the design tokens are organized and where to find the tokens they need.

Kimberly-Clark follows a component-based folder structure to organize design tokens and CSS files, keeping all relevant files together for each component makes it easy for team members to understand the structure and naming conventions and to find and maintain design-related files.

Don’t add too much unnecessary fluff

One limitation of design tokens is that they can become unwieldy if there are too many of them. It’s important to strike a balance between having enough tokens to cover all the necessary design elements, while also keeping the number of tokens to a manageable level. It may also be necessary to revisit and update your design tokens periodically to ensure that they are still relevant and useful.

Summing Up

Overall, the implementation of a design system and the use of design tokens at Kimberly-Clark has greatly improved our design and development process. It has brought about a change in the culture within the organization and has made our job more efficient and fast. As the digital landscape continues to evolve, it is crucial for companies to stay competitive by utilizing tools and processes like design systems to meet the constantly changing needs of their users.

More to come, as we continue to improve and evolve our design system. Up next, we’ll be implementing a headless design system and aligning our design tokens for even greater consistency and efficiency.

Thank you for reading and stay tuned for updates on our journey toward a best-in-class design system!