A Design System Built for Shipping Speed
Why I stopped chasing the perfect component library and started optimizing for how fast an idea becomes a deployed screen.
A design system is not a gallery of components. It is a machine for turning intent into interface as fast as possible. Once I judged mine by that standard, most of it got simpler.
The Problem
Our component library had grown 140 components, half of them one-off variants. Building a new screen meant archaeology: which button, which card, which spacing token?
Investigation
I audited what we actually used. A small core of primitives covered 90% of screens. The rest was accumulated indecision dressed up as flexibility.
The Solution
Ruthless consolidation. One set of semantic tokens, a handful of composable primitives, and strong opinions baked into defaults so the fast path is also the correct path.
The Result
New screens now take hours, not days. Consistency improved because there is simply less to get wrong. The library shrank by 60% and got more capable.
Lessons Learned
- Delete before you add.
- Encode taste in defaults, not documentation.
- Measure the system by time-to-shipped-screen.
