Build the video around one job and one visible result. Keep the human opening short enough that the viewer reaches the software while the question is still fresh.
Play the opening. Plan the next shot.
These are source reactions paired with suggested edits. The captions describe the product footage you add; they do not describe the source creator’s personal experience.
Which version are we approving?
Then show: Open the version and its feedback in your own demo workspace. Make the approval decision with the actual control your product provides.
End on: Hold on the approved status and the file ready to hand off.
These duplicate rows can be found together?
Then show: Show a sample CSV with duplicates, run your real duplicate-detection feature and review the matched rows before applying a change.
End on: Show the cleaned table and exported file. Keep any review steps needed for an accurate demonstration.
That’s the report ready to send.
Then show: Choose the date range and fields in your reporting tool, generate the report and show the output opening.
End on: Keep the exported report readable, then point to the feature or signup page where the viewer can try the same task.
Choose a job with a visible finish
For a team tool, “collaboration” is too broad to film. Approving a design, handing off a task or exporting a report gives you a beginning and an end. Write the final screen state first. If the outcome needs a paragraph of explanation, choose a smaller part of the workflow.
An approval video might start with three versions of the same asset and finish with one marked approved. A reporting video might start with a selected date range and finish with the exported file open. These are proposed examples; record the actions your own software actually supports.
Three feature briefs you can adapt
“Powerful workspace automation” is hard to film. “Move overdue tasks into one view” gives you a starting screen, an action and an ending. Translate each feature into that sequence before choosing a reaction.
These are suggested examples, not claims about a particular product. Use a brief only if your software supports the behavior, including any setup the edit would otherwise hide.
| Feature type | Opening idea | Visible evidence | Important boundary |
|---|---|---|---|
| Task filtering | “Only the things that need attention” | Show the filter and matching tasks | Do not imply the app chose priorities without rules |
| Document search | “Find the note, not the folder” | Enter a query and open the right result | Use an actual successful search |
| Report export | “Take this view into the meeting” | Export the displayed report and open it | Do not hide a required plan or configuration |
Capture the story before choosing a face
Create a small demo workspace with enough information to make the task believable. Use named sample files, a few comments and a clear owner. A screen full of placeholder text makes it hard to understand why the workflow matters. Remove private names, customer information and notifications before recording.
Capture the starting state, the decisive interaction and the result as separate takes. Leave a little stillness around each action so the editor can cut without rushing. Keep the cursor near the control it uses. Avoid a tour through navigation unless finding the feature is the subject of the video.
| Capture | Keep visible | Editing note |
|---|---|---|
| Starting state | The unresolved task and relevant version | Crop out unrelated navigation |
| Key action | The control and the change it causes | Keep the click and response in the same shot |
| Finished state | Approved status, exported file or completed handoff | Hold long enough to read the outcome |
Make three openings from the same recording
Keep the body of the demo fixed and change the way you introduce the problem. A question can lead with uncertainty. A direct line can lead with the action. A result-first version can open on the finished state before showing how it happened. Each version should make sense without knowing your product name.
A happy reaction such as the sample here can punctuate the finished task. If you want it at the start, use it to introduce a satisfying reveal. Watch the complete clip and cut around the expression; do not assume its first frame is the best in-point.
- Question: “Which version are we approving?” → show the version and its comments.
- Action: “Keep the feedback with the file.” → open the relevant discussion.
- Result: “This one is ready to send.” → reveal the approved state, then show the deciding action.
Let the screen stay readable
A desktop app needs a deliberate crop in a vertical edit. Keep the object, the control and the result together. If that needs two shots, cut between them instead of shrinking the entire window. Add a short caption for the action; do not transcribe every menu label.
Use the reaction as the introduction or a brief cutaway. A face beside a miniature dashboard can hide the most useful part of the video. Preview the export on your phone, with the sound off, and check that a new viewer can say what changed.
Review the handoff and the promise
End at the next useful step: the relevant feature page, a signup flow or an invitation to try the workflow. Keep the instruction consistent with what the viewer just saw. A video about approving a file should not land on an unrelated feature.
The person in a library clip has not necessarily used your software. Write captions about the demonstrated action, not a made-up customer experience. If you want a personal recommendation, that requires a separate, genuine account. For your first comparison, keep the demo and destination unchanged and record which opening you used.
Attach any performance claim to evidence you actually have. “Here is the saved view” is a visible fact. “This saved me ten hours” is a separate personal outcome, and a stock expression cannot supply it.
Questions & answers
Is this different from an app demo?
The capture often is. Desktop software may involve several panels, sample team data and a result such as a handoff or export. The app guide focuses on a short, single-screen action; this brief follows a workplace task.
Can I use a reaction over an AI software demo?
Yes, as an opening to footage you supply. Show a real input and output, and retain any steps needed to understand the result. The reaction does not verify the output or stand in for a customer review.
Do you record the software for me?
ugcpeople supplies existing human-shot clips. You record your software and assemble the final edit, or work with an editor.
Can a desktop SaaS product work in vertical video?
Yes, if the relevant panel and result remain readable. A focused crop or two clear shots is better than shrinking an entire desktop window.
Should I list all the benefits?
Start with the benefit demonstrated by the action shown. A list of unrelated claims makes the short video harder to follow.
Find the opening for your next edit.
See the public samples, then unlock the library when you’re ready to work with the originals.
Explore the library