Cognitive Friction in Operations

One-line summary: Systems should be designed to absorb the complexity of operations, rather than forcing the individuals carrying them to absorb it through sheer mental effort.

1. What I mean by “cognitive friction”

Cognitive friction in operations is what happens when the way a system works quietly fights the way a person’s brain works. It is not about “smart vs. not smart”, and not a personality issue. It is the mismatch between operational design and cognitive ecology.

In day‑to‑day operations, this looks like:

• Workflows that require constant re‑interpretation of rules;
• Dashboards that never quite match what people actually need to decide;
• “Simple” processes that still leave people mentally exhausted at the end of the day.

I use cognitive friction as a design signal, not as a label on individuals.

（认知摩擦 = 系统和人脑工作方式的结构性不对齐，不是“个人不行”。）

---

2. Why it matters in operations

High cognitive friction is expensive, but most of the cost is invisible. It shows up as “slow onboarding”, “mysterious errors”, “inconsistent customer service”, or “promising hires quietly burning out and leaving”.

When operational systems keep fighting people’s brains, teams pay for it in:

• Error rates and rework: Friction creates the gaps where mistakes happen.
• Decision latency: People hesitate when the system is ambiguous.
• Hidden emotional labour: Especially for neurodivergent workers who absorb most of the mismatch until they reach a breaking point.

Concrete patterns of friction:

• Rule–reality mismatch: The documented process assumes one clean path; real cases constantly fall into “edge cases” that require memory of unwritten rules.
• Product–description mismatch: What a dashboard claims to show is not quite what it actually shows, forcing people to mentally re‑translate every time.
• Invisible coordination work: People have to keep track of who knows what and which channel is “safe” to ask in, without triggering blame.

---

3. Methods / Data

In my research and practice, I treat cognitive friction as something we can observe, measure, and redesign. This approach is detailed in Paper A, where I explore how cognitive load affects operational stability.

I typically work in three layers:

• Map the friction: Identify where people have to “hold too much in their head” to keep operations running.
• Quantify the load: Use structured questions and real operational data to see which parts of the system are overloading which brains.
• Redesign the system: Adjust rules, tools, dashboards, and handover protocols so the system absorbs more of the complexity instead of the individual.

---

4. Design Principles

From my work, three design principles keep coming up to reduce cognitive friction:

1. Reduce process and rule complexity first, not just “improve the UI” If the underlying rules are contradictory or unclear, no interface can make the work feel simple.
2. Align product behaviour with product description Make sure what systems and dashboards claim to show is exactly what they show. Transparency without this alignment can make friction worse.
3. Monitor cognitive friction as a safety signal Treat reported friction scores as an operational metric with thresholds: beyond a certain point, you are not just “annoying people”, you are creating a risk.

I treat the cognitive friction scale as a design tool, not as a research end point. It exists to guide concrete changes in operations.

---

5. Next Steps / How this connects to A/B

Measuring cognitive friction is the first step toward high-leverage system optimization. This connects directly to A/B testing and operational iterations:

• Friction-informed A/B testing: Instead of just testing for “conversion” or “throughput”, we test for “reduced cognitive fatigue” or “lower error rate in edge cases”.
• Shortening the feedback loop: Using friction scores to determine when a new process should be rolled back or redesigned before it causes systemic failure.
• Neurodivergent Workers: If a system is safe enough for them, it usually becomes more stable and humane for everyone else.

---

6. FAQ

• Is cognitive friction the same as cognitive load? Not exactly. Cognitive load is often used at the task level; cognitive friction is about the mismatch between whole operational systems and the people inside them.
• Why talk about neurodivergent workers here? Because their nervous systems often “feel” these mismatches first and most intensely. If a system is safe enough for them, it usually becomes more stable for everyone.

---

7. Links out

• Learn more about my work → /profile
• Research background → /research
• Work with this concept → /work-with-me

---

This note is part of my long‑term programme on neurodivergent‑friendly operations. More notes → /notes