Design Systems Die from Addition, Not Neglect: Why Most Teams Have Too Many Components

The Default Move Is Killing Your Design System

The default move in every design system is to add. A new screen needs a slightly different card component, so someone forks Card into CardCompact. Another team needs a variant with a different layout, so they build CardGrid. A third team needs a promotional card with a badge, and CardPromo joins the library. The component count climbs. Documentation rots within a quarter. Figma analytics noise grows. A year in, nobody can name half the components in the library, and the team is spending more time managing the system than building with it.

This pattern is not a failure of execution. It is a failure of default behavior — and it is the primary reason design systems lose organizational trust.

Per the zeroheight 2026 Design Systems Report, buy-in satisfaction for design systems dropped from 42% to just 32% year over year (source). Gartner’s 2025 Hype Cycle moved design systems from the “Peak of Inflated Expectations” into the “Trough of Disillusionment” (source). The conventional narrative blames understaffing, weak governance, or poor documentation. Those are symptoms, not causes. The root cause is simpler and more uncomfortable: most design systems have too many components, and the default instinct to add rather than remove is the primary driver of failure.

Here is what this article argues: the teams that maintain coherent, trusted design systems in 2026 are not the ones with the largest component libraries. They are the ones that kill components as aggressively as they create them. They treat library size as a number to keep small, and they have a repeatable framework for saying no.

Every Component Carries a Cost That Compounds

A component in a design system is not free. The moment it enters the library, it begins accruing a maintenance tax that compounds with every release:

• Documentation rot. Every component needs usage guidelines, prop documentation, accessibility notes, and visual examples. A quarter after creation, at least one of these is out of date.
• Figma analytics noise. Every component adds to the instance count, detachment rate, and variant matrix that the team must monitor. More components mean more signals to evaluate, more false positives, and more time spent deciding what is healthy.
• Engineering migration cost. When the theme changes, the framework upgrades, or the design language evolves, every component must be updated and tested. A component with 200 instances across five products costs substantially more to migrate than a component with 10 instances in one product.
• Cognitive load. New designers and developers must learn which of the five button-like components is the right one for their use case. The larger the library, the more likely they are to pick the wrong one or build a custom solution.

Adam Arant, who runs one of the most disciplined design system operations documented in 2026, uses a specific threshold: any component with fewer than five instances across all product files after six months is a candidate for deprecation (source). The reasoning is straightforward: below five instances, the reuse benefit is negligible, and the maintenance cost is the only thing you are collecting.

Roberto Moreno Celta’s Component Maturity Model formalizes this intuition into a precise framework (source):

Stage	Instances	Abstraction Level	Maintenance Cost	Reusability	Action
Snowflake	1	None	Low	0%	Keep as one-off
Twin	2–3	Copy-paste with tweaks	Medium	20%	Wait for 3rd instance
Pattern	4–7	Shared classes with modifiers	Medium	60%	Consider abstraction
Component	8–20	Props, slots, composition	Low	80%	Full abstraction
Primitive	20+	Foundation for other components	Very Low	95%	Atomic building block

The critical insight is the gap between Stages 1 and 2. Most teams skip straight from “two instances” to building a full component with 47 props. The maturity model says: wait until you have seen the pattern four times before you abstract. Two is a coincidence. Eight is a pattern.

The 80/20 Trap: Why More Components Mean Less Value

The design system field has a size obsession. Teams proudly announce “we have 200+ components in our library.” The number is treated as a proxy for maturity, investment, and organizational commitment.

The data tells a different story. Sedrak, writing in the Design Systems Collective, analyzed why design systems break at scale: “A good design system does not die from a lack of components. It dies from trying to be universal everywhere” (source). The symptom is a Button component with 30 props, a Card with 20 boolean flags, and a file called theme.ts that grows faster than the component count. Every decision was locally rational. The cumulative effect is a system that nobody can safely change.

The component overload problem is quantified by data from the Drift Score project, which measured distinct visual values in production codebases. Pawel Klasa’s audit of major sites revealed that even Apple’s AirPods marketing page — the company synonymous with design discipline — had 52 distinct spacing values against a healthy range of 6–16 (source). The BBC homepage had 25 spacing values. GOV.UK, widely considered the least glamorous of the three, scored the best with 5 text colors and the tightest spacing distribution. The correlation is not about design reputation. It is about governance discipline.

The findings from zeroheight’s 2026 report back this up: only 8% of teams call their system “very stable,” while 44% call it unstable or very unstable. Only 40% have an automated token pipeline, meaning most teams are holding the line by hand, which does not scale past 20–30 components (source). The 60% of teams without automated pipelines are the ones whose systems silently accumulate detached instances, hardcoded hex values, and undocumented variants.

The pattern is consistent across every study: teams that build more components do not build better systems. They build systems that cost more to maintain, are harder to navigate, and produce less reliable output.

The Kill List: A Production Framework for Pruning

The alternative to passive accumulation is active pruning. Adam Arant’s framework, which he calls the “design system diet,” is the most concrete implementation of this approach documented in 2026. It is structured around a quarterly kill list with five criteria (source):

1. Low usage: Fewer than 5 instances across all product files after six months.
2. High detachment: More than 30% of instances are detached from the library — the signal that the component does not fit the real use case.
3. Near-duplicate exists: Two components that share more than half their props and serve the same purpose.
4. No documented owner: Anything in the library that nobody is willing to own for two consecutive quarters.
5. Composition possible: The pattern can be expressed by snapping together existing primitives in 5–8 lines of JSX.

