.png)
Consistency is easy to ask for, but building the conditions for it is harder.
When inconsistencies start appearing across a product, the explanation often seems obvious: teams are not following the design system. A designer may have created a new component instead of using the approved one, an engineer may have implemented a slightly different interaction, or a product team may have introduced a pattern that exists nowhere else in the ecosystem. The natural response is usually to push for greater adoption through better documentation, stricter standards or additional review, but that response assumes the design system already gives teams what they need to do their jobs effectively.
Often, it doesn’t.
When a designer creates a new pattern instead of using an established one, it is easy to treat the decision as a failure to follow standards, but repeated deviations deserve more curiosity. The existing component may not accommodate the use case, the documentation may explain what something looks like without providing enough guidance about when to use it, or the pattern a team needs may exist in Figma without an equivalent in code.
There are also situations where teams simply do not know whether a solution already exists, who owns it or where to go when their needs fall outside the documented system. In those cases, inconsistency is not necessarily the underlying problem but rather evidence that something in the system is making the preferred path difficult to follow.
A healthy design system should make reuse easier than reinvention, so when teams repeatedly choose to build something themselves, it is worth understanding what made that choice more practical.
Component anatomy, variants and specifications are useful, but they only address part of what teams need to make good design decisions. Designers also need to understand when a pattern should be used, when another option would be more appropriate, how it behaves outside of an ideal scenario and what to do when a use case falls beyond the documented variants.
Without that context, a component library can be technically thorough while still requiring every product team to interpret the system independently, which inevitably produces different solutions to similar problems.
Strong documentation captures the reasoning behind a pattern alongside the instructions for using it, giving teams enough context to make informed decisions without needing a design-system expert in every conversation.
No design system can anticipate every product need because products evolve, requirements change and teams inevitably encounter scenarios that were not considered when the original library was created. The challenge is therefore not preventing teams from ever needing something new, but establishing a clear path for what happens when they do.
If contributing to the system is confusing, prohibitively slow or dependent on knowing the right person, teams working against delivery deadlines will understandably solve their problems locally. Over time, those local solutions accumulate and the system begins losing the consistency it was intended to create.
A practical contribution model gives teams another option by allowing them to surface an unmet need, determine whether the problem is truly unique or shared across products, and contribute what they have learned back into the system. This allows the design system to evolve alongside the organization instead of becoming a snapshot of how the product worked when the library was first created.
Design systems often occupy an unusual position within large organizations because nearly everyone depends on them while responsibility for maintaining them may be distributed across several teams. When ownership becomes ambiguous, components can fall out of sync, documentation becomes outdated and questions remain unanswered long enough that teams begin creating their own solutions simply to keep work moving.
Eventually, designers stop trusting that the library reflects what is actually available, while engineers develop workarounds to meet delivery commitments, and restoring confidence becomes considerably more difficult than maintaining it would have been.
Clear ownership does not mean one team has to solve every design-system problem, but people should know who maintains the system, how decisions are made, where new needs should be raised and how changes are communicated across the organization.
It is easy to make consistency the responsibility of individual designers and engineers because that is where inconsistencies become visible, but a cohesive product is usually the result of something much larger. Clear documentation, practical governance, defined ownership, accessible contribution models and ongoing communication all create the environment in which teams can actually work consistently.
Design systems are most effective when teams do not have to choose between following the system and solving the problem in front of them, which is why the appearance of another one-off component should prompt more than a reminder to follow the library.
Instead of asking “Why didn’t they use the design system?”, it may be more useful to ask “What did they need that the system wasn’t giving them?”