When does your product need a design system (and when is it a waste)?

There is a phrase product teams use that signals exactly what they have not built. The phrase is “Material is our design system.” Or “Tailwind is our design system.” Or “we use the Shadcn defaults.” Each of those is honest about what was downloaded. None of them is a design system.

A design system is the set of rules, tokens, and components specific to YOUR product — not a generic library you started from. Knowing when to build one, and when not to, is one of the higher-impact design decisions a product team makes.

The shortest possible answer

You need a design system when (a) you have more than one designer working on the product, (b) you ship to more than three connected surfaces (web app, mobile app, marketing site, docs, admin), or (c) you have engineers building UI faster than designers can hand it off. Below those thresholds, a Figma file with shared styles is enough. Above them, you are paying the cost of NOT having one whether you realise it or not.

What a real design system actually contains

Not a Figma file. Not a component library in Storybook. Not a set of Tailwind utility classes. A real design system is four layers, in order:

1. Tokens. The atomic values — colour, type, spacing, radius, shadow, motion — defined ONCE as design tokens and exported into both the design tool (Figma variables) and the codebase (CSS custom properties, theme JSON). When a token changes, every place that uses it changes. Tokens are the load-bearing layer; if you have nothing else, you should have tokens.
2. Components. Buttons, inputs, cards, modals, tables, tabs — each defined as a single source of truth with all their variants and states (default, hover, focus, active, disabled, loading, error, empty). The component spec lives in Figma; the component implementation lives in code; the two stay in sync because tokens are shared.
3. Patterns. How components combine into common UI tasks — a form, a data table with sorting and pagination, a wizard, an empty state, a confirmation dialog. Patterns encode decisions about HOW the product behaves, not just how individual components look.
4. Documentation. A real site (not a Figma cover page) that explains when to use each component, when not to, accessibility considerations, the rationale behind each token choice, and the contribution guidelines for adding to the system.

“Material is our design system” usually means “we use Material components and nothing else.” That gives you components without tokens (everything reverts to Google’s brand decisions), patterns without rationale (you use Material’s patterns regardless of whether they fit your product), and documentation about Material — not documentation about your product.

The four signs you need a design system

Sign 1 — More than one designer.

One designer can carry the rules in their head. Two designers cannot. The moment a second designer starts shipping work, you need a shared source of truth or the brand and the product fragment within weeks. We have seen products diverge visibly within a single sprint after a second designer joined a team without a system.

Sign 2 — More than three connected surfaces.

Web app + mobile app + marketing site is three. Add admin, docs, or onboarding emails and you are at five. Each surface needs to feel like the same product — same easing, same spacing rhythm, same component vocabulary. Without a system, every surface reinvents these decisions locally, and the product ships as five different brands.

Sign 3 — Engineers building UI faster than designers can hand it off.

When the engineering team is asking “is this OK?” and “should this be 12 or 16 pixels?” multiple times a week, the designer has become a bottleneck and engineering is improvising. A system that includes design tokens AND component code (Storybook, headless UI libraries, or a published component package) removes the bottleneck. Engineers compose features from approved components; designers spend their time on new patterns, not on policing.

Sign 4 — A new product surface or sub-brand is coming.

If the product is launching a second product, a sub-brand, or expanding internationally, the existing implicit consistency will not survive the expansion. A design system before the expansion is dramatically cheaper than retrofitting one after. We have run this engagement four times in two years; in every case the cost-of-no-system grew faster than the cost of building one.

Three signs you do NOT need one yet

You have one designer, building one product, on one surface. A Figma file with shared styles is enough. Premature design systems are a real waste — they encode decisions before there is enough product to validate them.

The product is pre-product-market-fit. If you are still iterating on what the product even IS, locking in a system slows you down. Iterate the product first; systematise the design once the product stabilises.

The team is fewer than five people. Below five, communication overhead is low enough that informal consistency works. Above five, you need formal artifacts; below five, you need speed.

The “Material is our design system” trap

The temptation: skip the cost of building a system by adopting a well-documented one. Material Design, Apple’s Human Interface Guidelines, Carbon, Polaris — these are excellent systems for the companies that built them. They are not your design system.

Three problems with adopting another company’s system as your own:

1. Tokens are wrong. Material’s colour is Google’s. Material’s type scale is Roboto-optimised. Material’s elevation system is from a specific 2014 design philosophy. None of these are right for your product unless your product is owned by Google.
2. Patterns assume Google’s product strategy. Material’s FAB pattern, side drawer, snackbar timing — these encode decisions that Google made for Google’s products. When you use them in a product that does different things, they fight the work.
3. Documentation is for Google, not for you. Material’s docs explain Material. They do not explain how to use Material components AS your design system in YOUR product context. Your team has to do that documentation work anyway, and at that point you have built a partial system on top of a generic one — a worse outcome than building your own from the start.

What’s legitimate: using a headless UI library (Radix, React Aria, Shadcn primitives) as the technical foundation, then designing your own tokens and component variants on top. That’s not “Material is our design system” — that’s “we did not reinvent accessible primitives, but the system on top is ours.”

The minimum viable design system

If you need a system but cannot afford the full build, ship these four things in this order:

1. Design tokens (1–2 weeks). Colour, type, spacing, radius, motion. Exported as Figma variables and CSS custom properties. Half a page of documentation. This alone removes 60% of the inconsistency we see in pre-system products.
2. A core component set (3–4 weeks). Button, input, card, modal, table, navigation. Each with all states. Designed in Figma, built in code, documented in 2–3 pages.
3. Three to five patterns (2 weeks). Form, data table, empty state. Documented with rationale and accessibility notes.
4. A real documentation site (1 week). Static site (Storybook, Zeroheight, or hand-built) that the engineering and design teams actually use. NOT a Figma cover page.

Total: 7–9 weeks for a minimum viable system. That is dramatically cheaper than rebuilding the product when consistency fails at scale.

The cost-of-no-system

The reason teams underinvest in design systems is that the cost of not having one is invisible until it isn’t. Three places it shows up:

Engineering velocity. Without a system, every new feature requires design review of every UI component used. With a system, engineers compose features from approved primitives in hours rather than days.

Brand consistency. Without a system, the product looks different in week 1 vs week 26. Customers notice; investors notice; the team notices but cannot name it.

Onboarding cost. A new designer or engineer joining a team without a system takes 3–6 weeks to ramp up. A new hire joining a team WITH a system is shipping in week 2.

None of these costs appear on the design budget. All of them appear somewhere else.

The single-line version

You need a design system when the cost of not having one exceeds the cost of building one. For most teams shipping a real product across multiple surfaces, that crossover happens earlier than they expect. “Material is our design system” is a credible answer to a question nobody on a serious product team is asking.

Common questions