A "how to" guide answers a specific question by walking someone through actual steps in actual order
A "how to" guide is not a definition, a list of options, or an explanation of why something matters. It is a set of concrete steps that take someone from "I don't know how to do this" to "I did it." The reader arrives with a problem and leaves with a result.
The difference matters because a reader searching "how to reset my router" does not want to understand networking. They want their internet back. A reader searching "how to find my Wi-Fi password" does not want a history of password security. They want the six characters they need to type.
A good "how to" guide names the actual thing at each step — the real button, the real menu, the real file name — so someone can follow it without guessing or backtracking.
Key Takeaways
- Start by naming what the reader will have done when they finish, not what the guide will teach them.
- Break the task into the smallest steps that still make sense, and number them in the exact order someone must follow.
- At each step, name the actual button, menu, file, or window the reader will see, not a general description of it.
- Include what the reader should expect to see after each step, so they know whether they did it right.
- Add a troubleshooting section only if the task commonly fails at a specific point, and name the actual error message or problem.
Start with the actual outcome, not the topic
The opening sentence must answer the question in the title. If the title is "How to back up your iPhone," the opening is not "Backing up your iPhone is important for data protection." It is "You can back up your iPhone to iCloud or to a computer using a cable, and iCloud is faster if you have Wi-Fi."
Name the real choice the reader faces, or name the one path if there is only one. Then say what they will need before they start — a cable, a password, a file, a second device, whatever is actually required. A reader who discovers halfway through that they need something they do not have will abandon the guide.
Do not explain why the task matters or what it does in the background. The reader already knows they need to do it. They are here for the steps.
Number every step and name the actual thing at each one
Break the task into steps small enough that each one is a single action. "Open Settings and turn on two-factor authentication" is two steps, not one. "Open Settings" is step one. "Tap Account Security" is step two. "Toggle on Two-Factor Authentication" is step three.
At each step, name what the reader will actually see on their screen. If you write "Click the menu button," a reader on an older version of the software might not recognize it. If you write "Click the three horizontal lines in the top right corner," they will find it. If a button has a label, use the label: "Click Save," not "Click the button on the right."
After each step, write what the reader should see next. "You will see a blue checkmark appear" or "The window will close and you will return to the home screen." This tells them whether they did the step correctly without making them guess.
Use a table or screenshot only when steps happen in parallel
Most "how to" guides should be numbered steps in order. A table or image slows a reader down unless the steps genuinely happen at the same time or the reader needs to choose between options before they start.
If the guide says "On a Mac, do this. On a Windows computer, do that," a table makes sense because the reader needs to pick their path before step one. If the guide says "First do this, then do that," a numbered list is faster to follow.
A screenshot helps only if the button or menu is hard to find or has changed recently. If the button is labeled clearly, the reader will find it without a picture. If you do include a screenshot, point to the exact thing the reader should click: "Click the Settings icon (the gear in the top right corner)" works better than a picture alone.
Add troubleshooting only for common failure points
If the task usually works the first time, do not add a troubleshooting section. If the task commonly fails at one specific step — a password does not work, a file does not upload, a connection times out — name that step and the actual error message the reader will see.
Write what to do about it. "If you see 'Password incorrect,' make sure Caps Lock is off and try again" is useful. "If something goes wrong, restart your device" is not, because it could mean anything and the reader will try it anyway.
Keep troubleshooting short. If the task has many failure points, the steps themselves are probably too complicated and should be broken down further.
Test the guide by following it without the software in front of you
Read your guide as if you have never done the task before. Can you follow step one without looking at your device? Can you find the button in step two using only the name you wrote? Would you know whether you did step three correctly?
If you wrote "Click Settings," a reader on a phone will look for a gear icon. A reader on a computer might look for a menu. If you wrote "Open the Settings app" on a phone or "Click Settings in the menu bar" on a computer, they will find it.
Ask someone who has never done the task to follow your guide while you watch. Where do they hesitate? Where do they look for something you did not name? That is where your guide needs more detail.
Keep the language simple and the steps short
Use the shortest word that means the thing. "Click" instead of "select." "Open" instead of "launch." "Turn on" instead of "enable." A reader following steps is not reading for pleasure — they are reading to finish.
One sentence per step is usually enough. "Click the three dots in the top right corner" is clear. "Click the three dots in the top right corner, which will open a menu with more options" is slower to read and the reader will see the menu anyway.
If a step requires explanation, the step is too big. Break it into smaller steps instead.
Frequently Asked Questions
Should I include a "what you will need" section?
Yes, at the very beginning. List everything the reader must have or know before they start: a password, a cable, a second device, a file, an account. A reader who discovers halfway through that they need something they do not have will abandon the guide and blame themselves.
How detailed should each step be?
Detailed enough that someone who has never done it before can follow it without guessing. If you have to write "and then you will see a menu," the step is clear enough. If you have to write "and then you might see a menu, or you might see a dialog box depending on your settings," the step is too vague and needs to be rewritten or split.
What if the steps are different on different devices or versions?
Write separate guides for each one, or clearly label each path at the beginning: "These steps are for iPhone. If you have an Android phone, see this guide instead." Do not try to cover both in one guide — it confuses readers and makes the steps harder to follow.
Should I explain what each step does in the background?
No. The reader wants to finish the task, not understand how the software works. If the explanation is necessary to understand why they are doing the step, the step itself is probably unclear and should be rewritten.
How long should a "how to" guide be?
As long as it takes to complete the task, no longer. A simple task might be five steps. A complex one might be twenty. If your guide is over thirty steps, consider whether it should be split into multiple guides, each covering one part of the larger task.