A product demo can show every button and leave the viewer unsure why they'd use any of them.
For a short-form demo, choose a task small enough to finish on screen. Establish the starting situation, perform the action and let the viewer see the result. The restraint is in choosing the task; the detail belongs in making the change understandable.
We'll use an illustrative feedback workspace to plan and record a demo about assigning a review comment. You can apply the same method to a physical product by replacing the screen action with a visible movement or setup step.
Define what will be different at the end
In our fictional workspace, a comment can have an owner. At the start, a review note has nobody assigned. At the end, a named teammate appears beside it.
That is the entire transformation this demo needs to show. We aren't claiming that the teammate completes the work, that the deadline improves or that the software chooses the correct person.
Write the start and end in the brief:
| Starting state | User action | Visible result |
|---|---|---|
| A review comment has no assigned owner. | The coordinator selects a teammate. | The teammate's name appears on the comment. |
If the final column describes a feeling such as “the team is more organized,” find the observable behavior beneath it. Where would the viewer look to see the change? If you can't answer, the demo may need a narrower task or a different format.
The content-brief template gives you a place to record that decision with the claim and source material.
Prepare the scene before you start recording
Create a demo project with invented names and content. The comment should be understandable without a long explanation, such as “Increase the contrast on the navigation label.” Use a short project name and only the surrounding data needed to make the task credible.
Then check the rest of the recording area. Close unrelated tabs, hide private bookmarks and disable interruptions that might reveal messages. Open the menus you expect to use once before recording; a personal email address may appear in an account menu even when the main screen is clean.
Set the demo to the intended starting state. If the comment already has an owner, remove that assignment in the demo environment before the take. Don't make the editor simulate the missing starting state with a graphic.
For a physical product, preparation means having the actual model, the required parts and the source instructions available. Check that the sample can perform the action you're planning to show. If setup needs a tool or another person's help, the brief should say so.
Choose a frame that preserves cause and effect
A whole desktop can make a vertical video look like a postage stamp. Cropping solves some of that problem, but a crop can also remove the context that makes an action understandable.
For the assignment demo, the frame needs the comment text, the owner control and the place where the selected name will appear. It does not need the browser's entire tab bar or an empty sidebar.
Try the crop before the full recording. Capture a short sample, view it at phone size and ask whether the comment and resulting name remain legible. If not, adjust the application view or record a closer section. Don't assume you can recover tiny text by enlarging it later.
A useful sequence may need two views: one to establish the project and another for the interaction. Make that change of view clear. A cut that jumps to a different-looking screen just as the action happens can leave the viewer unsure what caused the result.
For a physical demonstration, keep the contact point visible. A hand reaching across the lens may hide the clip releasing or the hinge opening. Move the camera rather than narrating over the thing you failed to capture.
Record the complete action before making it fast
Capture a clean take from the starting state through the finished result. Give the screen a moment to settle before and after the interaction. Those pauses give the editor room to show the state without freezing a blurred transition frame.
If you click the wrong control, reset and record another take. Keep the earlier take separately if it contains a useful view, but don't ask the editor to assemble an impossible sequence from mismatched states.
Here's a shot plan for our example:
| Part | What to capture | Why it stays in the edit |
|---|---|---|
| Situation | The unassigned comment in its project | Establishes the piece of work and the missing owner |
| Selection | Open the owner control and choose a demo teammate | Shows how the user makes the assignment |
| Result | The same comment with the teammate's name visible | Connects the action to its outcome |
| Closing view | Hold on the completed assignment | Gives the viewer time to understand what changed |
You can trim idle cursor travel. Preserve the selection and the resulting state. If the real action includes a delay, don't turn an edited delay into a claim of instant performance. Show or describe the step honestly when its duration matters to the use case.
Write narration around what the picture cannot explain
A first draft might read: “Our powerful assignment feature helps teams collaborate more effectively and manage all their feedback in one place.” The screen has to carry nearly all the useful meaning while the voice describes a broad benefit.
Try: “This comment needs an owner. Choose the teammate handling it. Their name stays beside the note.”
That narration names the starting problem, explains the action and points to the result. It doesn't narrate every cursor movement. If the name is clearly visible, you may not need to read it aloud.
For a text-led version, use fewer words per frame and leave each line visible long enough to read. Check the wording against the actual action. “Assign automatically” would be false in this example, even if an editing template suggests it.
Read the draft over the recording before polishing the audio. If a sentence introduces a concept the video never shows, either capture what is missing or remove the sentence. Adding another feature to the narration is an easy way to turn a focused demo back into a tour.
Edit for understanding, then for pace
Build a first cut with the action intact. Watch it without music or decorative transitions. Can you tell what was wrong, what the user did and what changed?
Now remove repetition. If the voice explains the task while an opening card explains it again, try starting on the task itself. If the product name appears in the interface and a small label, you may not need a separate logo introduction.
A faster cut is not automatically clearer. The important result may need a quiet moment, particularly when the viewer has to read a status or compare two states. Spend the time there and remove it from an unnecessary transition.
Add captions and review them separately. Product terminology and teammate names may need correction. Check that the caption doesn't cover the owner control or the final assignment. Watch at the size and orientation in which someone will encounter the post.
The hooks guide can help you revise the opening after you know what the footage supports.
Run a comprehension check before approval
Show the cut to someone who hasn't read the brief. Ask them what task the product completed and what they would do to repeat it. Avoid leading questions such as “Was it clear that the assignment is manual?” Their unprompted answer is more useful.
For our example, an answer like “It decides who should handle each comment” reveals a problem. The intended result is “I choose a teammate and their name appears beside the note.” Review the wording and any cut that hides the selection.
Also check the final export for private information, misleading added graphics and a closing instruction the viewer can follow. Approval should refer to that export and its caption. If someone changes the demonstration after approval, review the revised version.
Download the demo recording plan and comprehension check (.txt) ↓Keep the usable pieces for the next recording
Save the clean take, the edited project, the final export and the brief together. Record which screen or product version you used so you can find posts that need review after a change.
If several demos share a setup, the batch-production guide helps you record them efficiently. Keep each task distinct when you edit. The next demo might show how to resolve the comment, but it doesn't need to appear halfway through this one.
Hexwave's format library reflects the kinds of product stories we're building toward. A clear demonstration remains useful regardless of which editor you use to make it.
Open the finished cut one last time and pause on the result. If that frame answers the question the first frame raised, the demo has done its job.
