A design system is worth building when your scale-up ships the same button four different ways and no one is sure which is correct. It is a product — tokens, components, patterns, content rules and governance — maintained as a single source of truth between design and engineering. Below is a playbook for knowing when you need one, what it contains, and how London and Tallinn teams keep it alive.
When does a scale-up actually need a design system?
Not at the MVP stage. A design system is a response to design debt, and design debt only becomes expensive once you have several product surfaces, more than a couple of designers, and an engineering team large enough that people stop remembering every decision. Build it too early and you are polishing components no one uses; build it too late and every release drags a tail of inconsistency behind it.
The honest signals that you have crossed the line are behavioural, not aspirational:
- The same component — a button, an input, a modal — exists in three or four visually different versions across the product.
- Designers copy-paste screens instead of assembling them, and engineers rebuild UI that already exists elsewhere.
- Simple changes, like a new brand colour or a larger tap target, take weeks because they must be found and fixed by hand.
- Onboarding a new designer or front-end engineer takes far longer than it should, because the rules live in people's heads.
- Accessibility and responsive behaviour are inconsistent, so QA keeps finding the same classes of bug.
If two or three of those are true, the system will pay for itself — see the full design system ROI business case. If none are, invest instead in a tighter component library and a shared Figma file, and revisit later. For teams still finding traction, our note on design from MVP to product-market fit covers what to standardise first.
What is the anatomy of a modern design system?
A mature system is layered. Each layer serves a different audience and changes at a different pace, which is why treating them separately keeps the whole thing maintainable.
Design tokens: primitive, semantic and component tiers
Design tokens are the named values — colours, spacing, radii, type scale, motion — that everything else references. The tiering matters more than the naming convention:
- Primitive tokens are raw values: blue-600, space-4, font-size-14. They carry no meaning, only value.
- Semantic tokens map primitives to intent: colour-action-primary, surface-danger, text-muted. Components reference these, so a rebrand or a theme change touches one layer.
- Component tokens are optional, scoped values like button-padding-inline, used when a component needs its own tuning without leaking into the global scale.
Get this tiering right and light or dark themes, density modes, and white-label variants become configuration rather than rework.
Components, patterns, content and documentation
Above tokens sit components (buttons, fields, cards), then patterns that compose them into recurring solutions — an empty state, a form layout, a data table with pagination. Alongside these live the parts teams routinely forget: content and voice rules so microcopy is consistent, and documentation that explains not just what a component looks like but when to use it, when not to, and what accessibility behaviour it guarantees. A component without usage guidance is a liability; people will use it in ways you never intended.
What does the tooling reality look like in 2026?
The tooling has matured to the point where the single-source-of-truth promise is genuinely achievable, provided you wire it up deliberately.
- Figma variables and modes now express tokens natively, with modes handling themes, brands and density. This is where most design-side tokens live and change.
- A token pipeline — using a transformer such as Style Dictionary or an equivalent — exports those variables to platform formats: CSS custom properties, iOS, Android, whatever you ship.
- Storybook (or a comparable component workshop) documents the coded components in isolation, with states, controls and accessibility checks.
- Code-connected components link the Figma component to its real implementation, so designers reference production code rather than a redrawn copy.
The single source of truth is not a place; it is a direction of flow. Tokens flow from design definitions into code; components are built once in code and reflected back into design. When that loop is intact, design and engineering stop arguing about which value is correct because there is only one. Keeping that pipeline fast also protects your Core Web Vitals, since a lean, shared component layer avoids duplicate CSS and bloat.
How do you treat a design system as a product?
The single biggest mindset shift for a scale-up: a design system is a product, and its users are your own designers and engineers. That framing decides everything about governance.
Contribution models and governance
Choose a governance model that matches your size. A small team can run centralised — one or two people own the system. As you grow, a federated model works better: a core team owns standards and the pipeline, while product teams contribute components through a defined review process. What kills systems is the middle ground where everyone can change everything and no one is accountable. Write down how a contribution is proposed, reviewed, accepted and released, and make that path genuinely faster than working around the system.
Versioning and measuring adoption
Version the system semantically so consumers can adopt changes on their own schedule, and communicate breaking changes clearly. Then measure adoption, because a system no one uses is just overhead. Track the share of UI built from system components, the number of one-off overrides, and how quickly teams pull in new versions. Adoption metrics turn the system from an act of faith into something you can argue for at budget time. Our product growth lens applies here too: treat internal adoption like any other funnel.
What are the common failure modes?
Most design systems do not fail technically; they fail organisationally. The recurring patterns are worth naming so you can spot them early:
- The abandoned library. Built in a burst of enthusiasm, never resourced afterwards, slowly drifts out of sync with the live product.
- Design and code divergence. The Figma library and the coded components describe different realities, so no one trusts either.
- Over-engineering. Months spent on tokens and theming for a product that needed twelve solid components.
- No adoption path. The system exists but using it is slower than not using it, so teams route around it.
- Governance vacuum. No owner, no contribution rules, endless bikeshedding.
Every one of these is a resourcing or ownership problem wearing a technical costume.
How do dual London and Tallinn teams keep design and code in sync?
Running design and engineering across London and Tallinn — or any distributed European setup — sharpens the discipline rather than complicating it, because you cannot rely on hallway conversations to paper over gaps. A few practices make distance a non-issue:
- Treat the token pipeline as the contract. When design changes a variable and the export runs, engineering receives the change without a meeting.
- Use code-connected components so a designer in Tallinn and an engineer in London are looking at the same source, not two interpretations.
- Keep documentation asynchronous and current — usage rules, do and don't examples, accessibility notes — so time zones never block a decision.
- Hold a lightweight, regular systems review across both offices to triage contributions and retire debt, rather than letting it accumulate silently.
The dual-base model, common among product studios working across Europe, works precisely because the system is written down and automated. Tacit knowledge does not survive a 1,800-kilometre gap; explicit systems do.
What does a practical rollout roadmap look like?
Roll out in phases and ship value at each one, so the system proves itself before it is finished.
- Phase 1 — Audit. Inventory existing UI, catalogue the duplication, and agree the token structure. This alone surfaces the cost of the current mess.
- Phase 2 — Foundations. Define primitive and semantic tokens in Figma variables, stand up the export pipeline, and ship them to code. Nothing looks different yet, but the plumbing is real.
- Phase 3 — Core components. Build the ten to fifteen components that cover most of your screens, document them in Storybook, and connect them to code.
- Phase 4 — Adoption. Migrate one high-traffic surface, measure the effort saved, and use that evidence to pull the rest of the product across.
- Phase 5 — Govern. Establish the contribution model, versioning and adoption metrics, and hand the system a named owner.
Done this way, a design system stops being a six-month tax and becomes a compounding asset — one that makes every subsequent feature, rebrand and platform faster to ship. That is the whole point of building one at scale-up stage rather than admiring one from afar.
Frequently asked questions
How is a design system different from a component library?
A component library is a set of reusable UI elements. A design system is broader: it includes the tokens beneath those components, the patterns above them, content and voice rules, documentation, and the governance that keeps everything current. The library is one layer; the system is the whole product, including the process that maintains it.
What are design tokens and why do the tiers matter?
Design tokens are named design decisions — colours, spacing, type, motion — stored as values other things reference. Tiering separates primitive values from semantic intent from component-specific tuning. That separation means a rebrand, a dark theme, or a density change touches one layer rather than every component, which is what makes the system maintainable as you grow.
When is a scale-up too early for a design system?
If you have one or two designers, a single product surface, and no recurring inconsistency, you are early. Design systems answer design debt, so with little debt the investment sits idle. Start with a shared component library and a clean Figma file, then build the full system once duplication, slow changes, and onboarding pain appear.
How do you keep design and code in sync across two offices?
Make automation the contract. A token pipeline exports design variables straight into code, and code-connected components mean designers reference the real implementation rather than a redrawn copy. Keep documentation asynchronous and current, and hold a regular cross-office systems review. Written, automated systems survive distance in a way tacit knowledge never does.
How do you measure whether a design system is working?
Track adoption, not output. Useful metrics include the share of UI built from system components, the count of one-off overrides, how fast teams pull in new versions, and the time saved on typical changes. These numbers turn the system from an act of faith into a fundable asset and reveal when a component is being avoided.