What Is a Design System? A Practical Guide for Product Teams

Every product team we meet is somewhere on the same curve. First the product is small and one designer holds the whole thing in their head. Then a second designer joins, then three engineers, then a mobile app, then a marketing site, and one day someone opens the codebase and finds eleven button components and six shades of grey that are all called "border".

That is the moment people start asking what a design system is, and whether they need one.

So: a design system is the shared, documented set of decisions that lets a team build a product consistently without renegotiating those decisions every time. Not a Figma file. Not a component library. A system of decisions, expressed in design and in code, with rules about how it changes.

This guide is written for founders, product leads and heads of design who are deciding whether to invest in one. It covers what a design system actually contains, when it pays for itself, when it absolutely does not, and how we build them at UntilNow.

What is a design system, precisely

The clearest way to think about it is in four layers. Each one depends on the one before it, and most failed design systems skipped a layer.

1. Foundations (the tokens)

Colour, type scale, spacing, radii, elevation, motion durations, breakpoints. These are named values, not hex codes scattered through screens. "color.surface.subtle" rather than "#F4F4F5".

Naming is the whole game here. A token named for its purpose survives a rebrand. A token named for its appearance ("grey-100") becomes a lie the first time your brand changes.

2. Components

Buttons, inputs, selects, modals, tables, toasts, navigation. Each one built with its full set of states: default, hover, focus, active, disabled, loading, error, empty. The states are where the real work lives. Most component libraries look complete until an engineer asks what a multi-select looks like while it is loading with a validation error attached.

3. Patterns

The layer almost everyone skips. Patterns are the recurring compositions: how a form is laid out, how errors are surfaced, how a destructive action is confirmed, how an empty state is written, how a data table handles 10,000 rows. Components tell you what to use. Patterns tell you what to do.

4. Governance and documentation

Who can add a component, how a change gets proposed, how the Figma library and the coded library stay in sync, what the deprecation path is. Without this layer, a design system is just a snapshot that starts rotting the day it ships.

What a design system is not

Three things get called design systems and are not.

A component library is not a design system. It is layer two of four. Plenty of teams have a tidy set of React components and still argue about spacing in every review, because nothing above or below that layer was ever agreed.

A Figma file is not a design system. If the design library and the production code drift, engineers stop trusting the file and start reading the code, and your system now exists only in the codebase. That is survivable. What is not survivable is nobody knowing which one is true.

Brand guidelines are not a design system. Brand guidelines were mostly written for marketing: logo clearspace, campaign photography, tone in a headline. Take a product question to them (which grey in a data table, what does our personality do to an error message) and you will find nothing. We wrote about that gap in more detail in brand-led product design.

Why product teams build design systems

The case is usually made on consistency. Consistency is the visible benefit, but it is not the one that pays for the work.

Speed compounds, and it compounds late

A design system makes the first three months slower and every month after that faster. New screens stop being design problems and become assembly problems. In our experience, teams reach a point where roughly 70 to 80 percent of a new screen is existing components arranged in an existing pattern, and the designer's whole attention goes to the 20 percent that is genuinely new. That is the return.

It removes a category of decision entirely

The hidden cost of no system is not ugly screens, it is decision volume. Every button, every gap, every error message is a small negotiation between a designer and an engineer. Multiply that by a sprint and you lose days to questions nobody will remember having answered.

It survives your team

Designers leave. Agencies finish. A documented system is the difference between a product that keeps its coherence after a handover and one that visibly changes character every time the team does. If you can point at a product and tell which year each screen was built, that product had no system.

Quality gets a floor

With accessible focus states, contrast-checked tokens and tested components, accessibility stops being something you retrofit before an enterprise procurement review. It becomes the default that comes free with using the system.

When you do not need a design system

This is the section most agencies leave out, so here it is plainly. We have talked clients out of design system work more than once.

You are pre product-market fit. If you are still changing what the product is every six weeks, a system codifies decisions you are about to throw away. Build a small set of shared tokens and three or four components, and stop there. Everything else is premature.

You have one designer and one engineer. Two people can hold consistency in their heads and talk to each other. The overhead of governance costs more than it returns until roughly the third or fourth person joins.

