Skip to content

Interaction — how humans engage with the system

Abstract illustration showing a person engaging with a structured system surface

Interaction describes human experience, not logic.

It does not define what the system is allowed to do, whether results are correct, or what data means. Those concerns belong elsewhere.

Interaction explains how people encounter the system in practice: how they find things, whether they understand what they see, how much effort tasks require, and what actions appear unavailable.

A system can be technically correct and still fail at interaction. When that happens, work slows down, mistakes increase, and confidence drops — not because the system is wrong, but because people struggle to engage with it.

Interaction is about experience, not behavior

Interaction is often confused with behavior or workflow.

But interaction does not describe what the system does. It describes how it feels to use it.

Two systems can enforce the same rules and process the same data, yet feel completely different to work with. One feels obvious and supportive. The other feels opaque, demanding, or restrictive.

That difference lives in interaction.

Interaction answers questions like:

  • Can I find what I’m looking for?
  • Do I understand what I’m seeing?
  • How much work does this take?
  • What am I prevented from doing?

These are experiential questions, not technical ones.

Discovery — can I find it?

Abstract navigation paths showing ease versus difficulty in finding information

Discovery describes how users find information or actions in the system.

It is about approachability: where users start, how they navigate, and whether they can locate what exists without already knowing how the system is structured.

The guiding test is simple:

“Is this about how a user finds something?”

If a user must remember where something lives, rely on training, or ask someone else where to look, discovery is weak.

Good discovery allows users to orient themselves through structure alone. It lets them explore confidently, even when they don’t yet know what they are looking for.

Discovery does not explain meaning.
It does not measure effort.
It only determines whether something can be found at all.

Understanding — can I understand it?

Same information presented clearly versus ambiguously

Understanding describes whether users can make sense of what they see once they have found it.

It is about clarity, not access.

The guiding test here is:

“Is this about clarity or confusion?”

Understanding succeeds when users can interpret information correctly, anticipate consequences, and trust what the system shows them. It fails when values are visible but ambiguous, when actions feel risky, or when users hesitate because they are unsure what will happen next.

A system can be discoverable and still confusing. In that case, users may reach the right screen — and still avoid acting.

Understanding supports the formation of a correct mental model. It allows users to act with confidence instead of caution.

Effort — how hard is it?

Illustration showing manual repetition versus system-assisted flow

Effort describes how much work the system requires from the user.

This includes physical effort, cognitive effort, and coordination effort. It appears when users must repeat actions, translate intent into steps, remember things the system does not carry, or manually compensate for gaps.

The guiding test is:

“Is this about the amount of work a user must do?”

Effort is not a personal problem. It is a structural one.

When systems absorb effort, work feels natural and proportional. When systems offload effort onto people, work still gets done — but only because users adapt their behavior.

Effort often becomes invisible once normalized. People stop noticing how much work they are doing until scale, pressure, or change exposes it.

Limitation — what am I prevented from doing?

Limitation describes what the interface prevents the user from doing, regardless of what the system might technically allow.

This is not a rules issue.

Limitation is about visible constraints in interaction:

  • disabled actions
  • unavailable paths
  • guardrails in the interface
  • fixed views or scopes that cannot be expanded

The guiding test is precise:

“Is the user blocked even though the system might technically allow it?”

If the answer is yes, it is an interaction limitation.
If the answer is no, and the block is intentional or enforced by policy, it belongs in Rules.

Limitation shapes how flexible a system feels as a surface for thinking. It determines whether users can expand context, explore alternatives, or reshape information as questions evolve.

How the interaction dimensions relate

Discovery, Understanding, Effort, and Limitation are distinct, but tightly connected.

A user may struggle because they cannot find something, because they do not understand what they see, because the task requires too much work, or because the interface prevents them from proceeding.

Each dimension answers a different experiential question:

  • Can I find it?
  • Can I understand it?
  • How hard is it?
  • What am I prevented from doing?

When problems are misclassified — for example treating a discovery problem as an effort problem — fixes tend to miss the mark.

Clear separation makes diagnosis possible.

What Interaction does not cover

Interaction does not decide:

  • whether something is allowed (Rules)
  • whether behavior is correct (Processing)
  • what data means (Information)

A system can be correct, compliant, and logically sound — and still be unusable.

Interaction exists to explain that gap.

Final anchor

Interaction describes how humans engage with the system.

It explains how people find things, whether they understand what they see, how much effort work requires, and what actions appear unavailable.

If users struggle, the problem is not always logic or data.

Sometimes, it is interaction.