GTC design tokens: a source of truth for scalable design systems

Design tokens are the building blocks of every design system. But most token systems were built for a different era, and now that AI is in the workflow, their flaws pile up, making products harder to maintain and work with.

When a token system isn't structured well, every visual update and redesign ends up reinventing it, adding complexity, and turning every visual change into an abstraction problem.

GTC solves three problems every token system faces:

Design tokens are standardized design decisions. They're not just a technical choice, but a product decision that shapes how your product scales over time.

Design tokens let you make big transformations to a product's UI and propagate changes in an instant.

When people refer to a design token, they typically mean a design decision that unifies multiple UI elements across the product. To make that decision reusable, every token is built from two key elements:

Every token name is a unique identifier for a specific value. The same value can sit under more than one name, which lets tokens reference each other and form a hierarchy.

These references between tokens are called ‘token aliases’.

Aliases are what make tokens reusable. Instead of storing its own copy of a value, a token aliases another token, so the underlying value lives in exactly one place: a Global token. Change it there once, and every token that aliases it updates too.

Aliased this way, tokens form a hierarchy: a Global token holds the raw value at the base, and a Theme token on top aliases it to an element, like this:

Design tokenization is what allows large enterprise systems to preserve consistent UI across multiple domains and sub-products.

Design tokens create a strong contract between the product and design-system teams. The design system owns tokens, and tokens own styling, semantics, and connections to components, while feature teams can focus solely on business logic.

This clear split of domains is valuable during redesigns. Tokens help move to new designs faster, as any global UI change, such as style updates or component improvements, can be rolled out by updating specific token values.

A token type is a category of value that the product reuses in more than one place: a brand palette, a font scale, a spacing sequence, etc. Each token type holds the full range of values for that one aspect of the design.

To structure design tokens effectively, we need to identify the types of tokens our product will actually use. If our product won't need a particular type, it's better to leave it outside the system.

Grouping tokens by type makes it easy to add new tokens without the list getting out of hand.

With the token types defined, we can organize them into more detailed semantic groups. The always-open question in the design systems field is how to name those groups so tokens stay legible to both large teams and machines as the product grows.

Across every enterprise project I've worked on, I've narrowed this down to three groups: Global, Theme, and Component (GTC), which held up consistently every time. The model is framework agnostic, so it's possible to use it with any UI component library of your choice.

Grouping tokens this way turns a flat list of tokens into a readable semantics layer, a structure where every token has a home and purpose, and every change is easy to track.

In GTC, each value can be updated globally across domains, narrowed to a single theme, or isolated to a specific component, making it possible to push changes exactly as far as it needs to go.

If you've used Material Design's token classes, GTC grouping will feel familiar. Material's reference, system, and component tiers line up closely with Global, Theme, and Component. The core difference is in the naming and hierarchy. Material Design applies one rigid grammar to every token, so each name becomes a long, segmented chain, e.g.:

GTC avoids the rigid grammar. Every token belongs to a group: Global, Theme, or Component. But past that group, each name is free to take whatever best fits what the token expresses.

Names stay short where they can be and specific where they need to be. That's what keeps the system readable and easy to maintain, e.g.:

Global tokens (also called primitive tokens) include the full set of raw values sorted into types the rest of the system is built from. They're never applied to components directly. Instead, Theme and Component tokens reference them.

Inside the Global group, values are organized into subgroups, each covering one or more token types, for example:

Theme tokens hold the UI's visual modes: how everything looks in a given context, including surfaces, icons, text, borders, and component visual states. Theme is the layer that shifts when that context changes, for example when the user switches from light to dark mode.

The Theme group is where "how should this look right now" is decided.

Theme resolves by mode: light and dark are the two most common color-scheme modes, and a product can add more, such as brand or high-contrast modes.

A single theme token points to a different Global token in each mode, one Global for light, another for dark. The raw values still live in Global, so attached to an element once, it restyles itself on mode changes.

The Component group is where "how this component should be built" is decided.

Instead of storing their own raw values, component tokens link to the Global group for structural values like radius, size, motion, and typography.

Edge case: a token that changes with visual mode can route through Theme first. Font-weight, for example: the same weight looks heavier on a dark background than on a light one, so we can set it thinner in dark mode. Robin Rendle walks through this technique in Dark mode and variable fonts.

Each component is a sub-folder inside the Component group, with its own structural tokens across one or more size modes, just as a Theme token resolves across its modes. One token holds a value for each size, so resizing a component means selecting a different mode (medium or small).

Modes (or "contexts" in Material Design) are a token's ability to store multiple values and pick the right one based on the current UI conditions.

In practice, a mode is a property assigned to a token that tells it which value to use in a given context: dark mode, high-contrast mode like in Theme, or a size-specific mode like in the Component token group.

In GTC, modes are selected by scope, so you can change a mode for a single component or the whole page at once. A token can answer to more than one mode, for example, a brand theme and specific component size, which can be activated independently.

When a token includes a mode-specific value, it's applied automatically when that mode is active. For example, a color token with a dark-mode value becomes active the moment the interface switches from light to dark.

All GTC tokens follow a level-based naming convention: where each level of the name tells you one thing about the token's final value.

In production code, tokens can have different numbers of levels depending on how much they need to express. For example, let's take the global.color.base.0 token: global says which group it belongs to, color says which subgroup it sits in, and base.0 points to the exact value.

Global tokens stay short, as they hold primitive values, but Theme and Component tokens run longer, as they carry more specific design decisions and values:

A design token taxonomy is the set of rules that governs how tokens are named in the design system.

Each token name has two parts:

Each level narrows what the token means, so the number of levels equals token's specificity. A good taxonomy comes down to one best practice: balance clarity against simplicity.

GTC uses the minimum number of levels required to describe a token, and adds a level only when removing it would leave the token ambiguous.

The opposite is a linear grammar, where one fixed chain is applied to every token, so each name carries unnecessary levels, whether it needs them or not.

Overly specific names grow longer and pull more rules in behind them, which is what makes a linear approach much harder to maintain over time. A single button hover color ends up spelling out levels that say the same thing:

The way to hold that balance in the GTC model is a lightweight set of rules for identifying each token level. The taxonomy levels below are guidelines for naming and arranging those levels.

Every name follows one fixed order: Group, then any of Element, Classifier, Identifier, and State. Only Group is a mandatory level, and other levels never appear out of order. They can be ignored if not present in a token's intent.

On their own, design tokens are just words. The taxonomy is what turns them into a shared language: each token gets meaning in the UI, and people and AI agents can make better design decisions and write better code.

This shared language works only when the names stay consistent. When each level signals what a token is for, designers and developers can find the token they need instead of adding a near-duplicate that clogs the set. Consistency matters more, the larger the system grows.

While the naming convention can and should be tailored to a team's workflow, it must be defined at the foundation. Once a token set grows, changing token groups and taxonomy becomes disruptive to product teams and at enterprise level it can quickly become unmanageable.