How a design system adds velocity, not overhead
The counterintuitive argument for investing in tokens and components before you think you need them.
Why systems feel slow at first
Every design system starts as overhead. You spend two weeks building a button component when you could have shipped four screens. Your PM looks at the sprint board. You feel the pressure.
But velocity is a lagging indicator. You don't see the payoff on the sprint it's built — you see it on the next ten.
The compounding effect
When a token changes, it changes everywhere. When a component gets updated, every screen using it updates too. This is obvious in theory. It becomes viscerally clear the first time you change a border-radius in one file and watch 47 screens update in Figma.
Context: regulated products
In insurance and banking, design systems aren't optional — they're compliance infrastructure. Accessibility, contrast ratios, interaction states — if these aren't systematized, they're inconsistent. Inconsistency in regulated UI is a risk, not just an aesthetic problem.
What I actually ship
A design system for me means three things: tokens (colors, spacing, type), components (built in Figma AND code), and documentation (the "why" of each decision). Without all three, it's just a component library — which is useful but not a system.
The honest timeline
It takes 6–8 weeks before a design system pays back the investment. If your project is shorter than that, skip the system. If it isn't, the question isn't whether to build one — it's when to start.
Start earlier than you think.