How to Record Software Tutorials People Actually Finish
Plan one-task software tutorials with a beat sheet, pre-flight checklist, per-step takes, and chapter and description templates, backed by video research.
Ask this guide
Answers come straight from this guide’s text. Nothing is generated, and nothing you type leaves your browser.
Plenty of screen-recorded tutorials lose viewers before the end, and some of the causes sit in the production rather than the material: a long intro before anything happens, a cursor drifting while the narrator thinks, one 30-minute take covering six loosely related jobs.
People watch a how-to video to complete a task, so some leave as soon as they have their answer. In a large edX dataset of math and science course videos, viewers watched only 2–3 minutes of a tutorial on average, whatever its length, and re-watched tutorials more often than lectures, a sign the authors read as people skipping to the part they need. So make the task completable, make the right moment easy to land on, and treat a full watch-through as a bonus.
By the end you will have a one-task-per-video workflow, a beat-sheet template, a pre-flight checklist, chapter and description templates, and a rule for splitting videos.
How long should a software tutorial be? What 6.9 million viewing sessions show
Default to one task and one visible result, usually 1 to 4 minutes. Past about six minutes, check for a second task; if there is none, add chapters. That default is our synthesis of the figures below, not a measured optimum.
| Source | What it measured | Figure |
|---|---|---|
| Guo, Kim & Rubin, 2014 | Median watch time, edX math and science videos | At most 6 min, whatever the length |
| Guo, Kim & Rubin, 2014 | Average watch time, tutorial videos | 2–3 min, whatever the length |
| van der Meij & van der Meij, 2013 | Their own Word-formatting videos | Averaged just over 1 min |
| van der Meij & van der Meij, 2013 | TechSmith's Camtasia 7 lessons, which they reviewed | 2–4 min, about 3 on average |
| Plaisant & Shneiderman, 2005 (cited by the van der Meijs) | Suggested length to keep a viewer engaged | 15–60 sec |
What the edX study found
The first two rows come from a 2014 paper by Philip Guo, Juho Kim and Rob Rubin. They mined edX server logs for 6.9 million watching sessions across four university courses from Fall 2012 (862 videos; about 128,000 students, summed across the four courses). The length results use the 76% of sessions played at normal speed. Engagement meant watch time and whether the student attempted the problem that followed. The share of sessions followed by an attempt fell from 56% in the shortest length bucket to 31% in the longest.
The authors advised chunks shorter than six minutes, but two details usually get dropped. Tutorials behaved differently from lectures: students re-watched them more often and paused at specific points, so the authors suggested bookmarks or signposts for skimming. And the limits are real: a retrospective analysis of math and science MOOCs, not a controlled experiment; watch time cannot tell attention from a tab left playing; and "tutorial" meant step-by-step problem-solving walkthroughs (tablet drawings, slides and code screencasts), not software-menu demos. Use the numbers as defaults to check a draft against, not as laws.
The team also coded production styles. Tutorials drawn on a tablet were watched 1.5 to 2 times as long as slide or code-screencast tutorials, and 40% of sessions with them were followed by a problem attempt, against 31% for the rest. They suggested sketching over slides or code that must be shown. Read it as a nudge toward visible motion and annotation, not a verdict on screencasts.
What the software-training research adds
Hans van der Meij and Jan van der Meij proposed eight guidelines for software videos in 2013. They built Word-formatting videos on them and compared those with a paper tutorial in three experiments, which the paper cites as still in preparation or review: the videos did better on motivation, on skills straight after training, and on skills a week later. That supports the video set as a package, not each guideline separately.
Scope one task, then write the beat sheet
Title the video with the verb phrase a user would type
Organizing a tutorial around your menus ("First, the File menu…") produces a tour, and viewers arrived with a task. Make each video one task: "Schedule automatic backups", not "Overview of the Settings panel". The van der Meijs add that a title should state the goal, since title words are what searches match. If the title needs "and", you have recorded two videos.
Split at sub-goals, not at a stopwatch
| What you see in the draft | What it usually means | What to do |
|---|---|---|
| The title needs "and" | Two tasks | Two videos, each ending on a visible result |
| More than five actions pass with no visible result | The sub-task is too big to follow | Add a checkpoint or split here |
| Runtime passes about six minutes | Probably more than one task | Re-run the title test; if it is one task, add chapters |
The van der Meijs call an arbitrary time limit for splitting a long task "hardly satisfactory"; what matters more is that a viewer perceives a clear beginning and end, usually at goal or sub-goal completion. The five-action figure comes from a common suggestion, reported by them, of three to five actions per sub-task. Treat it as a smell test.
A beat-sheet template
A full script produces read-aloud deadness; pure improvisation rambles. The middle path is one line per step: the action, the one thing worth saying, and the result the viewer should see. Here is one for a hypothetical backup app:
TITLE: Schedule automatic backups
END STATE: Backups tab showing "Next backup: tonight 02:00" (opens the video)
PREREQ: One sentence, said once: app installed, a destination exists
TRY-IT: A practice task plus a sample file for after the video
# ACTION (what the cursor does) SAY (one thing) RESULT SHOWN
1 Settings > Backups Where it lives; why it is off Backups panel
2 Pick the destination folder Local vs cloud, one sentence Path in the field
3 Set schedule: daily, 02:00 Daily suits most; name the exception Schedule row
4 Run the first backup How to confirm it worked "Last backup: just now"
CLOSE: Point to the next task; say what to do if step 4 fails
A beat sheet heads off two familiar problems: the silence while you work out what is next, and the "actually, let me go back" detour. Keep the SAY column procedural; the van der Meijs argue for concepts only when they clearly help the viewer understand the task and take little time to explain. At Guo's mean speaking rate of 156 words per minute, a 15-second step has room for about 40 words, so a SAY cell that needs more is probably two points.
Stage the recording with a pre-flight checklist
- Clean demo environment. A fresh profile or demo account, with no customer data, personal tabs or saved credentials in view. The screen-recording leak checklist covers what slips into frame.
- Notifications off. On a Mac, click Control Center in the menu bar, click Focus, pick Do Not Disturb, and choose a duration such as "For 1 hour" (Apple's steps, which document macOS 27). The 30-minute notification audit covers the longer-term fix.
- Readable at the size you publish. For 1080p output, record a 16:9 area and export at 1920×1080. As a rough test, export 20 seconds and play it in a window about a third the width of your screen; if you cannot read the button labels, raise the app's zoom. Show the whole interface by default, as the van der Meijs advise, and zoom in the edit only for a click or typed text.
- A cursor you control. Move deliberately to the target, then stop. Park it while you talk; a circling cursor is the visual equivalent of "um".
- An audio check. Ten seconds of speech, played back on headphones; the budget microphone guide covers the cheap fixes. On a Mac, Shift-Command-5 opens the screenshot toolbar, whose Options menu has Microphone and Timer settings, and it saves recordings as .mov files (Apple's page). On Windows, the Windows logo key + Shift + R starts a Snipping Tool recording (Microsoft's steps).
- A dry run and a resettable start state. Do the beat sheet once without recording, so first-launch dialogs and expired sessions show up here instead of mid-take. For every step, know how to return to its starting condition: a duplicated project, a snapshot, a script.
Our recorder, TechCast Studio, runs readiness checks for audio, system, readability and privacy before recording; it is in Founding Beta on Apple Silicon, and the public desktop download is not open yet. The checklist works with any recorder.
Record one step at a time with a silent hold on each result
Use per-step takes when the video runs past one sub-task; three to five actions fit in a single take. Otherwise, do not attempt the whole tutorial in one heroic take. Record one beat-sheet row at a time:
- Reset the app to that step's starting state.
- Start recording and stay silent and still for a second or two.
- Do the step while saying your one line.
- Stop on the result: leave the outcome on screen and hold still for three to five seconds.
- If you flub a line, hold still for two seconds, then redo the step from its start, not from mid-sentence.
- Play back the last ten seconds before moving on.
Separate takes drift, so match these between them: window position and size, cursor start point, scroll offset and zoom, theme and font size, mic distance and input gain (set it once, then leave it), and the menu-bar clock and badges. Record a few seconds of room tone once to cover gaps.
Treat the hold as two things. In the raw take it is a silent handle: stillness before and after each step makes a clean cut. In the finished video it is a pause for the viewer. The van der Meijs cite evidence that pauses as short as 2 seconds can help (from studies of animated worked examples, not software videos), mention designers adding 2 to 5 seconds at natural breaks, and used about five seconds in their own Word videos. Trim the handles; keep 2 to 5 seconds after each visible result.
On pace, Guo's team found that faster speakers tended to hold viewers longer, though they called speed a surface feature that correlates with enthusiasm and said speeding up a flat speaker might not help. The van der Meijs, writing about software novices, advise a conversational tempo and warn that a brisk pace can outrun a beginner. So sound interested, and keep the pace conversational while the cursor works.
Edit for skimmers: chapters, a before-and-after opening, restrained cues
Turn the beat sheet into chapters
Your beat sheet is already the chapter list: the END STATE becomes the first chapter and each row becomes one more. YouTube's rules for manual chapters, which go in the video description, are:
- The first timestamp must be
00:00. - There must be at least three timestamps, in ascending order.
- Each chapter must be at least 10 seconds long.
A manual list overrides automatic chapters, which are on by default for new uploads (the "Allow automatic chapters" checkbox). For the hypothetical backup video:
00:00 What you'll have by the end
00:12 Open the Backups settings
00:40 Choose a destination
01:25 Set the schedule
02:05 Run the first backup and confirm it worked
If chapters do not show, recheck those rules. YouTube's chapters page also lists causes outside your control, such as an active channel strike.
A beat sheet turns into a timestamp list like this one. Google says it prioritizes key moments given as timestamps and labels in a YouTube description (Google Search video guidance).
Open with the finished result
Open with a short before-and-after preview, not a channel intro. The van der Meijs' previews show the goal, speak to the viewer as "you", introduce key terms as they appear, and skip step-by-step detail. In the action steps they prefer short imperative narration: "Select the Backups tab", not an essay on why.
Cut dead time, but say how long the wait is
Cut or speed up loading spinners and long installs, but say how long the wait takes in real life ("this takes about 30 seconds the first time") in a label or spoken note. The van der Meijs call wait-time information "always important", because it is not self-evident that the viewer must do nothing. Also cut typing of a value you have already stated, and filler words; the edX producers in Guo's study edited out "umm" and "uhh".
Use cues sparingly
Highlighting has mixed evidence, and the studies measure different outcomes: Guo's tablet result is about engagement, while a 2021 experiment with 118 undergraduates found that added shapes and brightness frames in three video-editing tutorials made no difference to task performance. A meta-analysis of 29 cueing experiments (Alpizar et al., 2020, as summarized by that experiment's authors) found cues can help guide attention, so the null result is one data point, not the last word. The van der Meijs recommend highlighting, and used a red circle or a red arrow.
A workable rule: one cue style per video, only where the eye might miss the target (a small icon, a crowded toolbar), plus a zoom for clicks and typed values.
Publish with a text layer, then check where viewers leave
A video with no text around it is harder to search and slower to use as a quick reference. Put this in the description and on the docs page where you embed the video:
Schedule automatic backups in <App> <version> (about 3 minutes).
Before you start: <one-line prerequisites>
00:00 What you'll have by the end
...chapters...
Copy and paste: schedule = daily 02:00
Next: <link to the follow-up task>
Last checked against <App> <version> on <date>.
The "last checked" line matters because interfaces change, and a viewer on a newer version needs to know whether to trust step 3. For some viewers the text will get more use than the video: the video demonstrates, the text serves the person who needs one flag name.
Captions belong in the text layer
WCAG 2.2 success criterion 1.2.2 (Level A) asks for captions on prerecorded audio in synchronized media, with a narrow exception for clearly labeled alternatives to text. Beyond compliance, Morton Ann Gernsbacher's 2015 review cites more than 100 empirical studies finding that captions improve comprehension, attention and memory, most clearly for people watching in a non-native language, people learning to read, and deaf or hard-of-hearing viewers. It is a single-author review, so read "benefits everyone" as strongest for those groups.
YouTube says to always review automatic captions and edit anything not transcribed properly (YouTube's captions help); in Studio, that is Subtitles in the left menu. Check product names, command flags and menu labels first, because a wrong word there changes what the viewer types.
Close with a try-it, then read the retention graph
End by inviting the viewer to practice on a sample file with a stated goal. The van der Meijs cite an experiment in which practice after a video significantly improved performance compared with no practice.
A few days after publishing, open YouTube Studio, choose Content, pick the video, open Analytics, and find the audience retention report. It shows the share of viewers still watching after 30 seconds, plus spikes (parts re-watched or shared) and dips (parts skipped or abandoned). YouTube notes a spike can mean a section was unclear, and data takes one to two days to process.
Read it against your beat sheet. A spike on step 3 may mean that step is unclear; re-record step 3 with a clearer cue, not the whole video. Because tutorial viewers jump to the step they need, read a dip together with what follows: in our reading, a dip that recovers at the next chapter means people skipped a step they already knew, while one that stays down means they left. With only a few dozen views, one viewer moves the line, and YouTube highlights key moments only for videos of at least 60 seconds with at least 100 views. Its SEE MORE option compares your video with similar-length ones; check it before re-recording anything.
Where to start this week
Pick your most-watched tutorial and open its retention report. Re-record only the step with the worst dip or biggest spike, then add chapters and a description with copyable values. For the next video, write the beat sheet before you open the recorder.
Frequently asked questions
What if the task really takes 15 minutes?
Split it at sub-goals, each ending on a visible result, and publish the parts as a numbered series with an index page. The van der Meijs split a cumbersome formatting task the same way. Chapters help inside each part.
Should I narrate live or record the voice-over afterwards?
Live, one step at a time, is the simpler way to keep action and voice in sync, which the van der Meijs list as a guideline. If you prefer voice-over, record it against the finished picture one step at a time. Their 2013 paper favors a human voice over a computer-generated one, so it cannot speak to modern synthetic voices.
How do I stop a tutorial going stale when the software updates?
Put the app version in the description and re-record only what changed, since you recorded per step. This triage is a rule of thumb, not research:
| What changed | What to do |
|---|---|
| A label or button was renamed and your voice-over names the old one | Re-record that step |
| A menu path moved | Re-record that step and rename its chapter |
| A visual refresh with the same paths | Keep the video; update the "last checked" line and pin a comment |
| A changed default alters the result | Re-record from that step onward |
Do I need captions if the page has a written walkthrough?
Probably yes. WCAG 2.2 SC 1.2.2 exempts only media that is clearly labeled as an alternative to text, which the W3C defines as media presenting no more information than the text already does. A tutorial that shows more than the text says, such as where to click, does not qualify. This describes the standard, not legal advice.
Sources and further reading
- How Video Production Affects Student Engagement: An Empirical Study of MOOC Videos — Guo, Kim & Rubin, ACM Learning at Scale, 2014. Sessions, length, tutorials, speaking rate.
- Eight Guidelines for the Design of Instructional Videos for Software Training — van der Meij & van der Meij, Technical Communication, 2013. Length, preview, pauses, highlighting.
- Optimizing Video Tutorials for Software Training Through Cueing — Ragazou & Karasavvidis, Mobile Learning and Educational Technologies conferences, 2021. A 118-student cueing experiment.
- Video Chapters — YouTube Help. Chapter rules.
- Measure key moments for audience retention — YouTube Help. The retention report.
- Understanding SC 1.2.2 Captions (Prerecorded) (Level A) — W3C, WCAG 2.2. Caption requirement and exception.
- Video Captions Benefit Everyone — Gernsbacher, Policy Insights from the Behavioral and Brain Sciences, 2015. Caption review.
TechCast Studio is a local-first recording workspace for technical creators, currently in Founding Beta on Apple Silicon. The method above works with any recorder and editor you already have.