A design system's strength lies in its ability to translate abstract ideas into concrete code. Hard-coding values like #007bff or 16px directly into components creates a brittle system. When a brand color changes, you're left searching and replacing across dozens of files. This is not scalable.

Design tokens solve this by creating a shared language. They are named entities that store visual design attributes. Instead of using a raw hex code, you use a token like --color-brand-primary. This simple act of abstraction is transformative. It separates the raw value (the what) from its intended purpose (the why).

Effective token naming is semantic. It describes the token's role, not its value. Naming a color --blue-500 is useful, but naming it --color-interactive-default is powerful. The first describes a color; the second describes a job that needs doing.

A robust token system isn't flat. It has layers of abstraction, each serving a specific purpose. We can structure this as a three-tiered system: Global, Alias, and Component tokens. This hierarchy provides both flexibility and control, making the system easy to maintain and theme.

Global Tokens are the primitive values, the absolute source of truth. They are context-agnostic and often generated directly from a design tool. They use literal names, like --blue-500 or --font-size-100. You should rarely, if ever, apply global tokens directly to a component.

Alias Tokens are the next layer. They consume global tokens and give them a specific purpose or context. This is where the semantic meaning comes to life. An alias token like --color-background-primary might point to var(--gray-100) in a light theme but var(--gray-900) in a dark theme. Aliases are the key to themeability. They bridge the gap between your raw color palette and its application in the UI.

Component Tokens are the most specific layer. These tokens are scoped to a single component and define its properties. They almost always consume alias tokens. This allows you to make a component-specific change without affecting the global aliases. For example, you might decide a specific button needs a different background color, so you'd override its component token.

Consistency comes from systems, not just values. Instead of picking arbitrary numbers for spacing and font sizes, we should define them using a predictable, mathematical scale. This ensures visual harmony and rhythm throughout the user interface.

For spacing, a geometric scale is common. You start with a base unit and multiply it to create larger values. A 4px base unit is a popular choice, as it provides granular control and scales nicely on most displays.

For typography, we can achieve responsive and scalable text without media queries by using the CSS clamp() function. This function takes three arguments: a minimum value, a preferred value (often using viewport units), and a maximum value. This creates fluid typography that scales smoothly with the viewport size, but never becomes too small or too large.

Color systems also benefit from logical naming. Instead of just naming colors, we can create a system based on their role. This often involves defining background colors (sometimes called holes), accents for interactive elements, and states like hover, focus, and disabled. This semantic approach makes it clear how to apply colors correctly.

With these structured systems for naming and scaling, you create a design system that is more than just a collection of styles. You build a predictable, maintainable, and themeable foundation that enables designers and developers to build cohesive experiences efficiently.