Start with one goal per article and write the title as the task the reader wants to finish
A help article that covers three tasks gets skimmed and then abandoned. Good step by step help article screenshots start with one clear job for the reader. Pick one goal and write the title as the thing the reader wants to get done. 'Invite a colleague to your workspace' tells a reader what they will achieve. 'Team settings' tells them where they are, which is not the same thing.
Before you write the first step, check that the goal has a clear end point. If you cannot describe success in one sentence, you probably have two articles. Split them. Readers searching for help usually arrive with one question, and a single-goal article answers it quickly.
Number the steps and keep each to a single action, with the exact button or field name in bold
Use a numbered list, and give each step one action: click, type, choose, or check. 'Click Save changes and then close the window' is two steps hiding in one line. Split it, and the reader can stop and check after each action.
Name every control exactly as it appears on screen, in bold. Write Save changes, not 'the save button' or 'the green button at the bottom of the page'. Descriptions like that depend on what the screen looks like today, and they break as soon as the layout moves. Copy field names from the interface rather than from memory, including capital letters and punctuation.
Keep the sentences short and in the same order as the screen. If the reader has to scroll, say so in the step: 'Scroll down to Billing details.' Small things like this save people from hunting around the page.
Choose screenshots that earn their place: crop to the relevant area, mark the click point, keep them consistent
A screenshot should help a reader find something or confirm they are in the right place. It does not need to show the whole application. Crop each image to the area that matters, so the button or field is large enough to recognise without zooming in.
Mark the click point with a simple box, circle or arrow, and use the same marking style throughout the article. If every image uses a different colour or annotation, readers stop trusting the markers.
Keep the same window size, zoom level and crop across the article where you can. When every screenshot is framed the same way, the reader does not have to re-orient themselves on each image. Do not add a screenshot to every step by default. Add one where the screen is busy, where the next click is not obvious, or where a reader is likely to get lost. A text step that says exactly what to do is often enough for the rest.
Blur personal data in screenshots before publishing, and use sample data where you can
Real accounts contain names, email addresses, phone numbers and invoices. Before you publish, remove or blur anything that identifies a person or customer. In HandHoldly, personal data is blurred in the video, screenshots and article, but check each image yourself before it goes live rather than relying on a single pass.
Sample data is the better habit. Set up a test company, a made-up contact and dummy amounts, and capture your screenshots from that account. The article then shows exactly what the reader will see, and there is nothing to hide. Use the same sample names across the article and across your other help content, so a reader who moves between pages sees a consistent story.
Add expected results ('You should now see...') so readers know they are on track
After any step that changes something, tell the reader what they should see next. 'You should now see a green confirmation message at the top of the page' is a simple line, but it does a lot of work. It tells the reader they are on track, and it gives them a clear signal when something has gone wrong.
Keep expected results specific. 'The page updates' is vague. 'The name Priya Shah appears in the list of team members' gives the reader something to compare against. Use them after the steps where a reader is most likely to doubt themselves, such as saving, sending, or switching settings. You do not need one after every line.
Test the article by following it cold, or ask someone new to the product to try it
The best test is to follow your own article without your product knowledge. Open a fresh test account, or a browser where you are not signed in, and work through every step exactly as written. Do not fill in gaps from memory. Each time you pause, or think 'I know what they mean', note it down and rewrite that step.
Better still, ask someone new to the product to try the article while you watch quietly. Do not help them. Notice where they hesitate, where they scroll past a step, and where they read a button name differently from the one you wrote. Those moments show you where the article needs a clearer name, a better screenshot, or an extra expected result. Repeat the test once you have made changes, because a fix in one place can create a new gap in another.
Keep it right as the product changes: how one script can produce the article, the video and the live guide together, so a fix is made once
A help article is only useful while it matches the product. The usual problem is that the same steps live in three places: a help centre page, a training video, and a tour inside the app. When a button moves, someone has to remember to update all three, and one of them is usually missed.
HandHoldly takes a different approach. One script produces a narrated video, a live guided tour inside your app, and a step-by-step help article. You write the steps once, and the three outputs come from the same source. When a button is renamed or a screen changes, you fix the step in the script, and the article, video and guide reflect that fix. You are not hunting for the same wording in three different tools.
Nightly re-checks help you find problems before customers do. A scheduled check flags any step that no longer works, fires your webhooks, and emails the owners with the step named, so you know which line to look at. Re-checks flag a broken step; they do not repair it on their own.
AI is optional. When it is switched on, it can find a button that has moved or been renamed and draft a replacement step. You check that draft before saving it into the script with one click. Treat it as a suggestion to review, not a sure correction.
If you want to see how one script becomes a step-by-step article with screenshots, alongside the video and the live guide, See how it works.