In 2019, a fintech client asked us to audit their design system. It had been built by a talented team over 18 months, consumed by 6 product squads, and had 240 components in Figma. Four months after the initial release, 60% of product squads had stopped using it and were building their own local component libraries. We ran the same audit for a different client in 2023. Their design system, built by a two-person team, was used by all 11 squads with 94% adoption after two years. The difference was not design quality. It was governance and architecture.
Token Architecture: The Foundation That Everything Else Is Built On
Design tokens are not just a nice-to-have — they are the load-bearing wall of a scalable design system. Every hardcoded hex value (#1A2B3C) in your codebase is a future maintenance liability. Every instance of text-gray-700 in Tailwind that means 'disabled state' rather than 'literally a specific shade of grey' is an abstraction violation waiting to cause a visual regression when someone updates the grey palette.
We use a three-tier token architecture: Primitive tokens (the raw values: blue-600 = #2563EB), Semantic tokens (the intent: --color-action-primary = blue-600), and Component tokens (the local application: --button-bg-primary = --color-action-primary). When a brand refresh happens — and it will — you update one primitive token and every component inheriting from it updates for free.
/* ── Tier 1: Primitives ── */
:root {
--blue-600: #2563EB;
--blue-700: #1D4ED8;
--gray-100: #F3F4F6;
}
/* ── Tier 2: Semantic ── */
:root {
--color-action-primary: var(--blue-600);
--color-action-primary-hover: var(--blue-700);
--color-surface-default: var(--gray-100);
}
/* ── Tier 3: Component ── */
.btn-primary {
background-color: var(--color-action-primary);
}
.btn-primary:hover {
background-color: var(--color-action-primary-hover);
}The Component Hierarchy That Prevents Spaghetti
Without a strict component hierarchy, every engineer organically adds small variations to existing components ('I just need a Button with a slightly different padding here') and you end up with 18 semantically identical button variants. We enforce a four-level hierarchy: Primitives (atomic, no business logic), Patterns (compositions of primitives with intent), Templates (page-level compositions), and Overrides (strictly version-controlled escape hatches).
The key governance rule: no pattern can have more than two boolean props that affect layout. If your Card component has isHorizontal, isCompact, isHighlighted, hasBadge, and hasFooter, you do not have a Card component — you have five components with shared implementation. Split them.
Warning
The most dangerous words in design system development: 'let's add an optional prop for that'. Every optional prop is a combinatorial explosion of undocumented visual states. Prefer composition over configuration.
Governance: The Part Nobody Talks About
The highest-value process in a successful design system is not the component library itself — it is the contribution and deprecation process. Without explicit governance, teams either add unreviewed components that fragment visual consistency, or they avoid contributing entirely because it feels too bureaucratic.
We use a lightweight RACI model: any engineer can propose a new component via a two-hour design spike with a Figma mockup and a use-case brief. A rotating Design System Council (two engineers + one designer, rotating monthly) reviews proposals weekly and accepts, rejects, or flags for broader discussion. Accepted components are given a one-sprint implementation SLA. Deprecated components get a six-week sunset window with automated lint warnings.
Measuring Adoption: The Metric Nobody Tracks
Most design system teams measure component count and Figma library subscriptions. Neither metric tells you whether the system is actually improving product quality or developer velocity.
We track three adoption metrics monthly: Design System Coverage (percentage of UI surface area rendering design system components vs custom code), Drift Rate (number of new custom styles added outside the token system per week), and Time-to-First-Pixel (how long it takes a new engineer to ship a pixel-perfect screen using only design system components). These three numbers, tracked weekly, tell you whether your system is healthy or decaying.
Conclusion
A design system is a product, not a project. It has a roadmap, a backlog, adoption metrics, and a dedicated team — or it dies. The technical quality of your component library is table stakes. The governance processes, contribution workflows, and deprecation cadences are what separate systems that compound team velocity over time from systems that become legacy technical debt in 18 months.
Key Takeaways
- Three-tier token architecture (primitive → semantic → component) is mandatory for scalability
- Enforce a strict component hierarchy: primitives, patterns, templates, overrides
- Govern contribution and deprecation with a lightweight RACI process
- Track Design System Coverage, Drift Rate, and Time-to-First-Pixel weekly
- Treat your design system as a product with a dedicated team who owns its roadmap