Most design systems start with the right intention: consistency, speed, a single source of truth. But somewhere around the 6-month mark, teams start working around the system instead of within it. Components get detached. Overrides pile up. The system that was supposed to prevent chaos becomes the first thing designers ignore.
The problem isn’t the team. It’s that most design systems are built for control — and control, taken too far, makes a system brittle.
The Consistency Trap
A brand system exists to maintain consistency. But consistency doesn’t mean uniformity. A card component that works for a product page won’t work unchanged for a dashboard, an email, a mobile onboarding flow, and a partner microsite. If designers can’t adapt it without breaking it, they’ll detach it — and then it’s no longer part of the system at all.
This is the consistency trap: the stricter the system, the more often it gets bypassed. Every detached component is a silent vote of no confidence in the system’s flexibility.
What Slots Actually Solve
The component slots pattern — popularized in Figma’s recent work but a long-standing concept in component-based development — offers a different architecture. Instead of building components that anticipate every variation through properties and overrides, slots define where customization happens, not what goes there.
A card with a media slot, a content slot, and an action slot can be a product card, a testimonial, a pricing tier, or a blog preview — without ever detaching. The structure holds. The brand guardrails hold. But the content adapts.
For agencies managing multiple client brands on a shared system base, this is significant: the component contract stays consistent, the brand expression changes per client. One set of components, seven different visual identities.
The Real Governance Problem
Design system governance isn’t about locking things down — it’s about knowing which parts of a component should be locked and which should flex. A logo should never change. A container’s padding might need to. The primary typeface is fixed. The text content inside a heading isn’t.
Systems that treat everything as equally sacred end up with one of two failure modes: either designers override everything (the system is too rigid) or nothing is consistent (the system is too loose). Slots — and more broadly, the concept of flexible-by-design components — force explicit decisions about what the system controls versus what it delegates.
This is where most system documentation falls short. It describes what components look like, not what they protect. The honest version of a component spec isn’t “here’s how it renders.” It’s “here’s what you’re not allowed to change, and here’s what’s yours to fill.”
TL;DR
A design system that can’t bend will get broken. Build components that define structure and protect brand decisions — but leave intentional space for legitimate variation. That’s not a compromise on consistency. It’s what consistency actually looks like at scale.