The Design System

Why teams push back, why maintenance is worth it, and what it actually does for your product and brand

Key Takeaways

A design system only works if teams actually use it. Resistance is real, maintenance is unglamorous – but the payoff in product quality and brand consistency is bigger than most teams expect before they’ve lived with one for a year.

I’ve had the design system conversation more times than I can count.

Everyone agrees the product is inconsistent. Developers build the same component slightly differently each sprint. Designers make subtly different spacing decisions across screens. Something should be done. People nod. Then nothing happens.

Six months later, same conversation. Same nods. Same nothing.

The block isn’t disagreement about whether a system would help. It’s the gap between “this would be useful” and someone actually starting.

Why Teams Resist It

Resistance is predictable once you understand where it comes from. Developers have seen component libraries go stale within months. Designers have worked in systems where Figma didn’t match code. Both groups learned the hard way: the system says one thing, the product does another. So they stopped trusting it.

That history is the real obstacle – not the technical work. A system earns trust the same way it loses it: slowly. One component that works exactly as documented. One pattern that saves 45 minutes. One decision that doesn’t need relitigating because the system already answered it.

The hardest part of a design system isn’t building it. It’s making people believe it helps to using.

What a Design System Actually Is

Not just a component library. A complete system has four layers: design tokens (colour, type, spacing – the foundation everything else builds from), component library (UI pieces with documented variants in both Figma and code), usage guidelines (when and why to use each component, not just what it looks like), and design principles (the values that guide decisions when the guidelines don’t cover the exact situation).

Without all four, you have something useful but incomplete – and incomplete systems drift.

The Quality Difference It Makes

Without a system, consistency requires constant vigilance. The same spacing question gets answered again every week. The same grey gets hardcoded slightly differently by three different developers.

With a system, the right choice is built in. Accessibility compliance is built into components rather than audited after the fact. New screens feel like they belong to the same product. Users don’t notice consciously – but they feel it in how much cognitive work the interface asks of them.

The compounding effect takes time. Year one is mostly investment. But once the system reaches meaningful coverage, the speed of delivery changes noticeably. When Sparkbox tested IBM’s Carbon Design System against coding from scratch, developers completed the same task 47% faster – a median of 2 hours with Carbon versus 4.2 hours from scratch. A broader review across multiple studies finds design teams gaining around 38% in efficiency and development teams around 31% once a system reaches meaningful coverage.

What It Does for the Brand

Brand consistency in digital products isn’t achieved through a PDF brand guide. It’s achieved through the product behaving consistently every time someone uses it – same button radius, same motion speed, same tone in every error message.

A design system makes that possible at scale. Without it, designers and developers make local decisions that are each reasonable in isolation but diverge across the product over time. With it, brand expression is structural – built into the tokens and components, not dependent on everyone having the same taste.

The result: a product that feels like a product, not a collection of features built by different people at different times.

Why Maintenance Is Worth the Effort

The most common failure mode isn’t a bad component library. It’s one nobody maintained.

Components get stale. Products change. A system that isn’t actively owned becomes a museum piece – technically still there, practically ignored. Maintenance needs to be a real part of someone’s role, not a side responsibility. And there needs to be a clear process for when teams need components the system doesn’t have yet – otherwise exceptions pile up and the system fragments from the edges inward.

None of this is glamorous. But it’s what protects the investment. A well-maintained system from two years ago is worth far more than a beautifully launched one from six months ago that nobody touches.

Practical note: design tokens are moving toward a W3C standard (2025). Align to it now and you’ll avoid a migration later.

Where to Start

Audit what already exists. Map the inconsistencies. Find the components that appear everywhere with the most variation – those are your highest-value starting points.

Get design and engineering aligned early. Decisions about component structure, naming conventions, and token architecture need to happen together. Document as you go – not elaborate docs, just enough for someone new to understand why a pattern exists and when to use it.

What to Do Next

1. Audit first. Map the inconsistencies in your current product. That audit is your starting point and your business case.
2. Start with highest-frequency components – buttons, inputs, cards. A small, trusted system beats a comprehensive, ignored one.
3. Get a sponsor before you start. Design systems fail without someone who owns the mandate to maintain them over time.

Sources & Further Reading

• Brad Frost. Atomic Web Design.
• Nielsen Norman Group. Design Systems 101.
• Nielsen Norman Group. UX Debt: How to Identify, Prioritize, and Resolve.
• Interaction Design Foundation. Design Systems.
• Laws of UX. Jakob’s Law.
• Sparkbox. The Value of Design Systems Study: Developer Efficiency and Design Consistency.
• IBM. Carbon Design System.

René Manikofski is a Senior UX Designer with 10+ years of experience in e-commerce and digital product design across Europe. All articles are based on personal professional experience and supported by AI in writing.