Design systems that actually scale
Most design systems get abandoned within 18 months. Here's what we've learned shipping six of them — and the patterns that survive a year of real product work.
Sudewa Jayanath
Founder · Uniix Studio
Every agency proposal we read in 2024 listed a 'design system' as a deliverable. By Q1 2025, half of those systems were already broken — components forked into one-off variants, tokens drifting from code, documentation 6 months stale.
The pattern is consistent: teams build the system, then forget to operate it. A design system isn't a deliverable — it's an operating model.
1. Treat tokens as the source of truth, not components
When tokens are the source of truth, components can be re-skinned, swapped or rebuilt without breaking the visual identity. When components are the source of truth, every redesign is a migration.
We export tokens from Figma to a single JSON file, transform them into platform-specific variables (CSS custom properties, Swift, Kotlin) at build time, and ban hardcoded colors in PRs via a lint rule.
2. Keep the API surface tiny
A Button with 14 props is not a design system — it's a configuration nightmare. Pick the 3-4 variants that cover 90% of cases and force the rest into a deliberate exception.
The discipline isn't 'make components flexible' — it's 'make the right thing easy and the wrong thing hard'.
3. Ship docs in the same PR as the component
If documentation is a separate workstream, it never ships. Storybook + MDX in the same repo is a hard requirement.
