Design systems die after launch, not on launch day

A design system rarely fails at launch. It fails months later, when a team ships a screen with a one-off color and nobody writes down why. What holds the system up after that is maintenance process, not the component library. Versioning, deprecation and a contribution path decide whether it survives.

The launch is the easy part

Launch day is a coordinated effort with a deadline and a visible owner. The library ships, the docs page opens, and the first teams adopt it because they helped build it.

The months after that have none of those conditions. There is no deadline, no launch channel, and no shared attention.

Carbon, IBM’s design system, models this in its Product Development Lifecycle page. It splits contribution into discovery, delivery, and launch and scale. The page states that an asset becomes stable in that last phase, so stability is a later stage and not the starting line.

Nielsen Norman Group makes the same point in Design Systems 101. The article calls a design system “not a one-and-done solution” and says the system keeps evolving as teams send feedback. It also names the cost: building and maintaining one is time-intensive and needs a dedicated team.

The failure makes no noise. Nobody deletes a design system. People stop importing from it, one file at a time.

Maintenance is process, not the library

A component library is an artifact. It has no opinion about what happens when a caller needs something the library doesn’t offer.

NN/g separates the two parts of a design system: the repository and the people who manage it. The repository holds the style guide, the component library and the pattern library. The second part is the one that decays.

Process answers the questions the library can’t. Who decides when a component changes. How a breaking change reaches the callers. Where a team asks for something new. What happens when the request is refused.

A library with no process behind it degrades into a snapshot. It still installs, and it still looks correct in the docs, while the product moves away from it.

What becomes a component, and what stays local

Not every repeated element earns a place in the system. The decision is about reuse and cost, not about tidiness.

GOV.UK Design System publishes contribution criteria that answer this directly. A proposal has to be useful, meaning evidence shows many teams need it. It also has to be unique, meaning it doesn’t duplicate what already exists.

The criteria for publication add three more. The implementation has to be usable in user research, consistent with the existing styles and components, and versatile enough to serve a range of services.

Versatility is the one that predicts maintenance cost. A date input that serves a single service will need changes the moment a second service arrives.

When in doubt, keep it local. An element used on two screens of one product, with one owner and no reuse plan, is cheaper to keep in the product. The Carbon lifecycle page states a similar boundary for a different reason: it doesn’t take ownership of full applications or third-party tooling.

Move the element into the system when a second team needs it, or when the third copy appears. Both signals mean someone else is already paying for the duplication.

The component that accepts anything

A component with a prop for every value is a stylesheet in disguise. The wrapper looks like a system asset, and the design decisions live at the call site.

Carbon’s component checklist shows the opposite pattern. Its design spec requirements demand that specs use the color tokens, type tokens and spacing tokens of the system, and that colors stay tokenized. The page gives the reason: tokens reduce the maintenance burden and make theming possible. The tokens and theme guide covers how that token set becomes a theme.

A prop that takes a raw color, a raw spacing value or a free-form style object removes that guarantee. The token set stops being the source of truth, because the caller can set any value without touching the system.

The check is mechanical. Count the props that accept a raw value instead of a named option. Each one is a place where the rules can be broken without a review.

Two limits keep the rule usable. A layout component needs to accept width and position, because the system can’t know the page. And a wrapper that passes a class name through exists in almost every real system, as an escape hatch.

The distinction is whether the escape hatch is recorded. An unrecorded escape hatch becomes the normal path within two quarters.

Versioning and deprecation

Versioning is a promise about the contract, not about the code. The number that matters is the one a caller reads before updating.

Semantic versioning gives the shape. A patch changes nothing observable, a minor version adds, and a major version breaks. The hard part is agreeing on what counts as breaking. A renamed prop, a changed default and a removed visual state all break callers even when the markup is identical.

Deprecation is the part most systems skip. It needs four fields written down at the moment of the decision: what is deprecated, what replaces it, who owns the migration, and the date the old path is removed.

GOV.UK Design System sets a comparable expectation for the resources it links. A community resource has to answer support tickets within one month and stay no more than three months behind the latest version of GOV.UK Frontend. Those are maintenance terms, published in advance.

The window matters more than the date. A deprecation with no removal date accumulates parallel paths, and each path doubles the surface the system has to test.

