GTC design tokens: a single 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.

A well-designed token structure lets a brand grow fast and stay consistent, while poor token decisions slow the product down and turn any UI and brand change into a painful process.

Design tokens are standardized design decisions that are necessary for consistent business growth. 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, no matter the type or size of the business.

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 without worrying about design drift.

This clear split of domains is especially 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 your product reuses in more than one place: a brand palette, a type scale, a spacing size sequence, or a set of motion easings. Each token type holds the full range of values for that one aspect of the design.

To structure design tokens effectively, we first need to identify the token types 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 keeps them organized and makes it easy to add new ones without the list getting out of hand.

With the token types defined, we can organize them into more detailed semantic groups—the layer where teams and agents can reason about how tokens relate to and depend on each other. The always-open question in the design system field is how to name those groups so they stay understandable 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). It has held up every time. The structure doesn't care what framework you're on, so it travels well between the companies I've built systems for and my own projects.

Grouping tokens this way is the whole point of the GTC model: it turns a flat list of tokens into a readable structure, a structure where every token has an obvious 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, the grouping itself 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, storing information on how everything looks in a given context: surfaces, icons, text, borders, and component visual states. Theme is the layer that shifts when that context changes, for example when switching from light to dark mode.

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 you attach the theme token to an element once, and it repaints itself the moment the mode changes.

Component tokens hold a component's structural values, storing information on how it's built and sized: spacing, gaps, font-size, line-height, radius, icon-size, and every other property that affects "how should this component work/resize".

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

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

Edge case—a structural value that has to change with the mode can route through Theme first. Font-weight is the common case: the same weight looks heavier on a dark background than on a light one, so the dark value drops a step to keep them reading the same. Robin Rendle walks through the technique in Dark mode and variable fonts.

Each component is a sub-folder inside the Component group, holding 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 just means selecting a different mode (medium to 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. 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 each token is named in the design system.

Each token name has two parts:

Each level narrows what token means—so the number of levels equals tokens'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 add a level of complexity 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 the unnecessary amount of 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 work as 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 mandatory level, and other levels never appear out of order. *But can be ignored if not present in 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.

That 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—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 tokens groups and taxonomy becomes disruptive to product teams and on enterprise-level it can quickly become unmanageable.