The deprecation cycle follows a structured cadence:

// Step 1: Rename with warning
// In Figma: Button → "Button [deprecated]"
// In code: Rename export, leave re-export with console.warn
export { ButtonV2 as Button } from './ButtonV2';
// Original Button renamed to __ButtonLegacy with console.warn

// Step 2: Publish migration path (one-paragraph diff)
// "Replace <Button variant="primary" size="large"> with <Button size="lg" intent="accent">"

// Step 3: Set removal date (one major version away)
// Deprecated: v3.2 → Removal: v4.0

// Step 4: Track instances weekly, don't push the date
// < 80% migrated by removal date → paired migration sessions

The metrics that matter are not adoption rates or npm downloads. They are:

• Total component count — should stay flat or drift down year over year.
• Deprecation completion rate — the percentage of removal dates that actually hold. Arant targets >80%.
• Average instance count per non-deprecated component — rising indicates that the surviving components are genuinely shared.
• Count of deprecated-but-still-present components — falling indicates the migration pipeline is working.

A library that grows monotonically is, in Arant’s words, “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, not as a crisis response.

Composition Replaces Configuration

The most effective structural defense against component bloat is composition over configuration. Instead of building a single component with 30 props to handle every possible use case, build five small primitives and let consuming teams snap them together.

The difference is visible in code:

// ❌ Configuration-heavy approach: one component, 30 props
type CardProps = {
  variant: 'default' | 'compact' | 'promo' | 'billing' | 'onboarding';
  showIcon?: boolean;
  iconPosition?: 'left' | 'top';
  showBadge?: boolean;
  badgeVariant?: 'new' | 'beta' | 'deprecated';
  showFooter?: boolean;
  footerLayout?: 'single' | 'split' | 'stacked';
  // ... 20 more props
};

// ✅ Composition approach: primitives that snap together
function Card({ children }: { children: React.ReactNode }) {
  return <div className="card">{children}</div>;
}

// Usage: assemble at the product layer
<Card>
  <Card.Icon icon={billingIcon} />
  <Card.Heading>Billing Settings</Card.Heading>
  <Card.Body>
    <BillingForm />
  </Card.Body>
  <Card.Footer>
    <Button intent="accent">Save</Button>
  </Card.Footer>
</Card>

Sedrak’s analysis of the composition pattern is precise: “If two UI fragments look the same but have different reasons to change, do not rush to merge them” (source). The rule of thumb is that a component earns its slot in the library only if it cannot be expressed as a composition of existing primitives within roughly 5–8 lines of JSX. Past that, abstraction wins.

The cost of this approach is front-loaded — you need to educate teams on when to compose and when to create. But the benefit compounds: 5 primitives can do the work of 50 components, with zero version skew across consumers and dramatically lower migration cost when the design language evolves.

When the Diet Backfires: Honest Limits

The kill-list approach is not universal. There are three scenarios where aggressive pruning generates more cost than it saves:

New product surfaces. During the first 6–12 months of a product, visual patterns are still settling. A component that seems like a one-off today may be the foundation of a pattern next quarter. Arant recommends holding the kill list for the first year and letting patterns stabilize before pruning (source).

Regulated domains. A medical-device dashboard component that encodes WCAG and FDA constraints is not a candidate for deprecation just because instance count is low. The cost of getting it wrong outside the system outweighs the maintenance cost inside. The same applies to financial reporting components, accessibility-certified patterns, and any component whose correctness is audited.

Vendor handoffs. If a system was built by an outside studio and is being handed off to an internal team, freeze the kill list for the first quarter. The receiving team needs time to build the mental model needed to judge kill candidates.

Outside these three exceptions, the diet pays for itself within two quarterly cycles. The teams that avoid it are the ones whose libraries grow monotonically until a rewrite becomes inevitable.

Three Moves for 2026

The research and production case studies converge on three actionable steps that any design system team can implement this quarter:

1. Run a quarterly kill list. Set a recurring calendar event. Two people from the design system team walk the library with the five criteria above. Flag candidates publicly. Give consumers one week to push back. Then move into the deprecation cycle. The first pass will be the hardest. Subsequent passes become routine.

2. Measure pruning, not just adoption. Most teams track adoption rates and component usage. Those metrics incentivize addition. Instead, track the metrics that incentivize health: total component count (flat or down), deprecation completion rate (>80%), and average instance count per non-deprecated component (rising). A dashboard that shows these three numbers is a dashboard that surfaces the real state of the system.

3. Replace variants with composition. The next time someone requests a new component variant, ask: “Can this be expressed as a composition of existing primitives in 5–8 lines of JSX?” If yes, ship a documentation example instead of a new component. If no, the use case is genuinely new, and the component deserves a slot — with the kill-list criteria already applied from day one.

These three moves are not a complete design system strategy. But they are the minimum viable intervention for a system that is silently accumulating weight. The data is clear: the teams that control bloat are the teams that keep their systems healthy. The teams that let it accumulate are the teams that end up in a rewrite cycle, wondering how they got there.

The default move is to add. The winning move is to know when to stop.

---

This article extends the analysis of design system operational health covered in Design Systems Are Infrastructure: The Operations Gap That Observability, Lifecycle Management, and Golden Paths Must Close, which examines the measurement and lifecycle practices that make pruning possible. For the token-level foundation that prevents bloat at the source, see Design Tokens in 2026: The 84% Adoption Trap.