Why we kill components instead of adding them: the design system diet

The default move with a design system is to add. A new screen needs a slightly different card, someone forks Card into CardCompact, the library grows, and a year in nobody can name half the components in it. The bigger the library, the slower the design reviews, and the more often two designers solve the same problem in two different files.

We invert the default. We kill components more often than we add them, and we treat the library size as a number to keep small, not large. This piece is the rule set we follow, why each rule exists, and where it backfires.

The kill principle

A design system exists to remove decisions from product work, not to host every variant that ever existed. The Atlassian design system frames the same idea and pushes teams toward composition: instead of a wide component with eighteen props, two small components that snap together. Adobe walked the same path when it redesigned Spectrum 2 around tighter primitives.

The rule that follows: every component carries a cost. Documentation rot. Figma analytics noise. Engineering hours when the theme shifts and 200 instances need to migrate. New designers reading three near-duplicates and picking the wrong one. The benefit, reuse, only materializes when the component is genuinely shared. Below the reuse threshold, the cost is the only thing you get.

The entry test (before you add anything)

We use a two-question test before promoting anything into the library, lifted from the pattern Josh Cusick describes in Design systems should do less:

1. Is the pattern already used in three or more places in the product?
2. Is it generic enough that a fourth use case will appear within two quarters?

Both yes means the component can enter. One yes means leave it as a local pattern in the consuming app. Two no means write a snippet in Notion and move on.

This is harsher than it sounds. Most "we need this in the system" requests come in at one yes, sometimes zero. Saying no early is the cheapest moment in a component's life. Once it ships, every removal is a migration.

The kill list (signals to deprecate)

Once a quarter we walk the library with the kill list open. A component is a candidate for deprecation if any of the following are true:

• Fewer than 5 instances across all product files after six months. Figma Library Analytics surfaces this directly under Inserts and Instances; the February 2025 release added the same view for styles and variables, so the rule applies to tokens as well as components.
• More than 30% of instances are detached. Detachment is the signal that the component does not fit the real use case and designers are working around it. The detachment rate is the closest thing the design system has to a satisfaction score.
• A near-duplicate exists. ButtonPrimary, PrimaryButton, BtnCTA. Two components that share more than half their props is a strong signal one of them needs to die.
• No documented owner. Anything in the library that nobody is willing to put their name to maintains itself, badly. The owner field on the spec page is a kill switch. If it goes blank for two quarters, the component goes on the list.
• The pattern can be expressed by composing two smaller components. Card + Heading + Action is a layout, not a component. CardWithActionButton is a component that will fork five ways in a year.

A candidate is not a deletion. It is a deprecation, which means a clock starts.

How to deprecate without breaking consumers

Removing a component immediately is how design systems become hated. The cadence we use, modeled on the Adobe Spectrum deprecation window and the Figma rename pattern Craig Francies documents:

1. Rename the component. In Figma, Button becomes Button [deprecated]. Figma propagates the new name into every consuming file the next time it opens, so designers see the label without anyone sending an email. The same rule applies in code: rename the export, leave a re-export from the old path that logs a console warning in development.
2. Publish the migration path. Every deprecated component gets a one-paragraph "use this instead" note in the spec, with a code diff. If there is no replacement, the deprecation is wrong and you are about to break consumers.
3. Set a removal date. One major version away. Atlassian and Spectrum both run this way. The date lives in the spec page, not in someone's head.
4. Track instance count weekly. The number should drop. If it does not, the deprecation message is failing and the migration path needs sharper documentation, not a hard removal.
5. Remove on the date, not before. If teams have not migrated, the removal is a forcing function. If you push the date, you teach teams that deprecations are optional.

The hard part is step 4. Most design system teams skip it, hit the removal date, find half the product still consumes the deprecated component, and either delay (training: deprecations are optional) or remove (training: the design system breaks things). Weekly tracking with named owners is what closes the loop. The same pattern shows up in our governance approach across consumer projects: instance counts before opinions.

Composition over component

A surprising fraction of "we need a new component" requests collapse when you try to express the pattern as composition. A card with an icon row, a heading, a body, and two CTAs is not a new card variant. It is <Card><IconRow/><Heading/><Body/><ActionBar/></Card>. Five primitives that each do one thing.

The Atlassian composition guide and React's compound-component pattern both make this concrete. The cost is API discoverability: a new designer staring at five primitives has to know they snap together. The benefit is that the system has 5 components doing the work of 50, with no version skew across consumers.

The decision rule we use: a new component earns its slot in the library only if it cannot be expressed as composition of existing primitives within reasonable code. Reasonable means roughly 5 to 8 lines of JSX. Past that, abstraction wins.

The quarterly diet

The cadence matters more than the rules. Once every three months, two people from the design system team walk the library with the kill list. They flag candidates. The flag is public. Consumers have a week to push back. After the week, flagged components enter the deprecation cycle above.

What we measure across the cycle: total component count, count of deprecated-but-still-present components, average instance count per non-deprecated component, and the deprecation completion rate (how often the removal date holds). The first number should drift down or stay flat year over year. The fourth should sit above 80%. A proper design system audit tracks all four and surfaces drift before the rewrite conversation starts.

A library that grows monotonically is a library on its way to a rewrite. The teams that avoid the rewrite are the ones that treat killing as part of the regular work.

Where the diet backfires

Three cases push back on the rule set.

New product surface. When the product is six months old and the team is finding the shape of the UI, aggressive deprecation creates more rework than it saves. Hold the kill list for the first year and let patterns settle.

Industry-specific components with regulatory weight. A medical-device dashboard component that encodes WCAG and FDA constraints is not a candidate for deprecation just because instance count dropped. The cost of getting it wrong elsewhere outweighs the maintenance load.

Vendor handoff. If the design system was built by an outside studio and is being handed back to an in-house team, freeze the kill list during handover. Pruning a system the receiving team does not yet understand teaches them to fear it.

For everything else (production design systems with multiple consuming apps, more than 50 components in the library, more than one designer touching the system per week) the diet is the difference between a system that compounds value and one that compounds the kind of debt we wrote about in 10 design system mistakes that wreck consistency at scale.

Sources

• Josh Cusick: Design systems should do less
• Path to Project: How to govern component sprawl in a design system
• Atlassian Design: Composition overview
• Adobe Design: Introducing Spectrum 2
• Figma Blog: Opening up the data behind your design systems
• Craig Francies: How I handle component deprecation in Figma
• zeroheight: Deprecating in design systems