Guide
How to write a how-to guide
Instructional writing has one measure of quality: can the reader do the thing afterwards? Everything else — style, length, structure — is downstream of that, and most of it is decided before you write a word.
Short answer
Write the steps for one named reader at one named skill level, in the order they will do them, with the failure modes attached to the steps where they happen. Then watch someone use it and fix what they stumble on.
Start with the reader’s starting point
Most bad how-to writing fails before the first step, because the author never decided who is reading. Write down three things and keep them visible while you draft:
- What the reader can already do. "Has used a spreadsheet, has never written a formula."
- What they have in front of them. Tools, budget, materials, time.
- What "done" looks like. A specific artefact or state, not a feeling. "A sourdough loaf with an open crumb" rather than "confidence in baking".
Two readers at different skill levels cannot be served by one guide. Pick the less experienced one; the expert can skim.
Task analysis before prose
Before writing, list every action the reader must take, in order, including the ones that feel too obvious to mention. The obvious ones are where beginners stop. For each action note: what they need in hand before it, what they do, how they know it worked, and what goes wrong most often.
That table is the book. Chapters are groupings of it; prose is the connective tissue.
| Before | Action | Success looks like | Common failure |
|---|---|---|---|
| Starter is 4–8 hours past feeding | Drop a spoonful in water | It floats | It sinks — starter is not ready, wait 2 hours |
| Dough has risen 50% | Fold from four sides | Dough holds a rounder shape | Dough tears — it is under-hydrated or over-proved |
How to write a step
- One action per step. If the step contains "and", consider splitting it.
- Start with the verb. "Open the file", not "You will want to open the file".
- Put the condition first. "If the dough sticks, add flour" rather than "Add flour if the dough sticks" — the reader scanning for their situation finds it at the start of the line.
- State the expected result. Every few steps, tell them what they should be seeing. Without checkpoints, a reader who went wrong at step four discovers it at step nineteen.
- Attach the failure to the step. Troubleshooting sections at the back of a book are read by nobody in the moment they are needed.
Structure for a how-to book
- Chapter 1: what you will make, and what you need. Photographs or a clear description of the finished thing, plus the full list of materials or prerequisites.
- Chapter 2: the shortest possible complete run-through. A first success in one sitting, even if simplified. Momentum is everything in instruction.
- Chapters 3 onward: one stage per chapter, in order, each ending in a checkpoint.
- Penultimate chapter: when it goes wrong. Symptom, cause, fix — organised by what the reader sees, not by what is technically happening.
- Final chapter: what to do next. Variations, next skills, where to go deeper.
Neubook Write’s how-to kind writes to this shape. It interviews you for the task, the reader’s starting point and the mistakes you have watched people make, then drafts the stages in order with checkpoints built in.
Start a book, freeWhere AI helps, and where it will hurt you
Instructional writing is one of the strongest uses for AI drafting and one of the most dangerous, for the same reason: the output is confident and uniform.
| Reliable | Dangerous |
|---|---|
| Consistent step formatting across 200 steps | Exact menu paths and button labels in software |
| Drafting the troubleshooting table from your notes | Version numbers, prices, legal thresholds |
| Rewriting a rambling explanation into steps | Safety-critical instructions of any kind |
| Producing the same guide in another language | Anything it has no way of having seen |
Verify every specific against the real thing. If the guide involves tools, chemicals, electricity, food safety, medication or money, have someone competent read it before publication — that is not a legal formality, it is how people get hurt.
Test it on a person
The only real quality check for a how-to guide is watching someone follow it without your help. Three testers in the target audience will find nearly everything. Watch for:
- Hesitation — they read a step twice. The step is ambiguous.
- Scrolling back — you introduced something out of order.
- Asking you a question — write the answer into the guide, at that step, in their words.
- Doing it differently — either your order is wrong or theirs is. Find out which.
Readers scan rather than read, especially when their hands are busy. Nielsen Norman Group's long-running work on how people read on screens applies directly: front-load the important words, keep paragraphs short, and make the structure visible without reading it.
Screenshots, diagrams and when to use them
- Use an image when the reader must recognise something — a texture, a screen, a part. Otherwise words are better: they translate, they are searchable, and they do not date.
- Annotate rather than crop. A full screen with an arrow tells them where they are; a tight crop does not.
- Describe in the caption what the image shows, so the guide still works in a black-and-white paperback or for a reader with images off.
Publishing a practical guide
Instructional books are searched by task, which makes metadata mercifully literal. Put the task in the title. Use keyword phrases that are the queries themselves — "sourdough for beginners", "bookkeeping for freelancers", "balcony vegetable garden". Google's guidance on helpful, people-first content is a decent checklist for the same material published as articles: does it demonstrate first-hand expertise, does it satisfy the reader without them going back to search.
Disclose AI assistance at upload under Amazon's content guidelines, and if the guide carries any risk, add a plain safety note in the front matter.
A one-week build
| Day | Work |
|---|---|
| 1 | Reader, starting point, definition of done. Full task analysis table. |
| 2 | Group into stages. Write the chapter-two quick run-through first. |
| 3–4 | Draft the stages with checkpoints and inline failure notes. |
| 5 | Verify every specific. Build the troubleshooting table from real symptoms. |
| 6 | Watch three people use it. Take notes, do not help. |
| 7 | Fix everything they stumbled on. Then publish. |
Writing for the reader who is already stuck
Most readers do not start at chapter one. They arrive mid-task, something has gone wrong, and they are scanning for the paragraph that matches their situation. Design for that reader as well as the sequential one.
- Headings that name symptoms, not topics. "The dough will not stretch without tearing" beats "About gluten development".
- Repeat essential context locally. A sentence repeated in chapter nine saves a reader from hunting back to chapter two. Instructional writing is allowed redundancy that prose is not.
- Number your steps globally so people can refer to "step 14" in a forum or a message to you.
- Put a decision table early. "If your situation is A, read chapters 2, 5 and 9" respects the reader's time more than a linear insistence.
A troubleshooting section that works
Organise by what the reader observes, never by cause. They cannot search for a cause they have not identified.
| What you see | Most likely | Try first | If that fails |
|---|---|---|---|
| Loaf spreads flat in the oven | Over-proved | Shorten the final rise by 30 minutes | Check starter strength with a float test |
| Dense, gummy crumb | Under-baked or cut too early | Bake 10 minutes longer, cool fully | Raise oven temperature by 10°C |
| Crust too pale | No steam, or oven too cool | Cover for the first 20 minutes | Preheat longer with the pan inside |
Four columns, ordered by likelihood. The "if that fails" column is what separates a guide written by someone who has taught this from one written by someone who has only done it.
Safety, and when to say "do not do this"
Instructional writing carries a duty of care that fiction does not. Where the task involves risk:
- Put the warning where the action is, not in a preface nobody reads.
- Say what the hazard is and what it does, not just "be careful". "The handle stays hot for twenty minutes and will burn through a tea towel" changes behaviour; "caution: hot" does not.
- Name the limit of the guide. "If the wiring is pre-1970 or you cannot identify the earth, stop and call an electrician." Telling readers when to stop is part of teaching them.
- Have a competent person review anything involving electricity, gas, structural work, chemicals, food safety, medication or vehicles. This is not legal cover; it is the difference between a helpful guide and a dangerous one.
Keeping it current
Instructional books decay. Software changes, prices move, regulations shift. Two structural choices slow the decay considerably:
- Separate the durable from the volatile. Principles and sequence in the book; version-specific screenshots, prices and menu paths in a companion page you control and can update.
- Date the book visibly and say what version it describes. Readers forgive age they can see and resent age they discover.
A short "what has changed since publication" page on your site, linked from the front matter, buys a practical guide two extra years of usefulness for about an hour of work a year.
From guide to product
A how-to book is often the top of a wider offering, and the transitions are natural rather than forced:
- The materials list becomes an affiliate or shop page — disclosed, always.
- The hardest stage becomes a video or a short course, sold or free.
- The template becomes the lead magnet that builds the list.
- The questions readers email you become the second edition. Keep every one; they are the most valuable research you will get.
Turn what you know how to do into a guide people can follow. Neubook Write interviews you for the stages and the stumbles, writes the chapters with checkpoints, and exports EPUB, PDF and a print-ready paperback.
Start a book, freeSources
- Nielsen Norman Group: how users read on the web
- Google Search: creating helpful, reliable, people-first content
- KDP: Keywords
- KDP: Content guidelines, including AI-generated content
Common questions
How long should a how-to book be?
Long enough to complete the task and no longer. Most practical guides land between 20,000 and 45,000 words; padding an instructional book to hit a page count actively harms it.
Should I include screenshots?
Yes where the interface matters, but remember that software changes and screenshots date. Describe the action in words that will still be true, and use the image as support.
How do I test it?
Give it to someone in the target audience and watch them without helping. Every place they hesitate is a defect. Three testers catch most problems.
Book or documentation site?
A book suits a task with a beginning and an end that a reader works through once. Documentation suits reference material people dip into. If your content is mostly lookup, do not force it into chapters.
Is AI good at instructional writing?
It is good at structure, consistent step formatting and covering the cases you forgot. It is bad at knowing which step your readers get stuck on, and it will confidently describe interfaces that do not exist. Verify every specific.