Your product is one surface and will stay one surface. A single web app, no mobile, no marketing site sharing components, no white-label. A tidy component library is enough.

The real problem is that nobody knows what to build. A design system makes you faster at building. If your retention is flat because the product solves the wrong problem, a system makes you faster at building the wrong thing. Start with a UX audit or concept validation instead.

The honest test: a design system is worth it when the cost of inconsistency is currently being paid by more than two people, every week.

How we build design systems

Our approach is deliberately unglamorous, and it is built around the observation that most design systems fail from being too complete rather than too small.

Audit before we design anything

We pull every screen in the product and every component in the codebase into one view and count. How many buttons actually exist. How many greys. Which components are used on 40 screens and which on one. This usually takes a week and it consistently produces the moment where the team sees the real inventory for the first time.

The audit sets the scope. You do not need to systemise everything, you need to systemise what is used repeatedly.

Tokens before components, always

Foundations first, named semantically, agreed with both design and engineering in the same room. If tokens come after components, every component has to be rebuilt when the tokens land.

Build the 20 percent that carries 80 percent of screens

From the audit we take the components that appear everywhere and build those properly: every state, documented, coded, accessible. The long tail waits. A design system with 15 components that people actually use beats one with 60 that nobody trusts.

Design and code in step

We build the Figma library and the coded components together, not design first and a handoff later. A component is not done when it looks right in Figma, it is done when it is in the codebase and a product engineer has used it without asking a question.

Hand over the rules, not just the files

The last phase is governance: contribution process, review path, versioning, and the documentation that lets someone who was not in the room make a correct decision six months from now. This is the part that decides whether the system is alive in a year.

What it costs and how long it takes

Ranges, because scope varies enormously, but useful ranges.

A foundation system for an early-stage product (tokens, 12 to 18 core components, light documentation, Figma plus code) is typically a 5 to 8 week engagement. Enough to stop the bleeding, not enough to constrain a product still finding its shape.

A full system for an established product with multiple surfaces (audit, tokens, 30 to 50 components, patterns, accessibility, documentation site, governance) usually runs 10 to 16 weeks, often alongside the product team rather than instead of it.

A rescue, where a system exists but has drifted out of use, is usually shorter and mostly diagnostic: find out why people stopped using it. The answer is almost always that contributing was harder than working around it.

Budget for maintenance too. A design system with no ongoing owner has a shelf life of roughly one product cycle.

Signs your design system has gone wrong

• Designers detach components regularly. The system does not cover a real case and there is no path to add it.
• Engineers have a local "utils" file of one-off styles. Same problem, other side of the fence.
• Nobody has proposed a change in three months. That is not stability, that is abandonment.
• The documentation describes what components look like but not when to use which. Patterns layer missing.
• New hires ask a human instead of reading the docs. The docs do not answer real questions.

FAQ

What is the difference between a design system and a style guide?

A style guide describes appearance. A design system encodes decisions and ships them as usable assets in both design and code, with rules for changing them. A style guide is read. A system is used.

Should we use an off-the-shelf system like Material or shadcn?

As a starting point, often yes, especially pre-launch. As a finishing point, only if you are comfortable looking like every other product built the same way. The default kits that AI tools reach for are now so widely used that they have become the visual average of software. Fine for speed, expensive for differentiation.

Who should own the design system?

One named person, part-time is fine, with authority to say no. Shared ownership across a team reliably becomes no ownership.

How do we measure whether it is working?

Component adoption rate (what share of the UI is system components), time to build a standard screen, and the number of design-review comments about spacing and colour. All three should move within a quarter.

Can AI build our design system?

AI is genuinely good at the mechanical parts: generating component variants, writing documentation drafts, migrating tokens. It is poor at the decisions, which is most of the value. It does not know what your product should feel like or which of your 11 buttons was the right one.

The takeaway

A design system is not a design deliverable, it is product infrastructure. Its job is to remove a whole class of recurring decisions so your team spends its attention on the problems that are actually unique to your product.

Build it when the cost of inconsistency is being paid weekly by more than two people. Build the small version first. Name the owner before you name the components.

If you are weighing this up and want an honest read on whether it is the right investment right now, we are happy to look at your product and tell you if it is not. That conversation starts with a UX audit or a straight chat about design systems.