Design Systems Are Great Until Someone Has to Maintain Them—Who Really Owns Components?

[vp_eng_keisha]

Let me start with a confession: we invested heavily in building a design system 18 months ago. Beautiful components, comprehensive documentation, governance processes—the works.

Six months later, 35% of our components were stale or unused. Designers were creating one-off variations instead of using the system. Engineers were copy-pasting code instead of importing components.

The question nobody wanted to ask: Who actually owns maintaining this thing?

The Ownership Void

Here’s what typically happens:

1. Design team creates the system (visual specs, Figma libraries)
2. Engineering team builds it (React components, Storybook)
3. Product teams use it (sometimes)
4. Nobody maintains it (definitely)

Three months after launch, you have:

• Components with deprecated dependencies
• Design tokens that don’t match implementation
• Accessibility issues discovered but never fixed
• New variants requested but never built
• Documentation that’s outdated

Sound familiar?

What We Changed: The Pairing Model

We shifted to design + engineering pairs assigned to component categories.

Here’s the structure:

• Forms category: Sarah (designer) + Mike (frontend eng)
• Data display: Lisa (designer) + Chen (frontend eng)
• Navigation: Maya (designer) + Jordan (frontend eng)

Each pair owns:

• Visual design evolution
• Implementation quality
• Documentation accuracy
• Accessibility compliance
• Versioning and deprecation

The trade-off: This takes about 20% of senior IC time from each person. That’s significant.

The payoff: Component staleness dropped from 35% to 8%. System adoption increased from ~60% to ~87%.

What This Actually Looks Like

Monthly component health reviews (30 minutes per category):

• Review usage analytics (which components are actually used)
• Triage requests from product teams
• Flag deprecated patterns for removal
• Update documentation for common questions

Quarterly component audits (2 hours per category):

• Accessibility testing and fixes
• Dependency updates
• Performance profiling
• Design-code drift checks

On-demand support (varies):

• “Office hours” once a week where teams can request component updates
• Slack channel for component questions

The Hard Part: Justifying the Investment

Let’s be real: Not every company can afford 20% of senior IC time for design system maintenance.

Our CTO challenged this during planning: “Is this the best use of our most expensive people?”

Our argument:

1. Prevents tech debt accumulation - Incremental maintenance is cheaper than periodic rewrites
2. Enables product team velocity - Teams move faster with reliable components
3. Consistency at scale - 8 product teams building on same foundation
4. Reduces design-eng friction - Single source of truth for both disciplines

The ROI showed up 6 months in when we shipped a major redesign in 3 weeks instead of projected 8 weeks because we could update design tokens and component styles centrally.

The Enforcement Problem

Here’s the question I’m still wrestling with: How do you encourage adoption without becoming the design police?

We tried:

• Blocking PRs that don’t use the system - Created resentment, slowed teams down
• Mandatory design system training - People attended but didn’t change behavior
• Making the system obviously better than building custom - Better docs, faster implementation, accessibility built-in
• Highlighting wins - “Team X shipped in half the time using system components”

But we still see teams building one-offs when they’re under deadline pressure. The system is only valuable if people actually use it.

What I’m Curious About

For those of you running design systems:

1. Who owns maintenance at your org? Single team? Distributed ownership? No one?
2. How much time investment do you allocate? Is 20% of senior IC time reasonable or excessive?
3. How do you measure success? Usage metrics? Velocity improvements? Something else?
4. How do you enforce adoption without being authoritarian? What actually works?

Would love to hear what’s working (or not working) for others. The design system maintenance problem feels like one of those things everyone struggles with but nobody talks about openly.

[maya_builds]

Keisha, this is EXACTLY what I was trying to describe in my post about design-eng collaboration!

The pairing model you described is the key. At my company, we do something similar:

Monthly ‘design system office hours’ where any product team can request component updates or ask questions. The engineering + design pairs rotate hosting these sessions.

What’s worked for us on the adoption front:

Show, don’t mandate. We created a quick-start template that uses design system components. New features that start from the template ship 40% faster than those built from scratch. Product teams noticed and started asking for more templates.

Component showcase. We have a Slack channel where we highlight when teams successfully use system components for complex use cases. Social proof is powerful—teams see “oh, the Payments team used Modal + Form + Validation and it just worked.”

