I recently read John Cutler’s article “Minimally Viable Consistency”, and the concept immediately connected with my day-to-day work because it touches on one of the most persistent misconceptions in technology companies: the belief that consistency means uniformity.
It does not.
Consistency is not about making everything look the same. Consistency is about ensuring that the important parts of the system behave in a predictable, understandable, and sustainable way, even when products, teams, and interfaces need to respond to different contexts.
This is where the idea of minimally viable consistency becomes particularly useful when thinking about the creation and maintenance of a design system, but also about the broader product infrastructure within the same ecosystem.
In a technology company, especially one with multiple products, several teams, different maturity levels, and different delivery speeds, trying to enforce absolute consistency is an operational fantasy. Worse, it is an expensive fantasy. It creates friction, bureaucracy, resistance from teams, and, quite often, a system that exists more to protect itself than to help the organisation deliver better experiences.
The goal of a design system should not be to control every pixel or, at a more macro level, to control every interface across different devices. It should be to define, with clarity, what genuinely needs to be consistent and where flexibility is not only acceptable, but necessary.
The problem: we confuse coherence and consistency with rigidity
Many discussions about design systems start badly because they begin with the wrong question: “How do we make sure everything is consistent?”
The trap is not always obvious, but it becomes clear once we understand how subjective the word “consistency” can be.
The right question is different:
What kind of consistency do we need for the product to remain recognisable, efficient, accessible, and scalable?
That difference changes everything.
A button should follow consistent standards for accessibility, states, behaviour, semantics, spacing, and usage. But that does not mean every product needs to express the same visual intensity, the same level of density, or the same interface composition. This is especially true even within the same product when it is used across different devices. Think of an app that can be used on a laptop, a smartphone, and a TV.
A checkout flow, a technical dashboard, a native mobile app, and a commercial landing page do not have the same goal, the same cognitive rhythm, or the same usage context. Forcing all these contexts to use the same visual solution is confusing a design system with decoration.
A good design system does not eliminate difference. It makes difference legible.
A design system is not a component library
This is the first premise that needs to die conceptually.
A component library is only a visible manifestation of the system. Important, yes, but insufficient as the final representation of a design system.
A mature design system is a decision-making infrastructure. It defines principles, foundations, tokens, components, patterns, contribution criteria, update processes, ownership, documentation, governance mechanisms, and clear ways for the system to evolve.
When this does not exist, the organisation tends to fall into one of two extremes.
On one side, each team solves the same problems in isolation. The result is duplication, inconsistency, technical debt, and fragmented experiences.
On the other side, the design system tries to centralise everything. The result is slowness, review queues, frustration, and teams bypassing the system because it has stopped serving reality and has become more of a production funnel.
Neither extreme scales.
The first is more common in early-stage companies, start-ups, and small exploratory projects. The second appears more often in large companies with many dependencies, where production starts to obey multiple layers of control and refinement before anything sees the light of day.
The concept of minimally viable consistency offers a third way: define a strong, stable, shared core, and allow controlled variation in the layers where product context truly matters.
What should be consistent
Not everything deserves the same level of control.
In a design system, consistency should be strongest in the layers that create trust, reduce costs, and ensure interoperability between teams.
1. Token semantics
Teams should speak the same language when using colour, typography, spacing, elevation, states, modes, and themes. Even when visual values change across brands, products, or platforms, the semantic structure should remain predictable and relatively easy to learn.
2. Predictable component behaviour
A dropdown, modal, tooltip, or input should follow consistent patterns for interaction, accessibility, keyboard navigation, states, validation, and feedback. The user may not see the system, but they feel it when behaviour is inconsistent.
3. Quality criteria
Visual flexibility cannot become an excuse to compromise accessibility, performance, clarity, responsiveness, or usability. These criteria are not optional.
4. A clear contribution and evolution process
Teams need to know when they should use something that already exists, when they should propose a change, when they should create a local solution, and when that solution should evolve into the system. Without this process, the design system becomes dependent on informal conversations and arbitrary decisions.
5. Ownership
Someone must be responsible for maintaining the integrity of the system. Not as visual police, but as a team that ensures local decisions do not create global damage.
This point is critical. If no one is clearly responsible, the system degrades. If only one team is responsible for everything, the system becomes a bottleneck, or the team has to grow to a point where it is no longer beneficial for the company. The right model requires distributed responsibility, but with clear rules.
What should be flexible
Flexibility should exist wherever the experience needs to adapt to the real context of use.
1. Interface composition
Not every product needs to solve the same problems with the same layouts. Composition should be able to vary according to task complexity, information density, device, user maturity, and business objective.
2. Visual expression by product or brand
When a company operates multiple brands, entities, or product families, the system should allow differentiated expression without breaking the shared foundation. The answer is not to duplicate systems. The answer is to separate core, tokens, themes, and components intelligently.
3. Components with specific logic
Not everything belongs in the design system core. Components with business logic, specific dependencies, or limited use should live in shareable or local layers, not in the universal core.
4. Speed of experimentation
Product teams need room to test new solutions, including pushing the limits of the system when necessary. The design system should absorb that learning. It cannot kill exploration before it starts.
Here is the uncomfortable part: many design system teams say they want innovation, but then design processes that make innovation too expensive, or even impossible. Then they complain that teams do not contribute to, or use, the design system. The problem is not a lack of maturity from the teams. It is a system that asks for collaboration but rewards compliance.
A hidden cost: what consistency are we willing to pay for?
All consistency has a cost.
It costs time. It costs coordination. It costs documentation. It costs review. It costs negotiation. It costs maintenance. And, quite often, it costs opportunity.
So, before enforcing consistency, we should ask: what is the return on this consistency?
If consistency reduces bugs, improves accessibility, accelerates delivery, lowers support needs, improves team onboarding, or increases user trust, it is probably worth it. The saving in resources and time can be significant.
If consistency exists only because someone wants two screens to look identical, we may be spending energy in the wrong place.
A design system should protect what is structural, not police what is expressive.
The right architecture for scale
The healthiest way to think about this is in layers.
At the core, we should have the global foundations: semantics, tokens, accessibility, base behaviour, principles, and guidelines.
Above that, we should have core or headless components, focused on behaviour and interaction contracts.
Then, each entity, product, or brand can apply its visual layer, themes, specific components, and composition patterns.
This allows two things to coexist: systemic coherence and contextual freedom.
The alternative is worse: either we create a rigid system that nobody wants to use, or we let every team build its own universe. The first kills speed. The second kills coherence. Both kill the ability to scale.
The role of the design system team
A design system team should not operate as an aesthetic approval department or as component police. That model is obsolete, even if many organisations still pretend otherwise.
The right role is more strategic.
Define contracts. Reduce ambiguity. Help teams make better decisions. Create tools that accelerate real work. Identify emerging patterns. Turn local solutions into reusable capabilities. Maintain the quality of the ecosystem over time.
This requires a shift in posture. The design system team does not own the final experience. It owns the conditions that make good experiences possible repeatedly.
The most common mistake: trying to scale aesthetics before scaling foundations and decisions
Many companies try to solve inconsistency by creating more components or more variations of existing components.
But the cause of inconsistency is rarely just the lack of components. More often, it is the lack of decision criteria grounded in a strong conceptual and functional foundation.
When a team asks, “Can I create this component?”, the answer should not depend on the opinion of whoever happens to be in the meeting. It should depend on clear criteria.
Is it universal or specific? Does it contain business logic? Can it be reused by multiple teams? Does it solve a structural problem or only a local case? Does it affect accessibility or behaviour? Is there something similar in the system already? Does the maintenance cost justify including it?
Without this type of criteria, the design system becomes a political catalogue: what gets in is what is pushed hardest, what is most urgent, or what reaches the right person.
That is not governance. It is improvisation with good presentation. The result is accumulated design and technical debt.
Minimally viable consistency as a leadership principle
The most interesting part of this discussion is that it is not only about design. It is about organisational leadership.
Growing companies constantly need to decide where to align and where to decentralise. A design system is simply one visible expression of that dilemma.
If we centralise too much, teams lose autonomy. If we decentralise too much, the experience fragments. If we do not decide explicitly, each team invents its own answer.
Minimally viable consistency forces us to make adult choices. It does not ask, “How do we control everything?” It asks, “What is the minimum level of alignment required to allow autonomy without creating chaos?”
That is a far more useful question.
The future of design systems is less visual and more operational
As companies work across multiple brands, platforms, themes, devices, and increasingly personalised experiences, the idea of a purely visual design system becomes insufficient.
The future lies in systems that work as internal platforms: agnostic where they need to be agnostic, specific where they need to be specific, automated where there is repetition, and human where judgement is required.
This means better-structured design tokens. It means headless components and separated visual layers. It means living documentation. It means clear contribution processes. It means adoption and impact metrics. It means internal tools that reduce manual dependency. It means design system teams with a product mindset, not a support mindset.
Ultimately, it means accepting that a design system is not a Figma file, an npm package, or a documentation page. It is a continuous coordination mechanism between people, product, design, and technology.
Where the design system will have the greatest impact
If a company wants consistency without losing speed, it needs to stop treating the design system as a repository of final answers.
The design system should offer strong defaults, but it should also create space for better questions.
The right consistency is not the one that eliminates variation. It is the one that allows variation without breaking trust, quality, or scale.
That is the essence of minimally viable consistency applied to design systems: align enough so that teams can move with freedom, without forcing the organisation to pay the invisible cost of fragmentation.
And perhaps that is the most important point: consistency should not be measured by how similar interfaces look. It should be measured by how predictable, sustainable, and evolvable the system that produces them is.