Design Systems: When Do You Actually Need One?

A team of four ships a marketing site, a signed-in product and an admin panel. The primary button differs across all three, in ways nobody chose. Somebody proposes a design system, the estimate comes back at roughly a quarter of the next release, and the conversation that follows is conducted almost entirely in adjectives.

Design system adoption is a threshold decision, not a maturity badge. Below the threshold, a system is overhead you pay every sprint for consistency you could have had by copying a file. Above it, the absence of one is a tax on every screen you ship, and it compounds, because inconsistency spreads in a way that consistency never does.

The threshold has three inputs: how many surfaces you ship, how many people can change them, and how fast they change. Not company size. Not funding stage. Certainly not whether a competitor published theirs on a nice microsite last week.

Three different things get called a design system

The phrase covers three artefacts with different costs and completely different failure modes. Getting the vocabulary straight settles about half the usual disagreement before it starts.

The third row is the expensive one, and the reason sits in its last cell. A component library is a repository. A design system is a repository plus a standing commitment, and the commitment is the part that gets quietly removed from the estimate so the number looks approachable.

This distinction is not pedantry. It changes who signs off, what the ongoing cost line says, and what happens when the person who built it moves teams. Plenty of organisations genuinely need the second row and have been sold the third. The reverse also happens, and it is worse: a team that needed governance gets handed a package with no owner, and the package outlives the intent behind it.

The threshold: surfaces, contributors, rate of change

Three counts. Do them honestly, on paper, before anybody opens a design tool. The reason these three and not others is that they multiply. Two surfaces changed rarely by two people is a manageable amount of drift. Six surfaces changed weekly by eight people is a different category of problem, and the difference between them is not a matter of degree.

Count your surfaces

Count every place your interface appears, not every page. A marketing site, a signed-in product, an admin panel, transactional email, onboarding, checkout, error and maintenance pages, exported documents, and anything embedded from somewhere else. Most teams undercount by roughly half, because they only count the things a designer has opened this month.

Breakpoints are not surfaces, but they behave like them when the constraints diverge enough. That is the argument in mobile first is not a layout decision, and it matters here because a system assembled entirely from desktop compositions gets re-argued the first time somebody opens it on a narrow screen with one thumb.

Third-party embeds count too, and they are the ones nobody audits. A chat widget, a booking tool, a review badge and a consent banner are four interfaces you did not design, each with its own type scale and its own idea of focus. Consolidating them genuinely helps: a lightweight widget such as Flidu, which carries website-informed assistance alongside contact and conversion actions, removes several separate embeds from a page. The ones you keep still belong in the audit, because a floating widget can fail a screen reader no matter how tidy your own components are.

Count your contributors

The number that matters is not headcount. It is how many people can introduce a new pattern without asking anyone first. One designer and one developer sitting near each other do not need a system; they need a shared file and a habit. Somewhere around five people with commit rights and no arbiter, the same dropdown gets invented three times in a quarter, and nobody notices until an accessibility fix has to be applied in five places.

Contractors and agencies count double here, because they arrive with their own conventions and leave before the consequences land. If external hands regularly touch the interface, the threshold arrives earlier than the headcount suggests.

Count the rate of change

A site that changes twice a year never amortises a system. A product shipping weekly does, because the saving is per change and there are a great many changes. Rate of change cuts both ways, though: it is the input that most justifies the investment and the one that punishes neglect hardest, because quickly moving products are exactly where documentation goes stale and where a component quietly stops matching what production renders.

If you are past the threshold, the symptoms are unmistakable, and you probably recognised two or three of these before you finished reading the list.

• Two components do the same job and nobody can say which one is current.
• The design file and production disagree, and both are being actively maintained.
• An accessibility fix gets applied to one button and not to the other four.
• Onboarding a developer means explaining rules that exist nowhere in writing.
• Changing one colour means a search across three repositories and a hopeful commit.
• Nobody can answer "is this pattern approved" without naming one specific person.

What a system nobody maintains actually costs

The common failure is not that a system never gets built. It is that one gets built, presented, admired, and then left behind while the product keeps moving.

A partially adopted system is worse than no system, and this is the part teams do not believe until they live through it. With nothing in place, every screen is a fresh decision and everyone knows it. With a half-adopted library, every screen now carries a question: is this the old way or the new way? Developers hedge by copying whichever component sits nearest. Designers work around the library rather than filing against it. The package keeps its version number and loses its authority, which was the only thing it ever really had.

Then the deprecation problem arrives. Nothing can be removed, because removing it breaks a screen nobody has time to revisit, so the library only ever grows. Two years in there are four button variants, three marked deprecated in a code comment and all four live in production. Untangling that later is product improvement work rather than design work, and it reliably costs more than building the original system did.

