Product & UX
Building a Design System: When It Pays for Itself
Updated August 21, 2018By the CalliArc team
Key takeaway
A design system pays off once several people are building interfaces across more than one product surface — typically two or more squads. Below that, a shared component library and documented tokens deliver most of the benefit without the governance overhead.
Design systems are sold as a way to make products consistent. Their real return is speed: teams stop rebuilding and re-deciding the same twenty components, and start assembling.
What one actually contains
- Design tokens — colour, spacing, typography, radius, elevation — defined once and consumed by both design tools and code.
- Components, implemented and documented, with their states, variants, and accessibility behaviour.
- Patterns: how components combine for common jobs like forms, tables, empty states, and destructive confirmations.
- Usage guidance — when to use which component, and what not to do.
- Contribution rules: how a team proposes a change and how it gets accepted.
When it's worth it
- Two or more teams building interface in parallel, especially across web and mobile.
- Multiple products or surfaces that should feel like one company.
- A design and engineering handoff that repeatedly loses fidelity.
- Accessibility requirements you'd otherwise implement — and get wrong — separately in each component.
- Below that threshold: a shared component library and a tokens file. The same benefit, none of the governance.
How to start without stopping delivery
- Audit what exists. Counting the seventeen button variants already in production is usually enough to make the business case on its own.
- Start with tokens and the five most-used components — button, input, select, modal, table. That covers most screens.
- Build it out of real product work rather than as a separate project: the next feature uses the system and contributes what's missing.
- Document in code, with live examples. A specification in a design file drifts from the implementation within weeks.
What makes them fail
- No owner — a system everyone uses and nobody maintains decays into an inconsistent library with extra steps.
- Too rigid: if teams can't get a needed variant added quickly, they fork, and you now have two systems.
- Designed without engineers, producing components that are impractical to build.
- Versioned carelessly, so upgrading breaks consuming products and they stop upgrading.
- Measured by adoption theatre rather than by the questions it stops people asking.