How to document a process
By Annie, our AI research assistant, Reviewed and edited by Jessica WhiteTHE SHORT VERSION
There are three practical ways to get a process out of someone's head and onto a page a coworker can follow: write it manually from memory, record a video walkthrough, or capture it step by step with a tool that screenshots each action as it happens. Each produces a genuinely different document with different strengths and different failure points, and the right choice depends less on which tool looks best and more on how often the process changes and who has to maintain it after the first draft.
"Document the process" sounds like one instruction. In practice it is a choice between three fundamentally different methods, and most of the friction people report with process documentation, it takes too long, it goes stale immediately, nobody wants to write it, traces back to picking a method mismatched to the task rather than to documentation being inherently hard.
The three methods are:
Writing it manually from memory or notes
Recording a video walkthrough of someone performing it
Capturing it with a tool that records each on-screen step automatically as the task is performed.
None of the three is universally better. Each trades speed for maintainability differently, and knowing which trade a given process actually needs is most of the work.
Method one: writing it manually
Manual writing means sitting down, either alone or interviewing the person who does the task, and producing the document directly: a trigger, an owner, a sequence of steps, exception handling, and the rest of the elements a followable procedure needs.
What it is good for. Manual writing is the only method that naturally handles judgment-heavy processes, ones with decision points, exceptions, and reasoning that a screen recording or screenshot sequence cannot capture because none of it happens visibly on a screen. A process for handling an escalated client complaint, deciding when to override a standard policy, or evaluating a vendor's bid involves thinking that a capture tool has no way to observe. Writing it out forces someone to articulate the actual decision logic, which is often the most valuable part of the document.
Where it breaks down. Manual writing is slow, and it is the method most vulnerable to being written from memory rather than from direct observation of the task. A procedure written by someone recalling how they think a task works, rather than watching it actually performed, reliably ends up with steps in the wrong order or missing entirely, because memory smooths over small real steps that feel too obvious to mention. It is also the hardest method to keep current, since nothing about the format prompts anyone to notice when the underlying process has quietly changed.
Method two: recording a video walkthrough
A video walkthrough means recording someone performing the task on screen, narrating as they go, with the recording itself serving as the documentation, sometimes supplemented with a written summary.
What it is good for. Video captures things text struggles with: pacing, tone in a client-facing task, the exact visual state of a software interface at each point, and any physical or hands-on component that would take paragraphs to describe accurately in prose. For training a new hire on something with a visual or interpersonal component, watching someone do it once often transfers more real understanding than reading steps ever will.
Where it breaks down. Video is not searchable or skimmable the way text is. A person who needs to check one specific step three weeks from now has to scrub through a recording to find the relevant thirty seconds, which is slower than scanning a numbered list. Video is also the most expensive method to update: a two-minute change in the underlying process usually means re-recording the whole thing rather than editing one line, which means video documentation tends to go stale and stay stale, because updating it feels disproportionately costly relative to the size of the actual change.
Method three: capture-first documentation
Capture-first tools sit between manual writing and video. The person performing the task works normally, clicking and typing through the actual process, while a tool running in the background automatically records each step: it takes a screenshot at each action and generates a written, numbered description of what happened, producing a step-by-step guide without the person separately writing prose or narrating out loud.
Scribe is one example of a tool built specifically around this method. Its browser extension and desktop application record on-screen steps, clicks and the keystroke context around them, while someone performs a process, then auto-generates a guide combining a screenshot of each step with an automatically written text description of the action taken. The result reads similarly to a manually written procedure, a numbered sequence with screenshots, but was produced by doing the task once rather than by writing anything from scratch. Editing tools let the screenshots be annotated or redacted afterward, and finished guides can be exported to formats like PDF, HTML, Markdown, or Word, depending on the plan.
What capture-first tools are good for. This method is fastest for processes that are entirely visible on a screen, software workflows, data entry sequences, administrative tasks inside a system, because the tool is doing the transcription work a person would otherwise do by hand. It also tends to produce more accurately sequenced steps than manual writing from memory, since the steps are recorded in the order they actually happened rather than reconstructed afterward, and it lowers the barrier to documenting something at all: a task that would never get written up because nobody has time to sit down and draft it often does get captured, because capturing it takes no longer than doing the task itself.
Where it breaks down. A captured guide records what happened on screen, not why. It has no native way to explain a decision point, a judgment call, or an exception that occurs off-screen, which means capture-first output usually needs a person to go back afterward and add the reasoning a screenshot sequence cannot show. Review of published guides describes recurring friction on the editing side as well: reordering steps after the fact is not always straightforward, screenshots are occasionally missed or auto-zoomed inconsistently, and cleanup after capture, before a guide is ready to share, is a real step in the process rather than an optional one. Access to some of the format's most useful capabilities, desktop and mobile capture beyond the browser, custom branding, and non-link export formats, is also gated by plan on tools in this category rather than universally included, which is worth checking directly against the specific tool under consideration before assuming a feature is available.
Choosing among the three for a given process
The decision comes down to two questions, asked about the specific process being documented, not about documentation in general.
How much of the task happens on a screen, versus in someone's judgment? A process that is almost entirely clicking through software is a strong fit for capture-first documentation. A process that is mostly deciding what to do, evaluating a situation, choosing between options, is a poor fit for capture and a strong fit for manual writing, because the valuable part of that process is invisible to a screen recorder.
How often does this process change, and who is responsible for keeping the documentation current? A process that changes frequently needs to be cheap to update, which favors manual writing or capture-first documentation, both of which can usually be edited step by step, over video, which usually requires a full re-record for even a small change. A process that is stable and rarely changes can tolerate a more expensive-to-produce format like video, since the upkeep cost is rarely paid.
Many real documentation libraries end up using all three methods for different processes, and that is not a failure of consistency, it is a reasonable match between method and task. What matters is that the choice was made deliberately, based on what a given process actually needs, rather than defaulting to whichever method the team happened to reach for first.
After the process is captured
However a process gets documented, the output still needs the same six elements that make any procedure followable: a stated trigger, a named owner, the sequence, exception handling, a definition of done, and a review date. A capture-first tool or a video recording produces the sequence quickly and often produces it more accurately than memory would. It does not automatically produce the other five elements, which still require someone to add them deliberately once the raw capture exists. [How to write an SOP →] covers all six elements in full and is the natural next step regardless of which of the three methods produced the initial draft.
