In the past five years, "design system" has become one of the most requested deliverables in digital project briefs. Clients ask for them without always knowing what they are. Agencies propose them without always knowing when they're genuinely needed.
Let's clear this up.
What a design system actually is
A design system is a shared library of reusable components, standards, and guidelines that define how a product looks and behaves. At its core, it's three things working together:
Design tokens
The raw values: colors, spacing units, typography scales, shadow definitions. These are the atoms everything else is built from. In Figma, they live as variables. In code, as CSS custom properties or a theme file.
Component library
Buttons, inputs, cards, modals, navigation patterns — built once, documented, reused everywhere. Every component exists in both design (Figma) and code (React, Vue, etc.) with identical behavior.
Documentation and guidelines
Rules for how components are used: when to use a primary vs. secondary button, how forms should behave on error, what spacing rules apply between sections. Written for both designers and developers.
The real benefit
The value of a design system is speed and consistency at scale. When a new page needs to be designed, you assemble existing components rather than designing from scratch. When a developer builds a new feature, they import from the library rather than writing new CSS. Changes made to the system propagate everywhere.
For a team shipping 10+ features per month across multiple products, this compounds into weeks saved per quarter and a dramatically more consistent user experience.
Do you actually need one?
✓ You probably do if:
- You have 2+ products sharing a brand
- Your dev team ships new UI every sprint
- You have both design and dev working in parallel
- You've noticed inconsistency creeping in across your product
- You're planning significant growth in team size
⚠ You probably don't if:
- It's a single website or app, rarely updated
- You have no in-house design/dev team
- The project is under €50k budget
- You're pre-product-market fit and pivoting frequently
- There's one designer and one developer
The mistake most companies make is building a full design system for a project that doesn't need one. A 12-page marketing website doesn't need a design system — it needs a style guide. A dashboard with 40 screens used by an internal team of 5 probably doesn't need one either.
A design system is infrastructure. Build it when you're scaling, not before. Infrastructure too early is overhead. Infrastructure too late is debt.
The lighter alternative: a style guide
For most growing companies, a style guide — colors, typography, key component specs, and basic usage rules — covers 80% of what a design system provides at 20% of the cost. It's the right starting point.
We build style guides into every project we deliver. We build proper design systems when clients have the team size, product surface area, and ongoing development velocity that justifies the investment. The distinction matters.