How to create a step-by-step guide with screenshots

Most advice on this topic is an advertisement with a numbered list attached. This one starts with the manual method, because you can do the whole thing today with the screenshot tool already on your machine, and because knowing the manual method is what tells you whether a tool is saving you anything.

The job has four parts: capture, caption, redact, and maintain. The last one is where guides actually fail.

Before you capture: do the thing once

Run the whole workflow start to finish without recording anything.

This feels like wasted effort and saves more time than any other step. You will discover that step 3 requires a permission you forgot about, that there is a modal you always dismiss without reading, and that the “obvious” route is actually two clicks longer than the one you use out of habit. If you capture on your first pass you will capture all of that, and then spend longer deleting it than the dry run would have taken.

While you do it, decide three things:

• Where the guide starts. Not “log in” — assume the reader is where they’d realistically be. A guide to exporting a report starts on the reports page, not the login screen.
• Where it ends. The last screenshot should show the outcome, not the last click. The reader needs to recognise success.
• The one path. If there are two ways to do it, pick the one that works for everyone, not the one that’s fastest for you. Keyboard shortcuts are a footnote, not a step.

Capture

Set your window to a fixed size and leave it alone. This is the single biggest quality difference between a guide that looks made and one that looks thrown together. If every screenshot is a different width, the reader’s eye has to re-orient on every image. Pick a size — 1440 wide is a reasonable default — and do not resize, zoom, or move the window until you are finished.

Capture the region, not the screen. A full-screen capture on a modern monitor produces an image where the relevant button is 2% of the pixels. Capture the application window, or a consistent region within it. On Windows, Win + Shift + S gives you a region snip. On macOS, Cmd + Shift + 4 does, and Cmd + Shift + 4 then space captures a single window cleanly.

Capture before the click, not after. The reader needs to see the button they are about to press, in the state it is in when they need to find it. A screenshot of the result belongs to the next step.

Keep the cursor in shot if your tool allows it. A visible cursor over the target element does more to orient a reader than an arrow you draw on afterwards. Windows’ Snipping Tool does not include the cursor; a screen recorder does, which is one reason recording and extracting frames often beats snipping.

Take more than you need. Deleting a step is thirty seconds. Re-running the workflow to capture one you missed is ten minutes and you will get a different window size.

Caption

Here is the rule that fixes most bad guides: the caption says what to do, the screenshot says where.

Write the instruction so it works with the image missing. Then let the image answer “which one?” and “what does it look like?”

Bad:

Click here.

Also bad, in the opposite direction:

Click the blue “Export” button in the top right corner of the Reports page, underneath the date filter and next to the Share icon.

Good:

Click Export.

The screenshot already establishes that it is blue and in the top right. Repeating the visual information in words is what makes documentation exhausting to read, and it is also what breaks first when your UI changes — the button moves, and now the text is wrong as well as the image.

Three more caption rules:

• One action per step. “Click Export and choose CSV” is two steps. Split it. A reader who fails will fail on one of them, and you want to know which.
• Name what they’ll see next when it isn’t obvious. “Click Export. A format picker opens.” saves the reader wondering whether it worked.
• Bold the thing they click. It makes the guide scannable, and most people scan.

Number your steps. Not because it is prettier, but because it lets someone say “I’m stuck on step 4” — which is the entire point of writing the guide.

Redact

Do this before the guide leaves your machine, and treat it as part of capture rather than polish.

Anything you record from a real account is likely to contain: customer or colleague names, email addresses, revenue or usage figures, account IDs, API keys, an internal URL structure you would rather not publish, and a browser tab bar that says more about your company than you think.

Cover, don’t crop, when position matters. If you crop out the sidebar, the reader loses the spatial context that helps them find the button. Blur or block the sensitive area instead and leave the layout intact.

Use a solid block for anything genuinely secret. Blur is a reversible operation in principle, and low-radius blur over short text — a six-digit code, a short name — has been recovered before. For anything that matters, use an opaque rectangle. Blur is fine for making a busy dashboard less distracting; it is not a security control.

Never redact by drawing over the image in a tool that keeps layers. If you export a PDF or a layered file with a black rectangle on top, the text underneath is still there. Flatten it, or export to PNG.

Check the edges. The three places sensitive data survives redaction: the browser tab title, autocomplete dropdowns that appeared while you were typing, and notification toasts that popped up mid-capture.

If you are documenting a real customer’s account rather than your own, use a demo account instead. It is faster than redacting well, and there is no version of “I redacted it carefully” that survives a mistake.

Assemble

For a written guide, the structure that works is boringly consistent:

1. A title that describes the outcome, not the feature. “How to export a report as CSV”, not “The Export menu”.
2. One line on who this is for and what they need — permissions, a prerequisite, an app version.
3. Numbered steps. Image, then caption underneath it, consistently. Do not alternate.
4. A final screenshot of the result.
5. The two or three things that commonly go wrong, at the bottom. This section is where a guide stops generating tickets.

Put it wherever your readers already are — help centre, Notion, a README, an email. A guide in the right place at half the quality beats a beautiful one nobody finds.

Maintain

Every screenshot guide starts rotting the day you publish it, and this is the part nobody plans for.

Three habits that help:

• Date it visibly. “Last checked: August 2026” tells a reader whether to trust a screenshot that doesn’t match their screen. It costs nothing and prevents a support ticket.
• Keep the source. Whatever you captured with, keep the originals in a known place. The common failure is needing to change step 4 and having to re-capture all twelve because the window size is lost.
• Note the dependency. If your guide documents a UI, whoever changes that UI should know the guide exists. A line in the help-centre article listing which screens it depends on is cruder than a real system and works better than nothing.

The rot problem is the strongest argument for using a tool rather than a folder of PNGs. Not because capture is hard — it isn’t — but because editing one step out of twelve without redoing the other eleven is genuinely tedious by hand.

When a tool is worth it

Move off the manual method when one of these is true:

• You are writing more than about one guide a month. The per-guide time saving is real and compounds.
• Your UI changes often. Updating one step in a tool is a minute. Re-capturing a folder of screenshots is an afternoon.
• You need it to be interactive. A guide people read and a demo people click through are different formats — see interactive demo vs video vs GIF for which one your job needs.
• More than one person writes documentation. Consistency by convention fails at two people; consistency by tool doesn’t.

Two categories to choose between. Tools like Scribe and Tango produce a written guide much like the one described above, automatically. Tools like Supademo, Arcade, and Storylane produce a clickable walkthrough the reader advances themselves.

Two things to check on the pricing page before you commit, because both bite later:

• Is redaction included on the plan you are buying? At Scribe, Arcade, and Guidde it is a paid feature. Given that you cannot publish most real recordings without it, that changes which plan you actually need.
• How does it bill per person? Documentation is written by whoever knows the workflow, which is rarely one designated person. Per-seat pricing quietly decides that only one of you writes guides. We put the full cost breakdown in a separate post, with the numbers taken from each vendor’s own page.

Related

• Scribe alternatives in 2026 — seven tools for written guides, compared by price and use case
• How to blur sensitive data in a product demo — the longer version of the redaction section
• What interactive demo software really costs