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.
In Thinking, Fast and Slow, Daniel Kahneman distinguishes between two modes of human cognition:
This framework has profound implications not only for psychology but also for technical communication.
System 1 often gets a bad reputation in psychology and popular discussions because it can lead to cognitive biases — snap judgments, stereotypes, and errors in reasoning. Headlines highlight the pitfalls: “Why our intuition fails us” or “The hidden traps of fast thinking.”
Yet in most real-world situations, System 1 is astonishingly performant. It allows us to make split-second decisions while driving, or recognize a friend in a crowd — all without conscious effort.
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 would mean leaning into heuristics — cues that help readers act quickly without overthinking. Clear visual hierarchy, strong verbs, scannable structure, and obvious affordances (“click,” “type,” “drag”) allow the reader’s intuitive mind to guide action. This is writing that shows, not explains; triggers recognition, not recall.
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.
To foster cognitive ease, we can:
Use visual clarity: Favor legible fonts, sufficient contrast, and generous white space. These are not mere aesthetic choices — they reduce friction in perception.
Repeat key phrases and patterns: Consistency reinforces recognition, allowing System 1 to process structure automatically.
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.
As Kahneman also reminds us:
If you care about being thought credible and intelligent, do not use complex language where simpler language will do.
Use simple language: Clear, direct wording enhances fluency just as much as clean design does. Complexity in phrasing can create unnecessary cognitive strain, making readers work harder to trust and understand you. Simple language projects confidence and fosters credibility.
This is where minimalism, as developed by John Carroll and Hans van der Meij, intersects beautifully. Their minimalist principles emphasize:
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.
Within a DITA framework, the distinctions among tasks, concepts, and references map intriguingly to Kahneman’s systems:
A well-structured DITA content set therefore offers an affordance of cognitive control: readers can choose whether to stay in System 1 or engage System 2, depending on their momentary goal.
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 clues:
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. For example:
The Automated Verification Dashboard (we’ll just call it the Dashboard) lets you review submissions quickly.
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.
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.
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.
It would be more technically accurate to describe the features’ functions without implying human qualities. But that would heavily tax the user’s limited budget of attention.
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.
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. It’s a bridge between deliberate construction and intuitive grasp — a moment where the writer’s slow thinking enables the reader’s fast understanding.
Would AI be a better fit to partially replace tech writers’ System 2, allowing them to better leverage their System 1? I’ve got a hunch that AI was designed to mimic the deliberate, analytical thinking of System 2.
If we borrow Daniel Kahneman’s model of the mind, System 2 is the slow, analytical, rule-following mode — the part responsible for precision, consistency, and structural rigor. Much of technical writing operates here: editing for clarity, enforcing style guides, and maintaining information architecture.
But the uniquely human side of tech writing — empathy for the reader, intuitive phrasing, sense of tone, and contextual awareness — lives in System 1, the fast, instinctive mode.
The question, then, isn’t whether AI can replace tech writers, but whether it can absorb some of their System 2 load, freeing them to lean into their System 1 strengths. By offloading cognitive effort, AI could amplify what makes human writers irreplaceable: their ability to sense what readers feel, not just what they read.
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.
Good documentation doesn’t just tell users what to do. It thinks with them — fast or slow.