How to plan a software tutorial before you hit record

Most software tutorials go wrong before anyone presses record. The recording itself is usually fine. The problem is that nobody decided who the video was for, what they should be able to do at the end, or what exactly would be said over each click. So the narration wanders, the cursor hunts for the next button, and a three-minute task becomes a nine-minute video.

Planning fixes that, and it doesn't take long. Here's the process we use, in the order we use it.

1. Write the idea in two sentences

Start with the problem the video solves, not the feature it shows. "A walkthrough of the sharing settings" is a feature. "New users can't find how to invite a teammate, so they email files instead" is a problem. The second one tells you what to show, what to skip and where the video will be linked from.

Then pick a format. Most tutorials are one of four things:

• Story: how something happened, or a customer's path from A to B.
• Teach: a concept, with examples.
• Explain: why something works the way it does.
• Demonstrate: do the task on screen, step by step.

A software guide is nearly always demonstrate. Knowing that up front stops you from drifting into a ten-minute explanation of the permission model when the viewer only wanted to send an invite.

2. Describe the viewer, honestly

Write one line about who's watching and one about what they already know. "Team leads in their first week, who've never opened the settings page" is useful. "Everyone" is not.

Knowledge level changes everything downstream. Beginners need you to say where the button is. Experienced users need you to skip that and get to the part they're stuck on. If you can't decide, you probably have two videos.

3. Turn the goal into objectives you can check

An objective is something the viewer can do after watching, phrased as an action:

• Find the Share button on any project.
• Pick the right role for a teammate.
• Know that an invite can be undone.

Three is a good number for a short tutorial. If you have seven, split the video. Keep the list next to your script, and when you review the edit, tick each one off. If you can't point to the moment that achieves an objective, it isn't in the video yet.

4. Check your facts and keep your sources

Software changes. Before you script, open the product and do the task yourself, start to finish, on a fresh account if you can. Note anything that differs from the docs.

When you rely on a help article, a forum thread or an old slide deck, write down where it came from and how much you trust it. We use four labels: verified, likely, unverified and disputed. Anything below "verified" gets checked before it goes into the narration.

It's also worth watching two or three existing videos on the same task. Note what they do well and where you lost interest. That's your bar to clear.

5. Write the hook last, then put it first

The first few seconds decide whether people stay. A good tutorial hook does two jobs: it confirms the viewer is in the right place, and it tells them how long this will take.

"Sharing a project takes two steps, and you can undo both."

That's eleven words. It names the task, sets expectations and removes a worry. You don't need a channel intro or a summary of what you'll cover.

6. Script in segments: narration and visuals side by side

Break the video into sections, and each section into short segments. For every segment, write two things:

1. Narration: exactly what you'll say, in the words you'd actually use out loud.
2. Visuals: what's on screen, and what you'll add in the edit.

Writing visuals next to narration catches problems early. If a line of narration has no visual, the viewer is looking at a static screen. If a visual has no narration, you're asking them to work it out alone.

Keep narration short and concrete. Say "click Share", not "navigate to the sharing functionality". Read each line out loud; if you stumble, rewrite it.

7. Estimate the length before you record

People speak at roughly 130 to 160 words a minute when explaining something on screen. Count the words in your narration, divide, and add a little for pauses and on-screen actions that happen without talking.

If the estimate is twice what you wanted, cut now. It's much cheaper to delete a sentence than to edit around it later.

8. Record in pieces, against the script

With a script, you don't need one perfect take. Record each section separately: share a single window or tab rather than the whole screen, so notifications and other apps stay out of the shot. Close anything with personal data you don't need, and remember that what you can't close, you can blur in the edit.

Record your voice-over against the picture afterwards, segment by segment, reading from the script. It's faster than talking while clicking, and it sounds calmer.

Doing all of this in one place

You can plan in a doc, research in bookmarks and edit in a separate app. It works; it's just a lot of switching. We built FluidEditor so each step lives in the same project: a Planning tab for the idea, topic and format; a Research tab for the audience, sources with accuracy ratings, example videos and objectives; and a Script tab for the hook, sections and segments, with narration, visual notes and an estimated length.

When the script is ready, you can send it to the timeline: each section becomes a marker and each line of narration becomes timed text, ready to record against and turn into captions. Then you record your screen in the browser, add zooms, arrows and step badges, and export.

If that sounds like how you'd like to work, see how it fits together for tutorials and software guides.

A checklist to copy

• Problem in two sentences, and a format.
• Viewer and their knowledge level.
• Three objectives, phrased as actions.
• Task done end to end, sources noted and rated.
• A hook under fifteen words.
• Every segment has narration and visuals.
• Length estimate within your target.
• Recording plan: which window, what to close, what to blur.