# Slow food for fast thinking: designing with cognitive ease in mind
## Food for thought: Systems 1 and 2, and minimalism
Arguably, tech writers’ role is to relieve users from cognitive load. In a world flooded with information, users don’t need more data: they need clarity. Every sentence in a help article, API guide, or UI tooltip is a chance to reduce friction, simplify decisions, and help people think less about how to do something and more about what they want to achieve. Great technical writing isn’t about showcasing expertise; it’s about designing understanding.
> **The core thesis:** Good technical writing uses deliberate, analytical effort (System 2) to design affordances and minimalism that enable fast, intuitive comprehension (System 1) for the reader.
In [*Thinking, Fast and Slow*](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow), Daniel Kahneman distinguishes between two modes of human cognition:
* **System 1**, which is fast, intuitive, and automatic.
* **System 2**, which is slow, deliberate, and analytical.
Slow food for fast thinking: meticulous, deliberate preparation behind the scenes enables immediate, effortless consumption.
This framework has profound implications not only for psychology but also for **technical communication**.
## Writing for System 1
When we write technical documentation, especially instructional content, we often assume readers are engaging their System 2: carefully reading, analyzing, following logic. But in practice, most users read docs when they’re *in the middle of a task*, under time pressure, with cognitive load already high. That’s when System 1 dominates.
**So what would it mean for technical writing to target System 1?**
It means leaning into **heuristics**: cues that help readers act quickly without overthinking. Affordance is not just a UI design principle—technical writing itself creates cognitive affordances that show readers how to navigate and act:
White space, distinct headings, and scannability show readers where to look without conscious scanning effort.
Direct imperatives (deploy, configure, verify) tell readers exactly what to do rather than describing passive states.
Action cues ("click," "type," "drag") signal how to interact directly with the software or physical interface.
Repeated layout patterns allow System 1 recognition to replace the mental friction of re-learning navigation.
---
## Foster cognitive ease in technical documentation
As Daniel Kahneman explains in *Thinking, Fast and Slow*:
> A sentence that is printed in a clear font, or has been repeated, or has been primed, will be fluently processed with cognitive ease.
Cognitive ease describes how smoothly the mind processes information. When processing feels difficult (small fonts, dense text, inconsistent terminology), readers experience friction and uncertainty, triggering System 2’s effortful reasoning.
> **Designing for cognitive ease:** Ease is not laziness; it is the deliberate reduction of perceptual and syntactic friction so that the reader's working memory remains entirely available for their actual task.
To foster cognitive ease, we apply four structural practices:
1. **Use visual clarity:** Favor legible fonts, sufficient contrast, and generous white space. These are not mere aesthetic choices: they reduce friction in perception.
2. **Repeat key phrases and patterns:** Consistency reinforces recognition, allowing System 1 to process structure automatically.
3. **Prime through predictability:** *Priming* refers to subtly preparing readers to process new information more easily by exposing them to related ideas or patterns beforehand. Maintain a familiar layout and phrasing style across topics so that readers know where to look and what to expect.
4. **Use simple language:** Clear, direct wording enhances fluency just as much as clean design does. Complexity in phrasing creates unnecessary cognitive strain, making readers work harder to trust and understand you. Simple language projects confidence and fosters credibility.
As Kahneman reminds us:
> If you care about being thought credible and intelligent, do not use complex language where simpler language will do.
---
## Minimalism and the reduction of cognitive load
This is where **minimalism**, as developed by John Carroll and Hans van der Meij, intersects beautifully. Their minimalist principles emphasize:
* Focusing on *real tasks*, not exhaustive coverage.
* Providing *quick access* to needed information.
* *Eliminating unnecessary explanation* or conceptual overhead.
Minimalism is a practical strategy for engaging System 1: it minimizes the cognitive friction that forces readers into slow, effortful System 2 processing. The minimalist writer designs for fast comprehension and immediate action.
---
## DITA and systems thinking
Within a DITA framework, the distinctions among **tasks**, **concepts**, and **references** map directly to Kahneman’s cognitive systems:
| DITA Information Type | Cognitive Mode | Purpose & User Question |
|---|---|---|
| **Task** | System 1 (Fast) | Procedural, heuristic: *"What do I do next?"* |
| **Concept** | Bridge (Transition) | Explains *why*, offering context without overloading: *"Why does this work?"* |
| **Reference** | System 2 (Deep) | Detailed, precise, analytical: *"What exactly does this parameter mean?"* |
For a practical guide to applying these DITA information types in Markdown, see [strong information typing without the XML overhead](https://redaction-technique.org/strong-information-typing-without-xml-overhead).
> **The affordance of cognitive control:** A well-structured information-typed content set gives readers control over how deeply they engage—allowing them to act quickly in System 1 or analyze thoroughly in System 2 depending on their momentary goal.
---
## A concrete use case: writing for cognitive ease
Tech writers should aim at reducing the mental friction users experience when learning to perform a task. Even if writers can’t rename features, they can design documentation so that users spend less effort recalling, decoding, or connecting terms.
From this, tech writers can gather several actionable techniques:
1. **Introduce terms clearly and anchor them with mental cues.**
When a feature has a complex name, give readers a simple mental hook the first time you introduce it:
> The Automated Verification Dashboard (we’ll just call it the Dashboard) lets you review submissions quickly.
2. **Be consistent in terminology and phrasing.**
Documentation should always refer to features and steps in exactly the same way—avoid synonyms or alternate phrasing that force users to re-interpret meaning.
> **One concept, one stable name:** Never rotate synonyms for technical components or procedures. Inconsistent terminology forces System 1 to stall and forces System 2 to deduce whether two terms mean the same thing.
3. **Structure information to minimize cognitive load.**
Chunk related steps, use clear headings, and minimize nested instructions. This allows users’ working memory to focus on understanding what to do next, not on juggling too many concepts at once.
4. **Use narrative or persona-like framing for abstract concepts.**
Personify features so readers can track them intuitively. Says Kahneman:
> A sentence is understood more easily if it describes what an agent does than if it describes what something is, what properties it has.
> **Balancing precision and accessibility:** Describing what an active agent does is cognitively easier to track than describing abstract passive properties. While absolute technical precision might describe system states, framing operations through active roles protects the reader's limited attention budget.
Clarity depends not just on accuracy but on cognitive design. Writers should simplify the experience of thinking about it by guiding users’ attention, reinforcing consistency, and managing mental load.
---
## Technical diagrams: where writers’ System 2 meets readers’ System 1
Few artifacts reveal the dual nature of technical communication as clearly as technical diagrams. Creating a diagram demands the writer’s System 2: analytical precision, structural logic, and meticulous alignment of visual elements with underlying concepts. Every line, label, and arrow must be deliberate.
Yet, the goal of that effort is to speak directly to the user’s System 1: to make complex relationships instantly felt and understood without conscious reasoning. A well-crafted diagram transforms abstract data into immediate comprehension.
> **The writer/reader inversion:** The writer must think slowly and deliberately so that the reader can think quickly and effortlessly. A good diagram is a moment where the writer’s slow thinking enables the reader’s fast understanding.
---
## AI as a cognitive partner: offloading System 2 to strengthen System 1
Would AI be a better fit to take over part of tech writers’ System 2, so they can lean more into their System 1? It’s a well-known fact that AIs do better when they’re prompted to think step by step, and in many ways, they’re built to mirror the deliberate, analytical thinking of System 2. This dynamic is explored concretely in [using AI to transform a content corpus into living knowledge](https://redaction-technique.org/transforming-corpus-ai-living-knowledge).
If we borrow Daniel Kahneman’s model of the mind, System 2 is the slow, methodical, rule-following mode: the part that handles precision, consistency, and structure. A lot of technical writing lives here: editing for clarity, enforcing style guides, and keeping information architecture in check.
Consistency audits, style-guide rule checking, terminology cross-referencing, and structural transformation of raw notes.
Reader empathy, intuitive phrasing, tone modulation, contextual awareness, and deciding what genuinely matters to the user.
The truly human side of tech writing—empathy for the reader, intuitive phrasing, sense of tone, and contextual awareness—belongs to the intuitive, empathetic faculties.
The real opportunity is not replacing writers, but offloading repetitive System 2 verification so writers can focus on their most humane skill: understanding what readers feel and experience, not just what they read.
---
## Minimalism, affordance, and Systems 1 and 2 working together
Minimalism reduces friction. Affordance guides action. System 1 thrives on clarity and cues; System 2 builds understanding and mastery. When technical communication balances these systems—intuitive guidance supported by analytical depth—it becomes not just informative, but humane.
> **The human-centered goal:** Good documentation doesn’t just tell users what to do. It thinks with them: fast or slow.
## Summing up
## Related reading
- [The KISS principle of simplicity](https://docs.redaction-technique.org/en/costs/kiss-principle/) - minimalism and cognitive ease as an engineering principle.
## External sources
- [Kahneman's two-systems model](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow)
- [Affordance (Gibson/Norman)](https://en.wikipedia.org/wiki/Affordance)
- [Cognitive ease and load](https://en.wikipedia.org/wiki/Cognitive_load)
*Hero image: ["The Raked Rock Garden"](https://www.flickr.com/photos/ddefranza/73457264) by [David DeFranza](https://www.flickr.com/photos/ddefranza/), licensed under [CC BY-NC-SA 2.0](https://creativecommons.org/licenses/by-nc-sa/2.0/).*
---
Source: https://redaction-technique.org/systems-1-2-affordance-minimalism-technical-writing