The Design System Isn't Your Problem. Knowing When to Break It Is.
The Figma comment that ended the discussion: "This doesn't exist in the design system."
Posted on a mockup that solved a real problem. The component was novel — it needed to be, because the user need was novel — but the comment closed the review. The team shipped an existing component that half-fitted the context. Users kept contacting support about the interaction that didn't quite work.
Design system governance fails in two directions. The first is abandonment: teams ignore the system, build whatever fits the sprint, and produce products that share a logo but not a visual language. The second is over-enforcement: teams treat the system as law, force every case into existing components, and produce products that work technically but feel jammed — furniture arranged to match a floor plan designed for a different room.
Both paths produce the same outcome: bad user experiences and a design system that erodes team trust. The over-enforcement path just takes longer to get there.
How Design Systems Die Slowly
Most design system failures don't happen at once. They accumulate through small, locally rational decisions that compound.
A product team needs a data visualization component the system doesn't include. They build one, don't contribute it back, and it diverges from the system's visual language across the next three releases. Another team, six months later, needs the same component and builds their own version. A year after that, the product has four different chart components — none in the system, each with different interaction patterns, each maintained by a different squad.
Alternatively: the same team needs the data visualization component, submits a request to the design system team, waits eight weeks, ships with a workaround in the meantime, then never migrates to the official component when it finally lands because the product has already shipped and the retooling effort doesn't fit in any sprint.
Both paths produce the same state: a design system that reflects how the product used to work, maintained in parallel with a growing collection of one-off components that reflect how it actually works now.
Salesforce's Lightning Design System — one of the most extensive enterprise design systems in production — has been through this cycle. Their public documentation explicitly acknowledges that product teams regularly need to "extend or override" system components, and their current governance includes formal guidance on how to do that responsibly. That acknowledgment didn't appear in the documentation because Salesforce had good governance intentions. It appeared because they watched what happened when teams had no legitimate path to deviate: they deviated anyway, invisibly.
The Three Conditions That Warrant a Break
There are cases where using an existing component is wrong. Not suboptimal — wrong. A design system that can't acknowledge this distinction will always be worked around rather than worked with.
The user need is genuinely novel. If the interaction pattern you're building doesn't exist in the system because no product surface has ever needed it, forcing an existing component into service creates friction the user didn't ask for. Stripe's developer documentation uses interaction patterns — inline code editors, parameter tables with live response previews, contextual API examples — that don't appear in their core product design system. They aren't system failures. They're context-appropriate components for a surface the core system was never designed to serve. The dev docs context is sufficiently distinct that importing the marketing-facing component library would produce a worse result than building purpose-fit components.
The existing component creates cognitive friction in this specific context. A component appropriate for occasional feature discovery may be wrong for a high-frequency workflow. A tooltip that works on an onboarding screen becomes an obstacle when users hit the same interaction 40 times in an hour. The component is technically correct. The context has changed the calculus. "This component exists in the system" and "this component is right for this problem" are different sentences.
The deviation can be contributed back. Breaking the system as a sprint shortcut is a process debt decision — sometimes acceptable, should be tracked and resolved. Breaking it because you've found a genuine gap is different: the responsible path is building the component in a way that could be adopted into the system. The exception becomes a proposal. This distinction matters because it determines whether your break is a one-time patch or a system improvement.
The Permission Structure Nobody Designs
The harder problem isn't identifying when a break is warranted. It's who can authorize it.
Most design systems operate with an implicit permission model: the design system team owns the system, and product teams need approval to deviate. In theory, this prevents fragmentation. In practice, it creates a bottleneck that pressures teams to deviate silently rather than transparently. When approval takes three weeks and the sprint is two, teams build the component without asking and don't tell anyone. The fragmentation happens anyway, but now it's invisible.
The proliferation of AI-generated components has made this worse. Product teams now have frictionless access to generated components that almost-fit the system — visually close enough to pass a quick review, different enough to introduce interaction inconsistencies that compound at scale.
Google's first major Material Design version encountered the rigid-permission failure directly. The hamburger menu — the three-line navigation icon — was so deeply embedded in Material's interaction model that it persisted across Google products long after internal UX research showed users were discovering navigation features in hamburger menus at substantially lower rates than in persistent tab bars or bottom navigation. The system's authority outlasted the evidence behind the specific decision it was enforcing. Changing it required not just a design argument but a governance argument — permission to deviate from a standard that had become institutionalized.
That is the specific failure mode of over-enforcement: not that the system is wrong about everything, but that it stays right about things it has become wrong about because there is no clean path to question it.
What Governance That Works Actually Looks Like
Design teams that use systems well share a structural feature: they treat deviation as a design artifact, not a design failure.
When a component is built outside the system, it's documented — the need it serves, why no existing component fit, whether it's intended as a contribution candidate. The exception is visible and can be reviewed, evaluated, and either promoted into the system or deprecated when something better exists.
This requires a design system team that operates less like a standards authority and more like a platform team — people who build infrastructure that other teams build on, whose job is making deviation easy to do well rather than hard to do at all. The platform team model treats the design system as a living thing that grows from what the product actually needs, not a law that exists above the product.
The question worth asking about any design system is not whether people follow it. It's whether you know what people do when they don't — and whether that path is governed or chaotic.
A design system people never question isn't a well-governed system. It's a system nobody has told them they're allowed to push back on. The difference matters when the product needs to go somewhere the system was never designed to take it.
Cover photo by Egor Komarov via Pexels.