Why Most Design Systems Fail As Deliverables

A team I worked with finished their design system in February and reopened it in May. The first sprint after launch produced eleven exceptions to the new button component, six new variants of a card pattern that the system already had, and a long thread about whether the deprecated icon set should be re-added because two products still depended on it. The system had been declared finished in the same week the team that built it was reassigned, and three months was the gap between the declaration and the obvious fact that nothing about a design system is ever finished.

The pattern is consistent enough across teams to be a category, not an anecdote. A library gets built, ships under fanfare, and then quietly drifts from product reality while the deck announcing it gets reused at three more company all-hands.

What a design system is, when it is working

A working design system is not a library. It is the agreement that produces a library. The components are the visible part, but the components are the result, not the system. The system is the set of decisions about what counts as a component, who can add one, what triggers a deprecation, how exceptions are recorded, and which products are required to use which versions. Without those decisions explicit and someone responsible for them, the library is a snapshot.

Snapshots age. A library shipped in March without anyone responsible for keeping it current looks, by September, like a smaller and less useful version of the production interfaces it was supposed to govern. The teams that have shipped two or three design systems learn this the same way every time, which is by watching the library drift from the product within a quarter and concluding that the system was the wrong size, when the system was actually the wrong kind.

The mistake is mistaking the artefact for the discipline. The artefact is the part that ships. The discipline is the part that keeps shipping. A team that has only the artefact has a component library that decays. A team that has the discipline has a design system that compounds.

Why the deliverable framing keeps winning

The deliverable framing keeps winning because it is the framing the rest of the organisation can buy. A budget cycle has start and end dates. A roadmap has shippable units. A design system positioned as a quarter-long initiative with a launch date is legible to the people who approve initiatives. A design system positioned as a permanent function with no end date is harder to fund, harder to staff, and harder to celebrate.

The pitch that gets approved is the pitch that gets misshaped. A leader signs off on a design system because they have been told it will reduce engineering rework, accelerate the next product launch, and unify the brand across surfaces. Each of those promises is true if the system is a discipline. Each of them is hollow if the system is a deliverable. The same words mean different things depending on what gets staffed after the launch deck closes.

A design system understood as a deliverable also produces the wrong success metric. The team is measured on adoption in the first quarter, hits a flattering number, and the leader who approved the initiative checks the box. By quarter three the adoption number is the same number, except now half of the adoption is forks of the original components rather than uses of the canonical ones, which the dashboard cannot tell apart. The system looks adopted. The system has been worked around.

This is the wrinkle most adoption metrics miss, and the one that takes the longest to surface. Forks look like uses until you read the diffs.

What governance actually does

Governance sounds like a heavy word for what it actually is. In practice it is a small group of people, two to four at most companies, with explicit authority to accept contributions, deprecate patterns, maintain documentation, and adjudicate exceptions. The group does not have to be senior. The group has to be permanent. The system’s value compounds only if someone is responsible for compounding it.

The most common governance failure is the rotating committee. A representative from each product team, meeting fortnightly, voting on changes. The committee form looks democratic and feels collaborative, and it produces design systems that are slow to change in important ways and quick to change in unimportant ones. Representatives advocate for their team’s needs, which is what representatives do. Nobody advocates for the system as a coherent whole, because nobody on the committee is paid to.

The second most common failure is the senior solo owner. A staff designer or principal engineer takes the system on as a side responsibility alongside their main work. The system gets fast decisions while the owner is around and stalls when the owner leaves. The bus factor is one, the documentation drifts because nobody else is in the system every day, and the rest of the organisation slowly forgets who to ask.

The shape that works is the small permanent team. Not a tax on every product team, not a side project of one senior, but a small dedicated group whose job is the system. Two designers, one engineer, sometimes a writer if the documentation deserves it. They take contributions from the wider team, they say no often enough that the system stays coherent, and they stay long enough to see the consequences of their decisions.

The maintenance work nobody mentions in the launch deck

A design system shipped in March produces, over the following twelve months, a body of maintenance work that nobody mentions in the launch deck. New variants requested by product teams. Deprecations of patterns the system shipped with that did not survive contact with users. Token updates because the brand evolved. Documentation rewrites because the original pages assumed familiarity that the next cohort of designers does not have.

A rough estimate from teams that have done this honestly is that maintenance runs at about thirty per cent of the original build effort, every year, indefinitely. A library that took two designers a quarter to build needs roughly one designer a third of the year to keep current, every year. That number does not appear on roadmaps. It appears as quiet attrition of the library’s usefulness when the maintenance does not get staffed.

The maintenance is also where the discipline lives. The choice to deprecate a card variant is a discipline choice. The choice to accept a contribution from a product team is a discipline choice. The choice to leave a pattern in the library even though only one product uses it, because the pattern represents a direction the rest of the products should follow, is a discipline choice. None of these choices look like product work. All of them are the system’s actual product.

What changes when the framing changes

A team that switches from the deliverable framing to the discipline framing usually notices three things in the first quarter after the switch. The system stops being celebrated and starts being used. The contributions slow down because the bar to contribute is now real. The maintenance work starts appearing on someone’s calendar, which means it stops happening in the gaps and starts happening on purpose.

The leader who funded the system as a deliverable sometimes finds the discipline version harder to defend, because there is no second launch to point at. The team running the system has to learn to demonstrate value differently, in steady-state metrics that look small in any single quarter and significant over a year. Time to ship a new flow. Number of one-off interface decisions made per sprint. Drift between the canonical components and what is actually in production.

None of these metrics make a satisfying slide. All of them describe the actual job.

A design system that has been treated as a discipline for three years looks, from outside, exactly like a design system that has been treated as a deliverable for three months. Same library. Same documentation. Same components. The difference is invisible until you ask the team how many of the decisions in the library are still load-bearing, and they can answer the question in real time, because someone has been answering it every week for three years.

The artefact is what the system produces. The discipline is the system.