When is a design system premature?
If you have one designer and one product, you do not need a design system, you need a component library and a page of rules. A design system is a product with users, a release process and a maintenance cost, and building one before you have enough consumers to amortise that cost is a reliable way to slow down a small team while feeling organised. The threshold is lower than the sceptics say and considerably higher than most teams assume.
What does a design system actually cost to run?
Someone's continuing attention, which is the part nobody budgets. A real system needs a component to be designed, built, documented, tested for accessibility, versioned, released and then supported when four teams use it in ways nobody anticipated. That is product work, and it competes with the product itself for the same people.
The build is the small half. Most systems are created enthusiastically in a quarter and then decay, because governance was never assigned. The visible symptom is a component library with three button variants in the design tool, five in the code and a documentation site describing a version that shipped a year ago.
Reckon on a system needing continuing capacity rather than a project slot, even if that is a portion of one person's week. If nobody will own it, you are not building a design system, you are building a snapshot that will be wrong within months and will then be worse than having no system at all, because people will still be citing it.
What should a small team build instead?
Design tokens and a component library, without the surrounding apparatus. Tokens are the genuinely high-value part: colour, spacing, type scale and radius defined once, in a form both design tool and code read. They are cheap, they never need governance meetings, and they prevent the most common form of drift.
Then a component library used by one product, with no versioning, no documentation site and no contribution process. Components live in the codebase, the designer and the engineers agree what exists, and the rules fit on one page. This captures most of the consistency benefit at a fraction of the cost.
Write the page of rules and keep it to a page. What the spacing increments are, how many type sizes exist and what each is for, which colours may be used for what, and what happens on focus, hover, disabled and error. Teams routinely skip this because it feels too simple, and then spend two years negotiating spacing in code review.
| Team shape | What is worth building | What to skip | Owner |
|---|---|---|---|
| One designer, one product | Tokens and a page of rules | Documentation site, versioning, contribution process | The designer, informally |
| Two or three designers, one product | Tokens and a shared component library in code | Independent releases, a separate repository | Whoever touches it most, named explicitly |
| Several teams, one product | Versioned components with documented usage | A dedicated systems team | A part-time steward with decision rights |
| Multiple products or brands | A genuine system: themed tokens, releases, support | Nothing, this is the case it exists for | A funded team, however small |
| Agency delivering to a client | Tokens plus handover documentation | Anything requiring maintenance you will not be present for | The client, from day one |
What are the real thresholds?
Three consumers is the practical one. When three or more separate teams or products build interfaces that ought to look and behave alike, coordination cost exceeds the cost of a maintained system, and before that it does not. Count consumers rather than people, because ten engineers on one product still form a single consumer.
The second threshold is repeated re-litigation. If the same decisions are made again every quarter, about spacing, about which button is primary, about how a form reports errors, the arguing has become more expensive than the writing down. That is worth acting on even at small scale, though it usually calls for the page of rules rather than a system.
The third is a brand or accessibility obligation with consequences. Public sector work, regulated sectors and anything with an accessibility commitment benefit early, because getting focus states, contrast and keyboard behaviour right once in a shared component is dramatically cheaper than getting them right in forty places and then proving it.
How does a premature design system slow you down?
It converts decisions into requests. Once a system exists with a contribution process, a designer who needs a variant must either wait for the system to add it or break the rules, and both are slower than simply designing the thing. On a small team the system becomes a queue in front of a person who was previously just deciding.
It also freezes decisions made when you knew least. A system built in the first year encodes the conventions of a product that has not yet found its shape, and those conventions then resist the changes the product needs. Teams end up with a consistent interface for the wrong product, which is a worse position than an inconsistent one.
The third cost is attention. Systems work is satisfying, visible and easy to justify, which makes it a comfortable place to hide from harder product questions. A team polishing components while nobody has spoken to a user in three months is a common and expensive pattern.
How do you tell whether you crossed the line?
Count the buttons in your production code this afternoon. Search the codebase for the primary button, count the distinct implementations, and do the same for form fields and modal dialogues. If there are two of each and one designer, you have a tidying job. If there are six of each across three products, the coordination cost is already being paid, just in the worst possible form.
The second check is where new components come from. Ask the last three engineers who built one where they got the spacing and colours. If the answer is that they copied a nearby screen, you have a system already, an undocumented one, propagating by imitation. Writing down what it currently is beats designing what it ought to be.
Then check who would be woken by a change. If you altered the primary colour token today, how many teams would need to be told, and is there any mechanism to tell them. When that number reaches three and no mechanism exists, build the system. Before that, write the page.
Common questions
- When does a team need a design system?
- When three or more separate teams or products build interfaces that should look and behave alike, because at that point coordination cost exceeds maintenance cost. Count consumers rather than headcount, since ten engineers on a single product are one consumer. Earlier adoption is justified when an accessibility or regulatory obligation makes getting focus states, contrast and keyboard behaviour right once much cheaper than proving it in forty places.
- What should a small team build instead of a design system?
- Design tokens and a component library, without the surrounding apparatus. Tokens define colour, spacing, type scale and radius once in a form both design tool and code read, and prevent the most common drift at almost no cost. Add a single page of rules covering spacing increments, type sizes and their purposes, permitted colour usage, and the focus, hover, disabled and error states. Skip versioning, documentation sites and contribution processes.
- What does a design system cost to maintain?
- Continuing capacity rather than a project slot, because each component must be designed, built, documented, accessibility tested, versioned, released and supported when teams use it unexpectedly. The build is the smaller half. Systems created enthusiastically in one quarter and left unowned decay into a library with different variants in the design tool, the code and the documentation, which is worse than having no system because people still cite it.
- Can a design system slow a team down?
- Yes, in three ways. It converts decisions into requests, so a designer needing a variant either waits for the system or breaks the rules, both slower than deciding. It freezes conventions chosen when the team knew least about the product, producing consistency around the wrong shape. And systems work is satisfying and visible, which makes it a comfortable substitute for harder product questions.
- How do I know if we already need one?
- Search the codebase for how many distinct primary button, form field and modal implementations exist. Two of each with one designer is a tidying job; six of each across three products means the coordination cost is already being paid in the worst form. Then ask whether changing the primary colour today would require telling three or more teams, and whether any mechanism exists to tell them.
