We hit the wall in late 2019. Three active projects, all using slightly different button styles, different spacing conventions, different approaches to form validation. Not because anyone made a bad decision, but because nobody made a shared one. The cost wasn't visible until a developer moved between projects and spent their first two days learning a new set of patterns for the same type of work.
What You Need to Know
- Design systems aren't component libraries. They're shared agreements between design and engineering.
- The ROI appears when teams scale beyond two concurrent projects
- Starting small (tokens, then components, then patterns) works better than building everything upfront
- Enterprise clients notice consistency. It builds trust in ways that feature lists don't.
What a Design System Actually Is
A design system is a shared language. Not a Figma file. Not a component library. Not a style guide. It's all of those things working together, but more importantly, it's an agreement. When we say "primary button," everyone on every project means the same thing. Same colour, same padding, same hover state, same accessibility behaviour.
47%
reduction in UI development time reported by teams using mature design systems
Source: Sparkbox Design Systems Survey, 2019
That sounds obvious. In practice, without an explicit system, three developers will build three slightly different primary buttons. Each one works. Each one is defensible. But the inconsistency creates subtle friction. Users notice. Clients notice. New team members notice.
The Enterprise Case
Consistency Builds Client Trust
Enterprise clients are buying confidence as much as they're buying software. When every screen in their application feels like it belongs to the same family, that's a signal. It says: these people have their act together. The inverse is also true. Inconsistent UI, even when functional, creates doubt.
We had a client review session last year where the feedback was "the new module feels different from the rest of the app." It wasn't a bug. It was a design drift that happened because two different developers interpreted the same design differently. Both were reasonable. Neither was wrong. But the result felt fragmented.
Speed Across Projects
When a developer moves from Project A to Project B, the ramp-up time should be minimal if both projects share the same system. Same patterns, same naming conventions, same component API. The cognitive load of switching projects drops significantly.
A design system isn't about control. Every time a developer stops to think "how should this dropdown look?", that's a decision the system should have already answered.
Rainui Teihotua
Chief Creative Officer
Accessibility by Default
This is the argument that wins me over every time. When accessibility is built into the design system, every component inherits it. Focus states, screen reader labels, keyboard navigation, colour contrast. You solve it once, in the system, and every project benefits.
Without a system, accessibility becomes a per-project effort. And in the pressure of delivery timelines, it's the thing that gets deprioritised. We've written about the accessibility imperative before. A design system is how you make it practical rather than aspirational.
How We're Building Ours
We're starting small. Deliberately small. The temptation is to build a complete system before using it. That approach fails because you end up building components nobody needs while missing components everyone uses.
Phase 1: Design Tokens
Colours, spacing, typography, shadows. The atomic values that everything else is built from. Get these right and consistency follows naturally. Get these wrong and no amount of component polish will fix the underlying inconsistency.
Phase 2: Core Components
Buttons, inputs, cards, modals. The components that appear on every screen of every project. We're building these with accessibility baked in, responsive behaviour included, and a clear API that makes the right thing easy and the wrong thing hard.
Phase 3: Patterns
Login flows, data tables, form layouts, error states. These are compositions of core components that solve specific problems. They're opinionated, and that's the point. A data table pattern that handles sorting, pagination, and empty states means nobody has to reinvent that interaction.
The Real Cost of Not Having One
The cost isn't dramatic. Nobody's project fails because they lack a design system. The cost is slow. It's the extra hour per feature reconciling design differences. It's the accessibility bugs that get filed after launch. It's the new hire who takes a week longer to become productive because they're learning patterns instead of building features.
34%
of development time on enterprise projects spent on UI that already exists elsewhere in the codebase
Source: Brad Frost, Atomic Design Research, 2019
At our scale, with three to five concurrent projects, those hours add up to weeks per quarter. A design system doesn't eliminate that cost overnight. But it creates a trajectory where every project gets slightly faster and slightly more consistent than the last.
That's the investment we're making this year. Not glamorous. Extremely practical.