How to make a tutorial video

The difference between a tutorial that works and one that does not is whether the viewer sees the thing happen.

PageToVid films your page in a real browser, and a shot can perform an action before it is captured: click a button, type into a field, hover to reveal a menu, or spotlight one element while the rest dims. So "then you search for a customer" can be a shot of the search box with a real query typed into it, not a caption over a static page.

That is the whole technique. Each step in the tutorial becomes a scene, each scene is pointed at the element that step is about, and the action is performed on camera.

1. 1Write the steps first, as a numbered list. If you cannot write them, the tutorial is not ready to film. Five to eight steps is the useful range.
2. 2Inspect the page and note the selector for the element each step touches. The ranked subjects come back with selectors already verified against the page as it rendered.
3. 3One step per scene. Two steps in one scene is how a viewer loses their place — and since the narration sets the length, splitting costs no extra seconds.
4. 4Point each scene at its element with a click, some typing, a hover or a spotlight.
5. 5Narrate in the imperative. "Open the settings panel." Not "you would then open the settings panel."
6. 6Use `checklist` for the overview scene if you want to show the shape of the whole process before starting it.

Tutorials fail on pace more than on content. The viewer is switching between your video and their own screen.

• Slower than an ad, by a lot. 110 words a minute is the delivered pace, and a tutorial should sit at the roomy end of it — leave the words sparse and let the footage hold.
• Name the thing you are clicking before you click it. "In the top right, open Settings" gives them time to find it.
• One idea per scene, strictly. This matters more here than in any other format.
• Let a complex step breathe. A silent scene with a duration holds a screen still — useful when someone needs a moment to catch up.

A tutorial can be two minutes. Nobody scrolls past a tutorial they are actively following; the audience for this format has already decided to watch.

Most real tutorials are of an application, and applications are behind a sign-in. A page that answers with a login screen is refused before anything is charged — the tool will not pretend to film it.

The supported path is a capture session: you sign in once from the VS Code or browser extension and register the session, scoped to that one origin and expiring within three days. Renders can then film inside the application. It is a Scale-plan capability.

Film a demo account, never a real one. A capture records what is on screen, and a tutorial published with a customer's name in the sidebar is a data-protection incident with your logo on it.

A tutorial's value decays every time the interface changes, and the usual failure is nobody noticing.

Because the film is generated from the live page rather than from a recording somebody made once, re-rendering re-films the current interface. So the maintenance job is small: when a screen changes, re-render the tutorial. The narration, the structure and the timing survive; only the footage updates.

If you maintain a set of them, that is worth automating — the API can re-render on release, so the tutorials match the product you actually ship rather than the one you shipped when somebody had time to record a screencast.

• In the docs, next to the written steps. Not instead of them — people search text and watch video, and the pair converts far better than either alone.
• In onboarding email two, after the account exists and before the first week ends.
• In your support macros. A tutorial linked from a reply closes tickets that a paragraph does not.
• On YouTube, titled with the exact task. "How to export a report in [product]" is a search someone is performing right now.

Render at 16:9. A tutorial is watched deliberately, usually on a desktop, next to the application it is teaching.