There is a quieter cost as well. A neglected system teaches people that internal tools are not to be trusted, and that lesson transfers. The next shared thing you propose, whatever it is, meets a team that has already learned to route around shared things.

The smaller thing to build first

Most teams asking this question sit near the threshold rather than past it. Build the small thing. It delivers most of the value, costs a fraction, and survives being ignored for a month, which the large version does not.

1. Tokens before components. Colour, spacing, type scale, radii, border widths, motion durations. One source, consumed by both design and code. Tokens are cheap, they do not go stale the way prose documentation does, and on their own they remove the most visible category of drift.
2. Fix the four primitives you ship most. Button, input, link, heading. Four, done properly, including the states everybody forgets: focus, disabled, loading and error. Not thirty components, and not the one somebody finds interesting.
3. Write the usage rule beside each one. A component with no rule about when to use it gets used everywhere. One sentence about when not to reach for it is worth more than a page of props documentation.
4. Make the wrong thing harder than the right thing. A lint rule that blocks a raw hex value does more for consistency than any guideline document, because it acts at the moment of the decision rather than three weeks later in review.
5. Only then ask whether it should be a package. Publishing and versioning is real, permanent work. If everything lives in one repository, a shared folder stays the correct answer for far longer than people expect it to.

The sequence matters because tokens are the only part that stays nearly free to change later, while components become load-bearing almost immediately. It lines up with the wider question of what should freeze before a website build starts: decisions that are expensive to reverse go first, and decisions that are cheap to revise wait for real screens and real content. Getting that order right is most of what product design work is actually for.

Forms deserve a specific warning, because they look like a component problem and are not. A field is trivial. A form is a set of decisions about what you ask, in what order, and what happens when an answer is wrong. Our parent company makes that case in a form is a triage instrument, which is why a form belongs in a system as a pattern with rules attached, never as a bag of inputs somebody can assemble freely.

Ownership, versioning and the deprecation you will avoid

A system that ships changes is a product with internal customers, and it needs the ordinary apparatus of one: somebody who decides, a way to request a change, a release note, and a version number that means something to the people reading it.

Two rules keep it honest. Additive changes ship freely; removals and renames get a deprecation window with a stated end date rather than an implied one. And every breaking change carries a migration note naming the screens affected, because "we updated the button" is not an instruction anybody can act on, and it will not be acted on.

The contribution path matters more than the governance model, and teams get this backwards constantly. If a product engineer needs a new variant on a Thursday and the only route is a request that gets triaged next sprint, they will copy the component and edit it. That is not indiscipline. That is the system failing a reasonable request, and the fix is to make the front door faster than the workaround rather than to write a policy about the workaround.

Documentation follows the same logic. Documentation that lives beside the code, generated from the same source, survives. Documentation that lives in a separate tool becomes archaeology within a couple of releases, and then people stop trusting all of it, including the parts that are still correct.

What a design system does not fix

A design system makes good decisions repeatable. It does not make the decisions.

Accessibility is the clearest example. A system helps a great deal, because you fix focus behaviour once and it propagates everywhere. It does not make a product accessible, because most real failures are compositional: heading order, landmark structure, focus management across a route change, and whether anything can be reached at all without a mouse. Run the exercise described in what a keyboard user experiences on your site right now after adopting a system rather than before, and expect it to still find things. Native elements with correct structure will take you further than a beautifully documented custom control every single time.

The second gap is states. Component libraries document the happy path in a suspiciously tidy way, while the screens that decide whether a product feels finished are all the other ones, which is exactly why empty states remain the most neglected screen in a product. A system can hold them, and almost none do, because nobody designs an empty state until a customer has already seen one.

A design system is not a library of components. It is an agreement, and the components are only the part of the agreement you can install.

Where we would start

For a team below the threshold: tokens, four primitives, a usage rule beside each one, and a lint rule that makes the wrong thing awkward. That is a contained piece of work rather than a programme, and it removes most of the inconsistency people are actually complaining about when they ask for a system.

For a team past it: name the owner first and decide everything else second. A system with an owner and half the components will be finished within a year; a system with every component and no owner will be abandoned within one. The abandoned version is the more expensive of the two, because half the codebase has already adopted it and cannot easily be talked out of it.

The concession, and it is a real one: this is conservative advice, and it is wrong for teams building a product family from the start. If you already know there will be four applications sharing one interface, building the system before the second one exists is cheaper than retrofitting it afterwards, and the usual argument about premature investment does not apply. The test is whether the surfaces are certain, not whether they exist yet. If you are genuinely unsure which side of that line you sit on, describe what you are shipping and count the surfaces with somebody who has no stake in the answer.