Most walkthroughs that need rewriting were rushed at the start. Someone opens the product, starts recording or typing, and only then notices that the starting page was wrong, that a button has two labels, or that the screen shows a customer's name. Fixing those things after the script is written costs far more than settling them first.
That matters more when one script feeds several outputs. In HandHoldly, one script can become a narrated video, a live guide inside your app and a step-by-step help article. A plan that only suits one of those will cause trouble in the other two. A short planning page, filled in before anyone writes a sentence of narration, keeps all three on the same track.
Step 1: Name one task and one reader
Start with a single sentence that names the task and the person doing it. For example: 'A new admin invites a teammate.'
Keep it to one task. If the sentence needs the word 'and' twice, you have two walkthroughs. Splitting them now is much easier than trimming a long video later.
The reader matters as much as the task. A new admin knows where the settings menu is or does not, and the plan should reflect that. Write down what they already know, so you do not explain things they have seen a hundred times, or skip things they have never met.
Step 2: Note the starting point
Write down exactly where the reader is when the walkthrough begins. Which page are they on? Are they logged in? Do they have a particular role, such as admin or member?
This step prevents the most common complaint about help content: the first instruction assumes a screen the reader never sees. If the starting point is 'the dashboard, logged in as an admin', say so in the plan. A live guide needs this detail to appear in the right place, and an article needs it to make sense to someone reading it cold.
Step 3: List the clicks and entries in order
Now list every click and every field the reader must touch, in order. Use the exact label that appears on the screen, not the name your team uses internally. If the button says 'Send invite', write 'Send invite'. If it says 'Invite member' in one place and 'Add person' in another, note both and check which one the reader will see.
Exact labels matter because they are what the reader looks for. They also make the nightly re-checks in HandHoldly more useful. When a step stops working, the alert names the step, so a step written with the real label is easier for the owner to find and fix.
Keep each line short. 'Click Team in the left menu' is enough. You can add explanation when you write the script, but the plan only needs the actions.
Step 4: Mark where personal data could appear
Go through each screen and mark anything that could show personal data: names, email addresses, phone numbers, order details, anything a real customer might have entered. Mark the screens that show lists, because lists are where personal data tends to hide.
HandHoldly blurs personal data in the video, the screenshots and the article. The plan's job is to make sure you know where that data appears, so you can check the output rather than discover it after publishing. Do not rely on the blur alone. Use a demo account with made-up details wherever you can.
Step 5: Mark any delete, pay or send step
Find every step that deletes something, takes a payment or sends a message. Mark each one clearly in the plan.
HandHoldly refuses delete, pay and send buttons unless a step says otherwise. That rule is useful, but it should be a decision, not an accident. Ask yourself whether the walkthrough should press the button at all. Often the answer is no: the reader needs to know the button exists and what it does, but the walkthrough can stop just before it. If the walkthrough does need to press it, write that intention into the plan so the step is allowed on purpose.
Step 6: Decide the finish line
Finally, decide what the reader should see when the task has worked. Be specific. 'The teammate appears in the members list with the status Pending' is a finish line. 'It all works' is not.
The finish line tells you when to stop. It also gives the reader a way to check their own progress, which is often what they are really after. If you cannot describe the finish line in one sentence, the task is probably not yet one task.
The template itself
Copy the layout below into a document, one page per walkthrough. Fill in each line before you open the product.
Task: (one sentence, one task)
Reader: (who they are and what they already know)
Starting point: (page, logged in or not, role)
Steps, in order, with exact labels: 1. 2. 3.
Personal data on screen: (list the screens and fields)
Delete, pay or send steps: (list each one, and whether the walkthrough presses it)
Finish line: (what the reader sees when it has worked)
A page like this takes ten minutes for a simple task. It is worth doing even when the walkthrough feels obvious, because the obvious ones are the ones that get copied into other documents and go stale.
How the plan turns into a script
Once the plan is complete, the script is largely a matter of turning each numbered step into one plain sentence. Keep one sentence per step. That sentence can be narrated as it is, shown as a live guide step, and used as a heading or instruction line in the help article.
For example, step 3 in the plan might read 'Click Team in the left menu.' In the script, that becomes 'Select Team in the left menu.' The live guide highlights the same item, and the article uses it as step three with a screenshot. The wording is the same across all three, so a reader who watches the video and then opens the article is not confused by two different instructions.
If you use the optional AI drafting in HandHoldly, it can suggest wording from your plan. Treat those drafts as a starting point to check against the real screen, not as finished text. The plan is what makes that checking quick, because every line already names a label and a screen.
A worked example
Here is a plan for a made-up product, a small booking app called Tallyroom. The task is 'A new admin adds a room to the bookings calendar.'
Task: A new admin adds a room to the bookings calendar.
Reader: A new admin who has used the calendar as a member but has never added a room.
Starting point: The Calendar page, logged in as an admin.
Steps, in order, with exact labels:
- Click Rooms in the left menu.
- Click Add room.
- Type the room name in the field labelled Room name.
- Choose a capacity from the Capacity list.
- Click Save room.
Personal data on screen: None on the Rooms page. The example uses the demo room 'Meeting Room A'.
Delete, pay or send steps: None. Save room is a save, not a send, so the walkthrough presses it.
Finish line: 'Meeting Room A' appears in the Rooms list with a capacity of 8, and it can be selected when booking on the Calendar.
The plan fits on one page and shows every decision. The reader is clear, the starting point is clear, and the finish line tells both the writer and the reader when the task is done. From here, the script is five short sentences, and each one can drive the video, the live guide and the article without rewriting.
See how it works
If you want to see one script become a narrated video, a live guide and a help article, the HandHoldly overview shows how the steps move from one format to the next. See how it works.