You already know how to build components and organize a UI kit. But a truly scalable design system is more than a collection of static assets. It's a living architecture, a 'Single Source of Truth' that mirrors the logic of production code. The goal is to move from designing what something looks like to defining what it is.

This shift requires thinking like an engineer. Instead of hard-coding a color value into a button, you create a system of references. This architectural approach, built on design tokens, is what allows a system to scale across dozens of products and platforms without breaking.

Design tokens are the fundamental building blocks of a modern design system. They are named entities that store design attributes. Rather than thinking in disconnected hex codes or pixel values, you think in variables. This system is typically built with two layers of abstraction: primitives and semantic tokens.

This two-tiered system is incredibly powerful. Designers work with meaningful semantic tokens in Figma, while the underlying primitives can be changed without breaking the design's intent.

In Figma, this entire structure is managed using Variables. You create a collection for your primitives (e.g., 'Brand Primitives') and another for your semantic tokens (e.g., 'Global Tokens'). The semantic tokens in the 'Global Tokens' collection will reference the values in your 'Brand Primitives' collection. This creates a clear, maintainable link between your raw values and their application.

The true power of this token architecture becomes clear when you need to support multiple themes, like Light and Dark mode, or different information densities. Because your components use semantic tokens, you don't need to create separate component libraries for each theme. Instead, you just create new modes in your Figma Variables collection.

A mode is a different set of values for your tokens. For instance, in your 'Global Tokens' collection, you can have a 'Light' mode and a 'Dark' mode. When you switch modes, Figma automatically reapplies the correct primitive values to your semantic tokens. Your color-text-primary token might point to gray-900 in Light mode but gray-100 in Dark mode. The components update instantly because they only care about the semantic name, not the underlying primitive.

This same logic applies to other variations. You could add modes for 'Compact' and 'Comfortable' densities that remap spacing tokens (spacing-inset-squish, spacing-stack-medium) to different primitive space values. This approach makes your Single Source of Truth incredibly flexible and efficient.

With a robust token system in place, you can build smarter components. By nesting components and using Figma's component properties, you can create highly configurable elements. For example, a single 'Button' component could have properties to control its state (Default, Hover, Disabled), style (Primary, Secondary, Destructive), and whether it includes an icon.

Each of these variants isn't a separate, manually-colored component. Instead, they are all driven by your semantic tokens. The 'Destructive' button variant simply swaps the color-background-interactive token for color-background-destructive.

While Figma's variables are the modern standard, the core concept of shared resources has been around for a while. In Sketch, this is achieved through Symbol Libraries and Shared Styles. A library is a separate Sketch document that houses all your master components (Symbols) and styles. You can then link this library to any number of project files. When you update a Symbol in the library, Sketch prompts you to update it everywhere it's used, ensuring consistency across projects. While less dynamic than Figma's variables for theming, it serves the same core purpose of creating a centralized, reusable asset repository.

Architecting a design system this way establishes a clear, scalable framework that bridges the gap between design and development. It moves the process from decoration to true system-level thinking.