Design Systems at Scale: What Nobody Tells You

Every studio eventually inherits a design system in crisis. The tokens are inconsistent. The component library has four versions of a button. Nobody can tell you where the source of truth lives. And somewhere, a frustrated engineer is copy-pasting the same card component for the eleventh time.

We've built and rescued a lot of design systems. Here is what we've learned.

The Governance Problem Is Real

Most design system failures aren't technical. They're organizational. A system without a clear owner — a person whose job it is to make decisions and communicate them — will drift. Immediately.

Before you write a single token, answer these questions:

1. Who can merge changes to the system? If the answer is "anyone on the design team," the system will fragment.
2. What is the approval process for new components? Without a bar, the library becomes a dumping ground.
3. How do consuming teams request additions? Without a formal channel, they'll build their own.

Tokens Are Not Just Colors

The token layer is the most important part of a design system and the most commonly misunderstood. Most teams start with a color token called --color-primary and call it done.

A mature token architecture has three tiers:

• Primitive tokens: Raw values. --color-gold-500: #C9A25E. These are never used directly in components.
• Semantic tokens: Intent-based references. --color-action-default: var(--color-gold-500). These are what components consume.
• Component tokens: Scoped overrides. --button-bg: var(--color-action-default). These allow component-level theming without breaking the semantic layer.

Most teams skip the semantic tier and pay for it later when they try to support dark mode, white-labeling, or sub-brand themes.

The Documentation Paradox

Design systems that are documented perfectly are usually documented incorrectly.

The paradox: docs are written at a moment in time. The system changes. Docs don't. By the time a new team member reads the documentation, it is already partially wrong.

Our current approach is to treat code as the primary documentation and prose as supplementary. A well-named component with well-named props and comprehensive TypeScript types is more useful than a five-paragraph essay that may be three months out of date.

What Actually Scales

After watching systems succeed and fail, the characteristics of the ones that endure:

• Small surface area. They cover common cases completely rather than every case partially.
• Strong opinions. The best systems make decisions so consuming teams don't have to.
• Boring foundations. The typography scale, spacing system, and grid are never exciting. They are also the most important parts.

The goal of a design system is not to eliminate creativity. It is to eliminate the decisions that shouldn't require creativity, so that the people using it can spend their attention on the ones that do.