Carbon handles the same problem with status instead of dates. Its component checklist maps each asset to a status, from Draft and Preview candidate through Preview to Stable, and ties those statuses to the phases of the lifecycle. Only the Carbon team moves an asset from discovery to delivery, and the page notes that not every proposal advances.

Google’s Material Components for the web keeps the requirements for a new component in a contributing guide that anyone can read before proposing one. A component that can’t be tested can’t be maintained by someone else.

The contribution path

A contribution path is the route from “we need this” to “the system has this”. If the route is unclear, teams build locally and the system loses its claim on the product.

USWDS, the United States Web Design System, publishes its route in full. Anyone can suggest a component, starting with a GitHub discussion. If the discussion gathers support, the core team turns it into a formal proposal, and the proposal gets a 45-day comment period before the team decides.

The 45 days are the interesting detail. A long public window costs speed and buys legitimacy, because a component that enters the system with dissent attached enters with known objections (USWDS).

USWDS also runs feature requests and bug reports through public backlogs, where upvotes and comments set priority. That gives a team a second option besides building locally: adding weight to an existing request.

Three properties make a contribution path work. It is written down. It has an owner who answers. And it has a rejection answer, so a team learns why a request was declined instead of guessing.

Record the exception, don’t ban it

Every rule in a design system will be broken at some point. What matters is whether you can see it happen.

A recorded exception carries five fields: the rule it breaks, the reason, the owner, the date, and the condition that ends it. The last field turns an exception into a decision instead of a habit.

An unrecorded exception is invisible in the worst way. It looks like a normal file in the product, and it looks like a normal component in review.

A short file in the repository does the work. One line per exception, reviewed on the same cadence as the code, with a count that anyone can read.

The useful part is the count. A system with four open exceptions is a system with four known gaps. A system with forty is a system whose rules no longer describe the product.

What to measure after launch

Three numbers tell you whether the system is holding, and none of them is the size of the library.

Adoption by team: the share of screens built from system components instead of local copies, measured by imports or by counting duplicate implementations.
Open exceptions: how many are recorded, how old they are, and how many passed their end condition without closing.
Time to ship a new screen: the lead time from a design spec to a shipped screen, measured for a first-time contributor as well as for a regular.

Two more help on the maintenance side. Time to close a bug reported by another team, and the share of deprecations finished on their published date.

Measure the first number per team, not in aggregate. A single strong adopter can carry the average while three teams build around the system.

When a design system isn’t worth it

A design system is a bet on reuse over time. When the reuse isn’t there, the maintenance cost has nothing to pay for it.

NN/g lists the conditions that make the bet fail. The work is time-intensive and needs a dedicated team. Teaching people how to use the system takes time. And projects may be perceived as static one-off creations that need no shared components.

That points to three real cases against building one. A single product with a single team that already shares a channel and a review habit. A team small enough that nobody owns maintenance. A product whose lifecycle is shorter than the time the system takes to pay back its first year.

In those cases a shared stylesheet, a documented type scale and a review habit cover most of the value at a fraction of the cost.

While the product sits in one of these cases, keeping a system running costs more than it returns. The signs that the time has come are in the post on building your own design system or adopting a library.

Where the NN/g articles disagree

Three articles from the same publisher don’t agree on who runs a design system.

For Design Systems 101, a system needs people dedicated to it, and that goes on the bill. Lean design system teams reports that most teams have two to five people, often splitting system work with product work, and treats the small size as a deliberate choice. The two texts disagree on whether the team has to be dedicated.

They also disagree on what counts as progress. The 101 article anchors the value of a system in scale: dozens of teams and thousands of screens. Design system maturity says maturity isn’t linear, adoption never ends and systems regress. A team of ten and a company of ten thousand can both have a mature system. The two texts disagree on scale as the ruler.

They agree on very little. The system needs owners, and it keeps changing after launch.

Verify before you call it maintained

Confirm every component has an owner named in the repository.
Confirm the contribution path is published, with a stated response time.
Confirm each deprecated asset has a replacement, an owner and a removal date.
Confirm the token set is the only path to a color, a type size and a spacing value.
Confirm the exception log is readable, current, and counted on a schedule.
Confirm the adoption number is reported per team, not as a single average.
For each of the three metrics, name who reads it and what that person does when it gets worse.

The design system that survives launch is rarely the one with the largest library. It is the one with a documented route for the next request, a dated plan for the next removal, and a log that shows where the rules already broke.