Genesys design tokens library

Created a design token library based on JSON which generates main formats across CSS, JS, SASS, and Figma — improving radically the consistency.

ThemeStyle DictionaryCSSSASSJSJSON

Github repository SB documentation

My Role

Co-creation of a design token system in JSON that synced typography, colors, spacing, and other visual styles across Figma, web, and code. Led the token structure definition, guiding set up automation with Style Dictionary, created comprehensive documentation, and established a smooth workflow for designers and developers to collaborate efficiently.

Overview

Once the design system was launched, one thing became immediately clear: our designs looked great in Figma, but translating them into code was messy. Colors, typography, and spacing were implemented differently across platforms, which slowed development and caused frequent mismatches.

To solve this, I decided to build a design token library with the invaluable help of a highly enthusiastic frontend developer. Using a structured JSON as the foundation, the idea was simple: define all visual styles once and let automation handle the rest. With Style Dictionary, we generated CSS, SASS, JS, and even Figma variables directly from a single source, ensuring our brand looked consistent everywhere.

The Challenge

Before the tokens library, any design outside the UI components library (which was already integrated with tokens) required developers to manually copy values and translate them into code. Naturally, this introduced small inconsistencies along the way. It was time-consuming, error-prone, and frustrating for everyone involved.

I realized we needed a single source of truth, not just a document, but a living system where any change would ripple across every platform automatically. The challenge was balancing flexibility for designers with reliability for developers, creating a system that worked seamlessly across design tools and codebases.

A complete app powered by design tokensIn the 'Data Search' section, every color, font, and spacing value is driven by the design token system, so no manual styling required.

Process & Collaboration

We built a living documentation site in Storybook, where every design token was neatly organized, previewed, and explained. It included an advanced searchable table allowing developers to filter by format, tier, category, or scheme, and whenever possible, each token previewed its actual appearance.

Development Approach

The first step was defining the structure of our tokens in JSON. I grouped them into categories like color, typography, spacing, and elevation, thinking about both global and component-level scopes. The goal was clarity: anyone on the team should understand and use the tokens without confusion.

Semantics and naming conventions were crucial for usability. We defined three token tiers: global, alias, and component:

Global: the raw value without semantic meaning: global-color-palette-ui-error-03.
Alias: global values reused with semantic naming, not tied to a specific component: alias-color-background-feedback-error-strong.
Component: alias values reused and renamed for a specific component context: cmp-button-color-background-error-disabled.

Then came automation. Using Style Dictionary, we transformed the JSON source into multiple formats: CSS custom properties, SASS variables, JS constants, and Figma variables. Updates became effortless: changing a single value automatically propagated across platforms, saving time for both designers and developers.

The project was split into two separate libraries:

theme-generator: the core JSON definitions and scripts for creating a CLI used to generate themes.
theme-devo: the generated theme implementation for Devo.

Main naming conventionsThere is a clear and logical naming for defining tokens: always the same structure and order of each piece of the whole name: namespace - object - base - modifier.

Category valuesThis is an scheme with the available properties defined for each category: color - background, text, border, fill... etc. as instance.

Different types namingThese are clear examples fo how the name of the tokens are structured: namespace (alias and cmp type) - object (group, component and element) - base (category, concept and property) - modifier (variant and scale).

Naming orderThe order of these blocks is always the same. What changes is which blocks are used together within each token. Some naming blocks are mutually exclusive. For instance, if a token includes a group or component block (with or without an element), it can't include a concept block at the same time. This rule keeps naming consistent, avoids conflicts, and makes tokens easier to maintain as the system grows.

Naming by formatThe tokens are defined in JSON using camelCase for multi-word names. They are then exported to SASS (lowercase, prefixed with '$', and separated by hyphens), CSS (same format but prefixed with '--'), and JS (as object values accessed with dot notation).

Impact & Outcomes

Single source of truth

The impact was immediate: design and development finally spoke the same language. A single change in the token file updated web styles, React components, and Figma variables simultaneously.

Cohesion

Beyond efficiency, the library created a stronger sense of cohesion across products. The interface now feels unified.

Scalability

Scaling the design systembecame easier than ever as new features and platforms were added.

Storybook documentation for tokensThe Storybook documentation is built around a searchable table that allows designers and developers to filter tokens by tier, schema, format, and more. Whenever possible, it also provides live previews, making it easy for teams to quickly find and understand the tokens they need.

Different outputs for tokensThese are four different output format examples: CSS, JS, JSON and SASS. The original source is in JSON, but Style Dictionay also generates a JSON output with a info set of every token.

Learnings & Next Steps

Working on this project showed me how powerful it is to treat design as data. By structuring our styles as tokens, we bridged the gap between creative decisions and technical implementation, saving time and reducing errors. I also learned that clear naming and documentation are essential, because a system is only as good as it is understandable.

Next, we're developing an interface where designers can simply input a few values (brand colors, typography, and spacing scales) and automatically generate a new theme. This will make customization faster, more consistent, and scalable, especially for client-specific adaptations.