Anyone who has assembled furniture from a diagram knows the feeling: the instructions show a clean, ordered sequence of steps, and your actual experience is a mess of backtracking, re-reading step four because step five didn’t make sense, and improvising when the parts in your hands don’t quite match the parts in the picture. The manual describes an idealized process. You lived through a different one. And somehow the chair still gets built.
That gap between instructions and lived action is exactly what researcher Lucy Suchman documented in her landmark 1980s study of an office photocopier — a study that has quietly shaped how technology designers think about instructions ever since.
The Photocopier Study
Working at Xerox’s Palo Alto Research Center, Suchman and her colleagues recorded pairs of people trying to operate a photocopier that was, for its time, unusually sophisticated: it included an onscreen “expert help” system meant to walk users through complex tasks step by step, inferring what the user was trying to do and offering the next appropriate instruction.
In theory, this should have made the machine easier to use than a plain instruction sheet — it was interactive, and it was supposed to be responsive to the user’s actual progress. In practice, Suchman’s recordings showed pairs of intelligent, capable adults getting stuck again and again, confused not because they were careless but because the help system’s model of “what the user must be doing” kept diverging from what the users were actually doing.
Where the Plan and the Person Diverge
The breakdowns followed a pattern. The machine’s help system was built around an internal plan — a designer’s best guess, encoded in advance, about the typical sequence someone would follow to accomplish a task. The people using the machine, by contrast, were doing exactly what situated action theory predicts people always do: responding to the specific, immediate details in front of them, which didn’t always match what the designer had anticipated.
When a user’s screen showed something the built-in plan hadn’t accounted for, the machine had no way to notice the mismatch or repair it. It just kept offering the next instruction in its predetermined sequence, as though nothing had gone wrong — leaving the user to reinterpret a now-nonsensical instruction against a reality it no longer described.
Plans as Maps, Not Scripts
Suchman’s broader point, developed across the whole book, is that instructions — like plans generally — work more like a map than a script. A map is genuinely useful: it orients you, shows you the terrain, helps you choose a general direction. But you don’t walk a map footstep by footstep. You use it as a resource while you improvise your way across the actual, particular ground in front of you, which always has details — a fallen branch, a closed path, a shortcut — that no map could have included.
Instructions that are designed as if they were a script rather than a map will always eventually meet a situation they didn’t anticipate. When that happens, what the user needs isn’t a more detailed script. It’s a way to repair the mismatch — which is exactly what the 1980s photocopier’s help system had no way to do.
Why This Still Happens Today
The specific technology has changed, but the underlying design assumption shows up constantly in modern interfaces: rigid multi-step wizards, phone-tree menus with no path back to a human, chatbots built on decision trees that collapse the moment a user’s phrasing falls outside the anticipated set. Anywhere a system is built around one designer’s model of “the steps you’ll follow” rather than a genuine capacity to notice and adjust when a user’s real situation departs from that model, Suchman’s photocopier problem reappears in a new interface.
What This Means for You
If instructions have ever left you more confused than before you read them, the honest diagnosis usually isn’t that you missed something — it’s that the instructions were written as a script for an idealized situation, and your actual situation, like everyone’s actual situation, didn’t match it exactly. Well-designed instructions, and well-designed systems, treat that mismatch as the normal case to plan for, not the exception. The next article in this series picks up the conversational side of that same problem: how human conversation survives constant small misunderstandings that machines still struggle to repair.