Consistency vs. Cohesion: Designing Connected Product Ecosystems

Consistency is one of the first principles many designers learn: make similar things look and behave similarly so customers don't have to relearn the product.

That's good advice. But in a large product ecosystem, strict consistency can become the wrong goal.

Different products may serve different personas, devices, environments, and Jobs to Be Done. Forcing every experience to look and behave exactly the same can make the system technically consistent while making individual workflows less effective.

The stronger goal is cohesion: an ecosystem that feels connected and understandable even when parts of it need to behave differently.

Consistency Creates Predictability

Consistency reduces cognitive load. When customers encounter familiar navigation, terminology, interaction patterns, components, and visual language, they can transfer what they already know to the next task.

It also creates operational benefits. Shared components and patterns can improve accessibility, reduce duplicated design and engineering work, make quality easier to maintain, and speed delivery.

For foundational patterns, consistency is usually valuable.

But consistency is a means to an outcome—not the outcome itself.

Cohesion Creates a Connected System

Cohesion asks a broader question: Do the different parts of the ecosystem feel like they belong together and help the customer move successfully across the experience?

Two workflows can be cohesive without being identical.

A technician using a mobile product in the field may need larger targets, fewer steps, offline behavior, and fast access to a narrow set of tasks. An administrator doing configuration on a desktop may need greater information density and more powerful controls.

Making those interfaces identical would be consistent. Designing each appropriately while preserving shared language, mental models, data, and interaction principles creates cohesion.

Standardize the Things Customers Shouldn't Have to Relearn

A useful way to decide what should be consistent is to ask whether variation creates unnecessary learning.

Navigation principles, terminology, permissions, status language, accessibility behavior, common controls, and core interaction patterns are often good candidates for standardization.

If 'asset,' 'work order,' or 'priority' means something different in every product, the customer isn't experiencing flexibility. They're experiencing fragmentation.

The same applies to shared actions. If save, search, filtering, error handling, or notifications behave unpredictably across the ecosystem, variation creates cost without creating customer value.

Allow Variation When Context Changes the Job

Variation becomes useful when the context meaningfully changes what the customer needs.

Device is one example, but not the only one. Role, expertise, frequency of use, environment, risk, workflow complexity, and the Job to Be Done can all justify different experiences.

The question shouldn't be 'How do we make this screen match the other product?' It should be 'Which parts need to remain familiar, and which parts should adapt because the customer's context is different?'

Intentional variation is very different from accidental inconsistency.

Shared Capabilities Need Shared Mental Models

This becomes especially important when an ecosystem contains capabilities that appear across multiple products or verticals.

Asset management, work orders, inventory, permissions, compliance, notifications, reporting, and other capabilities may support many different customer journeys.

If every product independently defines those capabilities, duplication goes beyond code. Teams can create competing terminology, different rules, conflicting interaction models, and inconsistent data expectations.

A cohesive ecosystem treats shared capabilities as part of a larger system. The experience can adapt to context while the underlying mental model remains recognizable.

A Design System Helps, But It Can't Solve This Alone

Design systems are powerful tools for consistency. They give teams reusable components, patterns, accessibility guidance, and visual language.

But a design system can't decide whether two workflows should actually be the same.

Teams can use identical components and still create a fragmented experience. They can also create a highly cohesive experience using different layouts when the context requires it.

The design system answers part of the how. Product and experience architecture still need to answer what should be shared, what should vary, and why.

Govern Principles, Not Every Pixel

Large ecosystems need governance, but overly rigid governance can encourage teams to follow a pattern even when it doesn't serve the customer.

I prefer governing the things that protect customer understanding and product quality: shared terminology, accessibility expectations, core interaction principles, common capabilities, data relationships, and proven patterns.

Then give teams room to solve the specific customer job within those guardrails.

That creates consistency where it reduces friction and flexibility where it creates value.

A Practical Consistency vs. Cohesion Check

When deciding whether experiences across products should match, ask:

• Is this the same customer Job to Be Done, or only a similar-looking feature?

• Would variation force customers to relearn something they already understand?

• Does the device, role, environment, or workflow meaningfully change what the customer needs?

• Is this a shared capability that should have a common mental model across the ecosystem?

• Are differences intentional and evidence-based, or simply the result of different teams designing independently?

• Can the design system support the experience, or does the problem require a broader product or capability decision?

• Will this choice make it easier or harder for customers to move between products?

Design for a Family Resemblance, Not Identical Twins

A mature product ecosystem shouldn't feel like a collection of unrelated products. It also doesn't need every experience to be identical.

Customers should recognize the family: shared language, principles, mental models, quality, and behavior where familiarity matters.

Within that family, individual experiences should be allowed to adapt when the customer, context, or job genuinely changes.

Consistency gives customers predictability. Cohesion gives the ecosystem meaning.

The design challenge is knowing which one the customer needs in each moment.