What is a design system? (And why your product team needs one)

If you've ever watched a designer rebuild the same button for the fifth time, or spotted three different shades of "brand blue" on a single screen, you already know why design systems exist. They're the reason some product teams ship fast and stay consistent — and why others spend their Fridays arguing about button padding.

A design system isn't a trend or a nice-to-have. For any product team scaling past a handful of screens, it's what keeps design, engineering, and brand aligned as the surface area grows.

Here's what a design system actually is, why it matters for product teams, and how to tell if you're ready to invest in one.

What a design system actually is (not just a style guide)

A design system is the shared source of truth for how your product looks, behaves, and gets built. It sits in three layers that work together.

Design tokens are the raw values — colours, spacing, type scale, border radius, motion — stored in a format both designers and developers use. Components are reusable building blocks (buttons, inputs, cards, modals) with defined states, variants, and rules. Documentation is how you use the above: when to apply a pattern, when to break it, and what it means for your product.

A style guide tells you what your brand colour is. A design system tells you which component uses it, in which state, at what opacity, and why — and makes sure the code matches.

The Figma design system is usually where this lives, connected to engineering through tools like Storybook, Tokens Studio, or a component library in React or Vue. The specific tool matters less than the principle: one change propagates everywhere, and the design file and the codebase stop drifting apart.

Why product teams need one

Three reasons, roughly in the order you'll feel them.

Speed. Without a system, every new screen is a bespoke project. Designers rebuild patterns. Engineers reinvent components. PMs referee. With a system, new features are mostly assembly — you're composing known pieces instead of starting from scratch. Teams we've worked with have cut design-to-dev handoff time by 40–60% once their system hit maturity.

Consistency. Users don't read your product top to bottom. They scan, tap, and move on. Inconsistency — different button styles, different empty states, different error tones — creates friction they can't articulate but definitely feel. A design system makes consistency automatic instead of aspirational.

Cost. This is the part the CFO cares about. Every custom component is a liability: someone maintains it, tests it, fixes it when the browser changes, and eventually retires it. Systems reduce total surface area. Fewer moving parts, less QA, less refactoring a year from now.

There's a fourth reason that's harder to measure but just as real: hiring. Designers and engineers want to join teams where the foundations are solid. A mature design system signals a team that takes craft seriously.

When to invest in one

Not every team needs a design system on day one. If you're pre-product-market-fit and still iterating on core value, you probably don't. Ship the thing, learn, move on.

Here are the signals you're ready:

• You have more than two designers or two front-end engineers.
• Your product has grown past 10–15 meaningful screens.
• You're seeing visual drift — the same UI pattern built three different ways across the app.
• You're planning a redesign, a new product line, or a second platform (web + mobile, or spinning up a second app).
• Onboarding a new designer or engineer takes weeks because nothing is documented.

If two or more of those sound familiar, you're past the point where a design system pays for itself inside a quarter.

What good looks like

Plenty of companies have a Figma file labelled "design system" that nobody trusts. A good one has a few things going for it.

Tokens, not hex codes

Colours, spacing, and type are stored as variables, not hardcoded in every screen. When the brand evolves, you update a token — not every screen. This is the single biggest predictor of whether a system survives its first year.

Components that match what's shipped

The Figma library mirrors the code library. If a designer drags in a "Primary Button", the engineer imports the exact same component. No translation layer, no "close enough" gaps. This is where working with an experienced design system agency pays off — wiring the design side to the code side is where most in-house systems quietly break down.

Clear states and edge cases

For every component: default, hover, active, focus, disabled, loading, error. Empty states. Long text. Short text. A good system doesn't just show the happy path — it shows the reality.

Documentation that gets used

Not a 60-page PDF nobody reads. Short, pragmatic docs living next to the components themselves: what this is for, when to use it, when not to, and a link to the live example. If people keep asking "which input do I use?", the docs have failed.

Governance that doesn't crush the team

Someone owns the system. Someone decides when to add a new component versus compose an existing one. There's a light process for contribution. Without governance, systems rot. With too much, they become bureaucracy designers route around. The sweet spot is smaller than most people think.

Why design systems matter more in the AI era

Here's the part most articles on this topic miss. Generative AI has changed the economics of UI.

A designer or developer with AI tooling can now produce three versions of a screen in the time it used to take to produce one. That's great — if the output is constrained. If it isn't, you're just generating inconsistency faster.

A design system is the constraint. It's the context you give the model, the library it pulls from, the tokens it respects, the components it composes. Teams without one end up with AI-generated UI that looks slightly different every time it runs. Teams with one get AI as a genuine productivity multiplier, because the model has rails.

We've started thinking of design systems as the operating system for AI-assisted product work. If you plan to use AI anywhere in your design or build pipeline over the next two years, a system isn't optional. It's the thing that makes AI tools usable in a professional context.

Where to start

You don't need to build the full thing at once. The teams that get this right tend to start small: audit what exists, define tokens first, rebuild the 10–15 components you actually use, document as you go. Six weeks of focused work gets most mid-sized product teams to a working v1.

At UntilNow we build design systems for product teams — usually in Figma, usually tied back to a React or Vue component library, always shaped around the team's real workflows. We don't ship the 200-component library nobody asked for. We build the minimum system that solves your actual bottlenecks, then grow it with you.

If your team is hitting the signals above — visual drift, slow handoff, duplication across a growing product — it's probably time.

See how we approach design systems →