Three years ago, one of our clients came to us with a familiar problem. Their product had grown quickly from a single-feature MVP to a sprawling SaaS platform with dozens of screens, multiple user roles, and a frontend team that had doubled in size in 18 months.
The result was predictable to anyone who's seen this pattern before: a UI full of inconsistencies. Buttons that weren't quite the same shade of blue across modules. Form labels that used three different text styles depending on when they were built and who built them. Spacing that was "eyeballed" on a feature-by-feature basis. A modal that behaved one way in one part of the app and differently in another.
This wasn't a failure of skill. The team was talented. It was a failure of infrastructure.
The hidden costs
The obvious cost of this kind of inconsistency is aesthetic your product looks sloppy. But the less obvious costs are often far more significant:
- Design time: Designers spend hours recreating the same patterns instead of solving new problems.
- Development time: Engineers build slightly different implementations of the same component repeatedly.
- QA time: More surface area for visual bugs means more time catching and fixing them.
- Cognitive load: Inconsistent UX patterns confuse users and increase support burden.
- Onboarding time: New team members take longer to become productive when there's no canonical reference.
In our experience, teams without a design system spend roughly 30–40% of their design and frontend time re-solving problems they've already solved. At scale, that's enormous.
What a design system actually is
It's worth being precise here, because "design system" has become one of those terms that means different things to different people.
A design system is not just a Figma component library. It's not just a React component library. It's not just a style guide PDF.
A design system is a shared language a set of reusable decisions, components, patterns, and documentation that creates alignment between design, engineering, and product. When it's working well, it should be possible for a designer and an engineer to have a meaningful conversation using the same vocabulary about the same artefacts.
"The goal of a design system isn't consistency for its own sake it's to reduce the number of decisions needed for every new feature, so teams can spend their cognitive energy on genuinely new problems."
The three layers
When we build design systems for clients, we think about three distinct layers:
Foundation layer: Colours, typography, spacing, iconography, elevation, and motion. These are the atoms the smallest decisions that flow through everything else. They should be expressed as design tokens so they can be used consistently across both Figma and code.
Component layer: Buttons, inputs, cards, modals, navigation patterns the reusable building blocks. Each component should have documented variants, states, and usage guidelines. This is what most people mean when they say "component library."
Pattern layer: Composite patterns like empty states, error flows, onboarding sequences, and data tables. These are where components combine into recognisable, reusable UX solutions.
Adoption is the hard part
Building the system is the straightforward part. Getting a team to actually use it is where most design systems fail.
The most common failure mode is building a beautiful system that nobody adopts because it wasn't built with the team's workflows in mind, or because it wasn't maintained after the initial build, or because the documentation was too sparse to be useful.
The systems we build tend to succeed for a few reasons: we involve engineering from day one (so components are built to match implementation reality, not an idealised Figma world), we write real documentation (not just a page that says "see Figma"), and we run a handover workshop so teams understand not just what's in the system but why.
When to build one
The honest answer is: earlier than most teams think. Once you have more than two people regularly creating UI, you'll benefit from even a lightweight system. You don't need to build Atlassian's design system on day one a well-structured Figma file with 30 core components and clear token definitions will pay for itself within weeks.
If you're beyond that point and drowning in inconsistency, the investment in a proper system is almost always worth it. The ROI on well-built design infrastructure compounds over time every feature built on a solid foundation is faster, more consistent, and easier to maintain than one built from scratch.
Final thought
Design systems are, at their core, an investment in the quality of decisions over time. They won't make your product better on their own bad ideas implemented consistently are still bad ideas. But they create the conditions where good ideas can scale, and where teams can spend their energy on solving genuinely hard problems instead of reinventing the same wheel every sprint.
