A product video follows someone completing a task. The viewer sees the starting problem, the action that changes it, and enough evidence to understand the result. That sequence gives each feature a reason to appear.
The task can be ordinary. A support lead assigns a request, a developer identifies a failed check, or an analyst builds a weekly report. An explanation does not need an invented crisis to make those actions worth following.
Choose a structure from the product's behavior
A before-and-after comparison suits a visible change in the same task. A guided build suits a product whose value appears as someone creates and uses a working artifact. A recovery sequence suits a product that helps someone find and correct a specific failure.
| Structure | Material it needs | What the ending must show | Common weakness |
|---|---|---|---|
| Before and after | Comparable starting and ending conditions. | The improvement and the action that produced it. | The film skips the mechanism between the two conditions. |
| Guided build | A small artifact and the steps needed to create it. | The artifact working with representative input. | The film ends on configuration without testing it. |
| Recovery | A reproducible failure and a supported repair path. | A successful retry or a clearly bounded diagnosis. | The film implies the product repairs an issue that a person actually fixes. |
A feature list does not tell you which structure fits. A recording of a real task often does. The product owner can identify where a user makes a decision, which result they inspect, and which details the film can safely omit.
The material for this tutorial
The worked example uses LedgerView, a fictional reporting tool. An operations analyst needs a weekly list of orders that have not shipped. LedgerView imports a CSV, filters rows, saves a report, and reruns that report with a replacement file. These are teaching assumptions, not claims about a real service.
The sample file contains five orders:
order_id,status,total
LV-101,Shipped,42
LV-102,Unshipped,68
LV-103,Shipped,25
LV-104,Unshipped,91
LV-105,Cancelled,30
The viewer already understands spreadsheet rows and filters. They want to know whether they can reuse a report without rebuilding its filter each week. The desired understanding is, “The saved report retains its Unshipped filter when I import next week's file.”
A production brief should also record the intended player, the final invitation, and the product evidence. For a real reporting tool, attach a recording of the complete workflow, including how the user supplies the replacement file. Do not infer automatic refresh from a saved filter.
Step 1: Identify the result that answers the question
The first result should show LV-102 and LV-104 in a report named Unshipped orders. That establishes the filter, but it does not yet establish reuse. The film therefore needs a second run with changed input.
For the second file, change LV-102 to Shipped and add LV-106 with status Unshipped. The final result should contain LV-104 and LV-106. The saved condition must remain Status equals Unshipped.
This second run earns its place because it proves a different part of the claim. Repeating the original run with identical data would show the same result again without explaining what the saved report preserves.
Step 2: Compare possible outlines
A before-and-after version could show a raw file followed by the filtered report. That explains selection, but it needs another step to establish reuse. A recovery version would require a failure, such as an incorrect filter, that the audience did not ask about.
A guided build fits this task because the viewer needs to understand what the analyst saves and what changes on the next run. The sequence begins with the file, creates the report, and tests it with replacement data.
The decision does not make guided builds universally better. If the audience's question were “Why did my report omit an order?”, a specific failure and diagnosis would provide a more direct explanation.
Step 3: Write the complete sequence
Each row should change what the viewer knows about the same report:
| Beat | Picture and action | Why it belongs |
|---|---|---|
| 1. Weekly task | The analyst has a five-row order file and needs the unshipped orders. | Establishes the input and question. |
| 2. Import | The analyst imports the file; LedgerView displays its five rows. | Shows where the report data comes from. |
| 3. Filter | The analyst selects Status equals Unshipped. LV-102 and LV-104 remain. | Demonstrates the selection rule with inspectable values. |
| 4. Save | The analyst names the report Unshipped orders and saves it. | Establishes what will persist into the next run. |
| 5. Replace input | A label identifies the following week's file. The analyst imports it through the supported update action. | Makes the time change and manual action explicit. |
| 6. Rerun | The same saved report shows LV-104 and LV-106; its condition still reads Unshipped. | Demonstrates reuse and the changed result. |
| 7. Next action | The report remains visible beside a link to the setup tutorial. | Gives an interested viewer a relevant continuation. |
Keep the initial file small enough that the viewer can verify the filter. A hundred decorative rows would make the screen busier while hiding the evidence. A real production can use a representative subset if it clearly identifies that simplification.
Step 4: Preserve the decisions and compress repetition
The first import needs enough detail to establish the source and destination. The second import can move faster once the viewer recognizes the control, but it must still show that the analyst supplies another file. Skipping that action could imply a scheduled integration.
The filter deserves a close view because the audience needs to understand its condition. Menu travel and cursor movement can take less time, provided the control exists and the action remains plausible. A cursor should reach the target before clicking, and the result should follow the action that causes it.
Keep the report name and condition consistent across scenes. During the transition to the following week, retain the saved report or reintroduce it with its name visible. Otherwise the viewer may think the analyst built another report from scratch.
Step 5: Turn the outline into pictures
Draw the input table, filtered result, saved report, and second result before animating. The important comparisons are the status values against the filter and the two result sets against their respective files.
Use a closer framing when the condition changes. Use a wider framing when the viewer needs to connect the report to its input. A side-by-side comparison can help, but only if both sets of order IDs remain readable at the intended viewing size.
The storyboard guide provides the scene fields. The resulting board should name the cause and evidence of each change, including the manual import between weeks. Mark any product question that still lacks a source.
Step 6: Write narration for the visual sequence
After the visual draft works, narration can explain why each action matters. During filtering, “The report keeps only rows whose status is Unshipped” names the exact rule. During the second run, “Next week, the saved condition selects the unshipped orders from the new file” explains what persists.
Avoid claiming that LedgerView imports files automatically or saves a measured amount of time. The example demonstrates neither. A real benefit claim requires evidence beyond the sequence itself.
Record or synthesize the audio after writing to the reviewed visuals. Measure the clips to avoid truncation, then align the important phrases to events in playback. A scene long enough for the voice can still show the second result too early.
Troubleshooting the story
If the film feels like a tour, write the viewer question beside each scene. A scene about export themes does not answer whether the filter survives a new file; remove it or give it another tutorial.
If the ending feels unsupported, compare its claim with the visible result. A saved report proves that a configuration exists. A second run proves how it behaves with different input. Add the missing test when the promised understanding depends on it.
If the film feels repetitive, check whether each repeated operation introduces a meaningful distinction. The second file matters here because its changed rows test reuse. A third equivalent file probably adds little.
If the story requires a long explanation before the first action, narrow the audience or task. Viewers unfamiliar with spreadsheets may need a separate introduction to rows and filters. Adding every prerequisite to this film would change its purpose.
A practice outline with pass criteria
Choose a real task that produces a reusable artifact, such as a saved search, routing rule, or dashboard. Record its starting data and one changed input. Write a guided-build outline that includes construction and a second use, then draw the final proof frames.
The outline passes when another person can name what the product saved, what the user changed, and why the second result differs from the first. Every depicted capability should have a product source. The final artifact should include the audience question, example data, scene table, proof frames, and explicit exclusions.
If a different structure answers the question with fewer unsupported assumptions, use it and record the reason. The worked-example guide helps maintain continuity as that outline becomes a film.