But I’m still wrestling with the same enforcement question you raised. Some teams will ALWAYS build one-offs under pressure.

My question for you: How do you handle when product teams request component updates but the update would break existing uses? Do you version components? Fork them? How do you balance new requests vs. stability?

The pairing model is brilliant for maintenance, but governance gets tricky when 8 product teams all want slightly different things from the same component.

[product_david]

Playing devil’s advocate again (sensing a pattern here…)

Keisha, is 20% of senior IC time really justified for component maintenance? Let me do the math:

• Senior designer: ~K salary
• Senior frontend engineer: ~K salary
• 20% time = ~K/year in fully-loaded cost

For a team of 6 people (3 pairs), that’s roughly K/year in maintenance cost.

Question: How do you quantify the business value of going from 35% stale components to 8%?

I don’t doubt there’s value—your redesign story (3 weeks vs. 8 weeks) is compelling. But from a product budget perspective, I need to understand:

1. What’s the alternative cost? (If we DON’T invest 20% time, what breaks?)
2. What if you accepted some staleness and focused that time on new features?
3. Is there a minimum viable maintenance level that’s cheaper but still effective?

Your adoption numbers (60% → 87%) suggest teams see value. But 13% of teams still aren’t using it despite significant investment.

Alternative hypothesis: What if you invest in making contribution easier instead of dedicated maintainers? Lower the barrier for product teams to submit component improvements themselves?

I recognize I’m being very ROI-focused here. But in constrained budget environments, every K investment needs to compete with hiring another engineer or shipping another feature.

Genuinely curious how you make this case to finance/leadership. What’s the business metric that justifies the cost?

[eng_director_luis]

Keisha, the pairing model resonates. We’ve done something similar at our company with good results.

What makes component ownership work:

1. Clear ownership boundaries - Each pair has autonomy within their domain
2. Easy contribution path - Good docs, clear PR templates, automated tests
3. Regular triage - We do bi-weekly component request reviews, not monthly

David’s ROI question is fair. Here’s how we’ve quantified it:

Automated staleness alerts - We built tooling that flags components with:

• No usage in last 90 days (candidate for deprecation)
• Dependencies >6 months old (security/maintenance risk)
• Design-code drift (Figma vs. implemented)

This made the maintenance cost visible. Before dedicated owners, we were accumulating ~K in deferred maintenance annually (estimated cost to fix accumulated issues).

The key success factor from my experience: Make contribution easy.

We tried single-owner model first. Failed because knowledge silos. Pair model works better for:

• Knowledge sharing (neither person is a single point of failure)
• Design-engineering alignment (forces collaboration)
• Code review quality (pairs already understand context)

On enforcement: We don’t enforce at PR level. Instead:

• New features start with “which existing components can we use?” in design review
• We track “custom component debt” as a metric (new one-offs created)
• Quarterly: Product teams present cases for one-offs, we fold common patterns back into system

The goal isn’t 100% adoption. It’s sustainable common foundation + room for innovation.

[cto_michelle]

This discussion hits on something I’ve been thinking about a lot: design systems are infrastructure, and infrastructure requires investment.

David, your ROI question is the right one to ask, but here’s the reframe:

Would you question spending K/year on API infrastructure maintenance? Database administration? DevOps tooling?

Design systems are product infrastructure. The ROI isn’t always direct feature velocity—it’s:

• Reduced decision fatigue (teams don’t re-solve solved problems)
• Consistent user experience (brand coherence at scale)
• Onboarding speed (new engineers productive faster)
• Accessibility baseline (compliance built-in)

At our scale (120 engineers, 8 product teams), we can’t afford NOT to invest in this.

But Keisha, I’d add nuance: 20% time works for mature engineering orgs. Most startups can’t afford this until Series B+.

Our approach to scaling:

• Lightweight governance for small orgs - Single design-eng lead, community contributions
• Dedicated pair ownership at scale - Once you hit 50+ engineers, the investment pays off

On enforcement: We don’t enforce through process. We enforce through making the system the path of least resistance.

• Better documentation than building custom
• Accessibility/performance testing built-in
• Design QA approval faster for system components

Teams that build one-offs now have to justify why custom is better. Usually it’s not.

Question for minimum viable maintenance: What’s the smallest team size where dedicated design system ownership makes sense? My hypothesis: 30-40 engineers. Below that, lightweight governance works.