If you've recorded your app and the result feels like a slow product tour, we'd choose one useful task and build the ad around that. Show the real action, let someone see what changed, and give them a sensible next step. You can add narration, captions, or an AI presenter once that sequence makes sense on its own.
The tricky part is making a desktop interface readable in a short ad. Cropping can hide the button that explains the result. Cutting a loading pause can make a multi-step process look automatic. And a polished generated dashboard can quietly promise a feature your app doesn't have.
So let's work through an expense-app example, from the recording plan to the exported ad. The app and script are fictional; this is an editing exercise you can adapt, not a demo we filmed or a campaign we measured. We'll keep the real recording as the evidence and use the rest of the video to help someone follow it.
Choose the task before you record the tour
Imagine our fictional expense app lets a team member upload a receipt, choose a category, and send it for review. The reviewer then sees it in a pending queue. For this example, those are the approved features. We haven't established automatic categorization, automatic reimbursement, or a processing-time claim.
We'd make the ad answer: “How do I send a receipt to the person reviewing expenses?” That's small enough to show clearly. A tour of dashboards, budgets, integrations, and reporting would give the viewer more features to remember before they'd understood the first task.
Write the answer in ordinary language before opening the recorder: “Upload the receipt, choose its category, and send it for review.” Then check that a new user can actually do those things with the account and plan you're advertising. If a feature needs a particular role or paid tier, keep that qualification with the explanation and destination.
If you're still deciding whether the ad should be a demo, tutorial, or customer story, our UGC format guide can help with that earlier choice. Here, we're assuming the viewer needs to see the software work.
Set up a demo account you can safely show
We'd use an account prepared for recording, with fictional names, a sample receipt, and no real customer records. Make the sample realistic enough to understand, but don't use a real person's expense report just because it's already populated. Close unrelated tabs and notifications, and check the address bar, account menu, and filenames before recording.
For the expense example, we'd label the workspace “Demo workspace” and use a receipt created for the demonstration. A short “Demo data” label in the video can make that context clear. We wouldn't make the dashboard look like proof of customer adoption or savings.
Start from a state you can explain. If the uploader is already signed in and the reviewer is already assigned, that's fine for a feature demonstration. Don't then describe the clip as the complete setup process. If assigning a reviewer is part of the task you're promising to teach, you need to show or explain it.
You don't need a new paid recorder to begin. On a Mac, Apple's screen-recording instructions, checked October 30, 2026, explain how to open Screenshot with Shift-Command-5 and record a selected portion of the screen. Whichever recorder you use, make a short sample and inspect the saved file before capturing the whole workflow. Confirm that the text is readable and the menus you need are inside the recording.
Record the action and the result together
For our expense app, we'd keep an uncut source recording of the whole task. That gives the editor something to check against when making a shorter version. Capture the starting state, the actual interaction, and enough of the result to read it.
Here's the source plan we'd prepare. These are proposed filenames and capture instructions for the fictional example, not existing recordings.
| Source to capture | What the viewer needs to understand | What we'd preserve in the edit |
|---|---|---|
receipt-upload | The team member chooses a file and the receipt appears | The real upload action and the resulting receipt |
category-selection | The team member chooses the category manually | The category menu, selection, and selected value |
send-for-review | The submission goes into review rather than straight to payment | The actual send action and pending status |
reviewer-queue | A different role receives the submitted receipt | A clear handoff to the reviewer view and the matching item |
Leave a little stillness around the important result. If you immediately move to the next menu, the viewer may spend the whole clip following the pointer without reading what happened. You can trim that hold later once you know how the narration fits.
And keep the roles straight. A cut from the submitter's screen to the reviewer's queue should say something like “Now in the reviewer's view.” Otherwise it can look as though the person uploading the receipt can approve their own expense, even if your app doesn't allow that.
We'd also capture a fresh result when the input changes. Splicing one receipt upload onto a queue showing a different receipt gives the editor an avoidable continuity problem. Match the amount, filename, category, and status across the shots before recording another take.
Make the vertical edit readable without changing the workflow
A desktop recording squeezed into a vertical canvas can leave every label too small. We'd begin with the part of the interface the viewer needs at that moment, then check whether the action and its result still fit together.
For the category step, that means seeing the menu open, the chosen category, and the resulting field value. If those don't fit in one close view, use a wider shot for the action and a closer view for the result. A brief hold is easier to understand than a camera move chasing every cursor movement.
| Editing problem | What we'd try | What would make us revise it |
|---|---|---|
| The whole window is too small | Crop around the relevant panel; establish the wider view first if needed | The viewer can no longer tell where the action happens |
| The menu opens outside the crop | Widen or reposition the shot for that step | The selection is hidden while narration says the user chooses it |
| A caption covers the status | Move the caption or give the interface more space | “Pending review” becomes unreadable |
| A pause slows the sequence | Trim idle time and make a meaningful time jump clear | The edit implies a speed or automation claim we haven't established |
| A role change feels like one continuous action | Label the reviewer view and use a clear cut | It appears the submitter has permissions they don't have |
If the only way to make a step readable is to give it more time, we'd give it more time. There isn't a universal ad length that makes an illegible demo useful. You can shorten the introduction or show fewer features before rushing the proof.
Don't redraw a missing button or generate a replacement screen to rescue the crop. Go back to the source recording, widen the view, or record that step again. A mockup can illustrate a future idea, but we'd label it as a concept and keep it separate from a demonstration of today's product.
Write the narration against the footage you actually have
Now we can build a short explanation. We'd avoid “Watch it handle expenses automatically,” because our example needs a person to choose the category and another person to review the receipt. Here's a script that stays with the approved actions:
Here's how a receipt gets to your reviewer.
Upload the receipt and choose its category.
Send it for review. The status changes to pending.
Now in the reviewer's view, that receipt is waiting in the queue.
See the receipt workflow on our product page.Place each sentence beside its matching shot. “Choose its category” belongs over the visible manual selection; “pending” belongs where that status can be read. If the words arrive before the picture, adjust the timing instead of expecting the viewer to remember the line until the result appears.
Describing the important change also helps people who can't see the screen clearly. The W3C guide to visual descriptions, checked October 30, 2026, explains how essential visual information can be woven into the main narration. In our example, “The status changes to pending” says more than “And there you go.” This is a useful writing practice, not a claim that the finished ad meets every accessibility requirement.
Then check captions against the actual audio. The W3C caption guidance, also checked October 30, describes captions as speech and relevant non-speech audio information and explains why automatic captions need review. Extra labels such as “Reviewer view” have a different job: they orient the viewer in the interface. Keep them readable alongside the captions.
For a difficult product name or rushed read, our AI voiceover guide works through a spoken-copy and caption correction. Here, we'd keep the focus on whether the narration explains the action we can actually see.
Give the editor the recording and a specific brief
We build Cospark, so the product recommendation here comes from its own team. You can use this brief with another editor too. Cospark's product page, checked October 30, 2026, describes working from your footage, adding narration and captions, and revising through chat or the timeline. Script to Video is a starting point when you already have the script.
For this project, we'd supply the real screen clips rather than ask for generated interface scenes. We haven't tested a paid generation for this guide, and we're not promising automatic screen capture, privacy redaction, or a crop that follows every menu correctly. Those are things to inspect in the workflow and output you choose.
Here's the brief we'd adapt after recording:
Make a software demo ad from the attached real screen recordings.
Audience: team members who need to send a receipt for review.
Question: how does the receipt reach the reviewer?
Use the supplied script and screen footage. Keep the actual interface,
manual category selection, send action, and pending status accurate.
Label the switch to the reviewer account. Show the same receipt throughout.
The account uses fictional demo data; keep that context visible.
Create a readable vertical edit. Keep the menu, selected category, and
pending status visible when the narration explains them. Leave room for captions.
You may trim idle pauses; flag time jumps that could change the apparent workflow.
Do not imply automatic categorization, payment, or a measured completion time.
Do not generate replacement product screens or invent customer results.
Show the scene plan and proposed cuts before adding optional generated media.
End with the product-page destination for this receipt workflow.That last request is a project instruction, not a guarantee of an enforced approval step. Review the proposed edit and then the output. If the tool can't preserve the screen footage as needed, keep the demo in an editor where you can control those cuts.
Say the draft crops out the category selection and the narrator now says “It sorts your receipt.” We'd give a focused correction:
Restore the real category-selection step from category-selection.
Widen that shot so the menu and selected value are readable.
Replace "It sorts your receipt" with "Choose its category."
Keep the receipt upload, pending status, reviewer-view label, and ending.
Do not regenerate any interface footage. Show the revised sequence with
its surrounding shots, narration, and captions so we can review it together.Compare the correction with the previous version. Even a specific request can disturb a caption or timing elsewhere, so we'd check the whole short ad again before approving it.
Watch the exported file as someone who's never used the app
First, watch without stopping. Can you follow what the user does and why the result matters? Then pause on the menu, status, and role change. Finally, watch at phone size with sound off and listen once without relying on the picture. Those passes reveal different gaps; none replaces the others.
Open the exported file, because that's the one you're handing over. Check it in the intended placement preview as well: platform controls and the final crop can cover a status that looked fine in the editor. If the narration promises a free trial, an integration, or a plan-specific feature, verify that wording against the current destination before launch.
We'd keep a small handoff note so the next edit starts from the right source:
Feature and product version shown:
Recording date and source filenames:
Demo data and permissions checked:
Required steps: upload, manual category choice, send, pending, reviewer queue
Role change label:
Any cut waiting time or omitted prerequisites to explain:
Approved script and caption version:
Landing page and plan qualification:
Exact exported file reviewed:
Reviewer and review date:If the product changes, use that note to find the affected screen rather than quietly leaving an old interface in the ad. And if the first version is clear, you can try a different opening while keeping the accepted demonstration intact. Our AI ad creative guide explains how we'd separate that variation from a new message.
For your first cut, we'd make the smallest complete explanation you can support: one real task, a readable result, and a next step that matches what someone just saw. Once that's working, you'll have something concrete to improve instead of a polished tour that never quite shows the product.