Business Analysis Notes

UX for analysts

Cognitive Friction

4 min read · Updated

In short Cognitive friction is the mental resistance people meet when a system’s rules keep shifting with its state. Alan Cooper uses the idea to explain why software frustrates people even when it is physically easy to operate, and why someone must deliberately design how software behaves.

Based on: A. Cooper, The Inmates Are Running the Asylum (1999), ch. 2.

On this page

Key ideas#

What it is#

Cooper’s term describes the effort the mind spends making sense of a complex set of rules that change as the situation changes. Like physical friction, a little is harmless, but its cost climbs steeply as it grows. Unlike physical friction, it can’t be measured with engineering tools. It is real, but not measurable in that way.

The source: controls whose meaning depends on state#

A mechanical device usually has few states relative to its controls, so its behavior is predictable even when it is hard to master. A violin is difficult to play, but it never turns into a different instrument. Cooper contrasts this with devices whose controls have meta-functions, such as a microwave where the same number keys set the power in one state and the time in another. Pressing a key is physically easy; knowing what it will do is not.

His point about ergonomics: specialists traditionally optimize for the user’s eyes and fingers (can you see the button, can you reach it), not for the user’s mind. The result is products that are physically comfortable and mentally tiring. Cooper even treats the hyperlink as an extreme case: its only purpose is to take you somewhere, and the content at the other end can change independently of the link.

Interaction design vs. program design#

Cooper argues that all programming involves design decisions, and he draws the line by who is affected:

  • Interaction design covers decisions that directly affect the end user: behavior, purpose, information and presentation.
  • Program design covers everything else, such as language and internal architecture. It becomes an interaction question when a technical choice changes something the user notices, such as response time.

He deliberately avoids the word “interface”. It suggests code on one side, people on the other, and a thin layer between them that is responsible for the user’s needs. In practice this lets programmers postpone the user (“the interface comes when I’m done”), so user-facing design happens last and in a hurry, if at all.

Too little design is still design#

Most organizations, Cooper observes, have no one whose job is to design for the end user. But someone still decides how the software behaves: a marketer pushing an attractive feature, or a programmer implementing the behavior they prefer. They are designing without the role. The difference between deliberate and accidental design is motivation. A real interaction designer decides from the user’s goals. An accidental one decides from personal taste, habit, fear of the unknown or the path of least effort for the developer.

How to apply it#

For business analysts the key lesson is the last one: if your requirements leave behavior open, someone else will design it.

  1. Specify behavior, not only data. For every user-facing function, state what the user sees, what each control does, and what happens on success and on failure.
  2. Sort open decisions. Separate interaction decisions, which need user input and persona checks, from program decisions, which the team can make. Give each interaction decision an owner.
  3. Hunt for state-dependent controls. In prototypes, look for buttons, keys or gestures whose effect depends on a state the user may not be watching.
  4. Write user-visible performance as requirements. If response time changes how people work, it is an interaction requirement, not a technical detail.
  5. Schedule interaction design before build. Don’t accept a plan where “the UI” is a final phase.

Review checklist#

  • Each control does one thing, or the state that changes its meaning is unmistakable.
  • Every user-facing behavior has a written decision and an owner.
  • Response times that users will notice are stated and testable.
  • Links and navigation say where they lead.
  • No behavior was chosen only because it was easiest to build.

Example#

At The Workshop, a fictional chain of bike-repair workshops, the specification for repair-status notifications says only: “The customer is notified when the status changes.” The outside development team fills the gap the easy way: one message per internal status change, including technical ones. Customers receive several messages a day, most of them meaningless. Nobody chose this behavior on purpose; it was designed by default.

The mechanics’ tablet shows another kind of friction. A single “Next” button opens the next job in list view but advances the current job’s status in detail view. Mechanics working fast press it in the wrong view and close jobs by mistake. The analyst writes two requirements: separate controls for “open next job” and “mark stage done”, and a notification rule that lists exactly which status changes trigger a customer message.

Pitfalls#

  • Assuming developers will “make it intuitive” → write the behavior down.
  • Judging usability only by clicks and target sizes → also count the states a user must keep in mind.
  • Treating the UI as a layer to add later → plan interaction design together with the requirements.

Sources and further reading#

  • A. Cooper. The Inmates Are Running the Asylum. Sams, 1999, ch. 2.