Most documentation projects begin at a keyboard. That is the wrong place to start. Before a single step gets written, someone has to go and watch the process run, because what people say they do and what people actually do are rarely the same thing.
What does it mean to document a process before you write it down?
It means observing the work where it happens, in real conditions, before you draft a step. Writing captures a version of the process. The observation decides whether the version you captured is the one your business runs on.
I spent years in manufacturing operations writing the procedures myself, and the pattern held everywhere. Ask an experienced operator to describe their job and you get a clean, logical account with about four steps missing. Watch the same person work for twenty minutes and the missing steps appear: the gauge they tap before trusting it, the second form they fill out only on Fridays, the call to shipping that never made it into anyone's flowchart.
Why is the description of a process never the process?
Because practice compresses. Once a sequence is well learned, it stops being stored as separate steps and starts being stored as one motion, which makes it nearly impossible to narrate accurately from memory.
That is not carelessness, it is how skill works. The cost lands on the reader of the finished document, usually a new hire who has none of that compression and needs every part spelled out. This is also why the strongest performer often writes the weakest procedure, and why a translator between the expert and the reader is worth having. Getting that translation right is the core of technical writing.
What should you be looking for while you watch?
Look for the parts of the process that no one would think to tell you. Those are the parts that break for a new person, and they are almost never in the version described at a desk.
- Where the sequence branches, and what the operator uses to decide
- Where a step exists only because it has always existed
- Where someone checks something that no document tells them to check
- Where the work stops and waits on a person, a signature, or a machine
- Where two people doing the same job do it differently, and why
- Where errors get caught, and where they get through
The last two matter most. Variation between people tells you the procedure is underspecified. The point where errors escape tells you which step your document has to be strongest on.
What do you do when observation shows the process is broken?
Decide on purpose whether you are recording the process or fixing it, and say which out loud before you write. Documenting a broken process carefully is the fastest way to make it permanent.
Nearly every documentation project turns up something worth changing: a duplicated approval, a report nobody reads, a step that survives a machine replaced six years ago. Writing that down without comment gives it authority it never earned. The honest options are to fix it first, write it as is with the flaw flagged for a decision, or scope a design pass alongside the writing. Any of the three works. Choosing none of them is what produces a procedure everyone works around.
How do you capture what you saw without producing forty pages of notes?
Map before you draft. Sequence, decision points, inputs and outputs, and who owns each handoff. One page, no prose, no formatting.
Then take the map back to the floor and check it twice: once with the person who does the work, once with the person accountable for the result. They will disagree somewhere, and that disagreement is the most useful thing you will find all week. It is nearly always the place where the process actually fails. Resolve it before drafting, because a procedure written on top of an unsettled disagreement will be overruled in practice within a month.
How long does this step take?
Less than the revision cycle it prevents. A single well-bounded process is usually half a day of observation and mapping. Something regulated or safety critical takes longer, because you need to see the exceptions and not only the clean run.
Skipping it does not save time, it relocates the time. It reappears as three rounds of review, a procedure that fails the first new hire who follows it literally, and a supervisor still answering the same question every Tuesday. Common questions about scope and sequencing are answered on the FAQ.
When is it worth bringing in someone from outside?
When the people who know the process best are the people who cannot describe it. An outside writer has one real advantage: no compression. Nothing about the work is obvious yet, so the naive question gets asked, and the naive question is the one your documentation has to answer.
There is a second advantage that is harder to name. An outsider can ask why a step exists without it sounding like an accusation, which is often the only way the honest answer comes out. If you have a process that lives in one person's head, or a set of procedures that nobody follows the way they are written, a discovery call is the place to start. Technical work is scoped per project and can include the observation and process design phase, not only the writing.
Frequently asked questions
What is the first step in documenting a process?
Observing the work as it is actually performed, before any drafting. A description given from memory routinely omits steps that have become automatic, so the written procedure inherits those gaps. Watching the process run in real conditions is what makes the documented version match the operating version.
Why can experienced employees not describe their own process accurately?
Because practice compresses a learned sequence into a single remembered action. The individual steps stop being separately retrievable, which is a feature of skill rather than a lapse in attention. The result is that the most experienced person often gives the least complete account, and a new hire following that account gets stuck.
Should you fix a broken process or document it as it is?
Either is defensible, but the choice has to be made deliberately and stated before writing begins. Documenting a flawed process carefully gives it authority it has not earned. The workable options are to fix it first, write it as is with the flaw flagged for a decision, or run a design pass alongside the documentation.
How long does it take to map a process before writing it?
About half a day of observation and mapping for a single well-bounded process. Regulated or safety critical work takes longer because the exceptions have to be seen, not only the clean run. Skipping this step does not save time, it moves the time into review cycles and repeated questions after the document is issued.
