Designing with Distinctions, Not Features

Most product roadmaps read the same.

Add a feature.
Improve a feature.
Automate a feature.

When systems fail, the instinct is to add one more.

And yet, many of the hardest failures in software don’t come from missing functionality. They come from confusion — about what something is, what it is not, and how it should be treated.

This is not a feature problem.
It is a distinction problem.

What a Distinction Actually Is

A distinction is a boundary that makes something intelligible.

It answers questions like:

• Is this a request or an update?
• Is this routine or exceptional?
• Is this informational, or does it require action?
• Is this resolved, or merely quiet?

Humans make these distinctions constantly, often without noticing. They are how we navigate complexity without being overwhelmed.

Software, on the other hand, tends to blur them.

Not because it cannot represent distinctions — but because it often hides them inside logic, rules, and models instead of making them explicit.

When Distinctions Stay Implicit

Consider a system that processes incoming documents.

Internally, it may already distinguish between:

• new vs. existing matters,
• high vs. low confidence classifications,
• reversible vs. irreversible actions.

But if these distinctions remain implicit, users never interact with them directly.

From the outside, everything looks the same:
a list, a status, a result.

When something goes wrong, people are forced to reverse-engineer the system’s thinking. They ask, “Why did this happen?” and receive answers in terms of processes, not meaning.

This is where frustration begins.

Not because the system is wrong — but because its distinctions are invisible.

Feature Thinking vs. Distinction Thinking

Feature-driven design asks:

• What can the system do?
• What should we add next?

Distinction-driven design asks:

• What differences matter here?
• Which boundaries must remain stable for the system to make sense?

These are very different questions.

Feature thinking accumulates capabilities.
Distinction thinking stabilizes understanding.

In complex domains, adding features without clarifying distinctions often increases ambiguity. The system becomes more powerful, but harder to reason about.

Why Distinctions Are a Design Concern

Distinctions are often treated as an implementation detail — something engineers or models “handle.”

But for users, distinctions are the interface.

People don’t want to know how a system works. They want to know:

• what category something falls into,
• how certain that categorization is,
• and what kind of response is appropriate.

When these distinctions are surfaced clearly, systems feel calm, even when they are doing complex things.

When they are hidden, systems feel arbitrary.

Surfacing Distinctions Changes Interaction

When a system makes its distinctions explicit, interaction shifts.

Users stop correcting outcomes and start correcting understanding.
They no longer fight the system; they refine it.

For example, instead of overriding an automated action, a user might adjust a distinction:

• “This looks like a routine case, but it isn’t.”
• “This is technically complete, but substantively unresolved.”

These are not edge cases. They are how real work actually happens.

Designing for this kind of interaction requires fewer features — not more.

Fewer Features, Clearer Systems

Some of the most robust systems feel simple not because they do little, but because their distinctions are clean.

You always know:

• where you are,
• what kind of thing you are dealing with,
• and what kind of action makes sense next.

This clarity does not emerge from adding intelligence on top. It emerges from deciding which distinctions matter and committing to them in the design.

Once those boundaries are clear, automation, agents, and workflows can operate safely within them.

Without them, even the smartest systems drift.

A Different Measure of Progress

Progress in product design is often measured by shipped features.

But in systems that must remain understandable under complexity, a better measure is this:

Are the system’s distinctions becoming clearer or more blurred over time?

Designing with distinctions means treating clarity as a first-class outcome.

Not everything needs a feature.
Some things need a boundary.