Show a Changing Product Interface Without Advertising a Fictional Feature

A commercial gets twelve seconds for the interface. The app behind it has four screens, a button that moved last week, and a release date that has moved twice. Somewhere in the middle of that, someone has to decide what the twelve seconds show.

The rule that survives that pressure is shorter than the problem: a shot may change how much of the product the viewer sees. It may not change what the product does.

That sounds obvious. It stops being obvious the moment an edit is tight. Cut from a search field to a confirmation screen and the passage is cleaner, faster, and no longer about the same product. The work is knowing which of your simplifications are craft and which one quietly upgraded the software.

Establish the action before you establish the frame

Start with one question for whoever owns the product: what does this do, right now, in which version? Not what it will do, and not what the demo does. You need three things, each with a name attached.

The action: what the user does, what the product does in response, and what exists afterward that didn't exist before. The conditions: the plan, region, account, permission, or connection the behavior depends on. The version: the build number or dated snapshot that answer describes. And then the fourth thing, which is easy to skip because it isn't technical — who said so, and when. Phrases like "it's basically live" travel fast through a production and arrive in a script as settled fact. Get a person's name attached to the answer before you get a storyboard.

Four different things can be sitting on the screen at once, and they blur together:

• behavior that works in a build someone can point to;
• staged data — invented names, inventory, prices, coverage — placed inside a real screen;
• recorded material, an actual capture of an actual session;
• planned interactions that exist in a design file and nowhere else.

Staged data deserves its own warning, because it is usually treated as free. It's free only when the fabrication carries no claim. In the exercise later in this piece, the app lists rooms in three neighborhoods. Adding a room from a fourth neighborhood to the results list for visual variety sounds harmless, and it depicts coverage the product doesn't have. That's a small example of the general problem: the fabricated part is rarely the part you're watching.

GOV.UK's service manual, which is written for UK public services rather than for advertisers, draws a related line — a prototype can deliver a realistic experience without being production-ready code, and the manual advises keeping prototypes from being mistaken for live services. Useful as context for how easily the confusion is manufactured. It is not a test your commercial can pass, and guidance pages like that get revised.

What a shot may change, and what changes a claim

Plenty of visual treatment is free of consequences:

• enlarging a real control until it fills the frame;
• compressing time between two events that both occur;
• simplifying a cluttered background, or cutting to a designed screen in place of a messy one;
• directing attention with focus, sound and edit.

None of that adds an ability. The product still does what it does; you've just decided which part of it the viewer watches.

What adds an ability is subtler:

• removing a step the user has to take, so the product appears to take it;
• cutting past a wait, so a slow result plays as instant;
• presenting an outcome the product reaches only later, or only under some conditions, as the thing it does.

The FTC's advertising guidance for small businesses describes how the agency assesses whether an ad is deceptive, including the whole context of the ad, claims that are implied rather than stated outright, and whether the advertiser has evidence for what the ad conveys. Read as craft advice rather than legal instruction, that's the right lens for an interface passage, because implied claims are precisely what a screen montage produces. That guidance is US federal guidance; it is not a clearance of any particular cut, and it doesn't pretend to speak for the rest of the world. Nothing in it endorses an edit. A disclaimer parked at the end of a spot is also a thin correction for what the middle of the spot showed, which is why whether a specific disclosure does the job belongs with the advertiser's own review rather than with your treatment.

A booking passage, twice

What follows is an exercise specification. Halyard is invented. No app was inspected for this example, and nothing here describes the behavior of a product that exists.

The stipulated facts, for a version the exercise labels 4.2:

• Halyard lists rooms in three neighborhoods.
• The user enters a date and a start time, and taps Search.
• A results list appears. Each result row has a Select control.
• Selecting a slot opens a summary screen. Nothing is booked yet.
• One control creates the booking: Confirm booking, on the summary screen.
• Tapping it produces a confirmation screen with a reference, and the room is booked immediately.

Three user actions — search, select, confirm — and exactly one of them has consequences.

Passage A. Over the shoulder: the results list, a hand tapping Select. Macro: the summary screen, Confirm booking filling the frame, a thumb entering, the control changing state, the reference arriving. Then the actor's face, a small exhale. A later shot: the reference appearing in the actor's calendar. Voiceover: "Pick your slot, confirm it, and the room is yours."

Framing changed, scale changed, background simplified, a macro insert added. The number of decisions did not change, and neither did who makes them.

Passage B. A hand types "Thursday 7 p.m." and results appear. Cut. The phone shows "Booked — Studio B, Thursday, 7 p.m.," and the actor smiles. Voiceover: "Halyard finds your room and books it."

No Select. No Confirm. The system is credited with the choice, and the voiceover says the implied claim out loud.

The part worth being precise about: the problem with Passage B is not that time got compressed. Commercials compress time constantly and honestly. The question is whether a required action survives somewhere in the passage — in the picture, in the spoken line, or in how the cut is built. Passage B shows the confirmation screen and the smile, and nothing anywhere has carried the Confirm tap.

You can patch that with a line. "Select a slot, confirm, done" over the same shots does carry the actions, and it's better than nothing. But a line can't out-argue a picture that contradicts it, particularly when the picture is the fast, joyful part and the line is a clause. The impression is built from the whole passage — which is the same reason the FTC framing is about the whole advertisement and not about one frame. Words are one lever. They aren't a reset button.

When the screens change and the action doesn't

Now suppose the exercise's next version, labeled 4.3, keeps the same required actions and rearranges them. The summary screen is gone. Each result row carries its own control, labeled Book. The user still chooses a slot and still makes one deliberate confirming tap; selecting and confirming have merged into a single action.

What this costs:

• The insert: reshoot. Label and layout changed.
• The actor's tap: keep. It's still a real control with a real consequence.
• The reaction: keep.
• The voiceover: tighten. "Pick your slot, confirm it" now describes two things the user does in one tap. "Tap a room, and it's yours."
• The later cut on the calendar entry: keep.

This is where modularity earns its keep, and where the word usually gets used loosely. An insert is only modular if swapping it doesn't invalidate what surrounds it. If you replace the screen and the actor's face no longer matches the moment, you didn't build a module — you built a scene with a screen in it, and the screen just became expensive. The practical shape is a screen element shot clean and separately: locked off or macro, replaceable, with the performance built so it works against more than one plausible version of the screen. Where the performance depends on what the screen says, you've tied them together, and the treatment should admit that instead of claiming flexibility it doesn't have.

One related habit: label planned screens. A polished board of a screen that doesn't exist yet reads as a release promise the moment it lands in a deck. Mark it as planned before it goes to a client, not after someone has already repeated it in a meeting.

When the action changes

Now the harder revision. The exercise's version 5.0 is planned, not current, and it turns bookings into requests. Tapping Book sends a request; the room is confirmed only when the venue accepts — up to a day, per the exercise. The screen after the tap says "Request sent," not "Booked."

This is the case a replaceable insert cannot absorb. The screen is the swappable part. The reaction is the point of the scene. An actor who relaxes because the room is booked is performing a fact version 5.0 does not deliver, and no insert fixes a performance built on the wrong outcome.

The compression problem gets worse too. Passage B's cut from search to booked now skips a selection, a confirmation, a wait of up to a day, and another person's decision. Under 4.2 that cut was a distortion. Under 5.0 it's a different product.

If 5.0 is what will actually launch, and the commercial airs after launch, the timing changes but the order of operations doesn't. You still need the owner to name the build you're filming, because the shoot happens on a date and the screen has to be something. A planned state stays labeled planned until someone can point to it working.

Put the confirmation in the shot record

Behavior that lives in someone's memory leaves the production when that person does. One line per interface shot carries it:

Shot 12 — macro, summary screen, Confirm booking tap. Behavior: this tap creates the booking; selecting does not. Build: 4.2, owner-confirmed. Insert: replaceable — screen content only, including label and layout. Bound to: VO line 4; actor's reaction, shot 13.

The value is in that last clause. When the screen changes, you know what else to look at. When the insert and the reaction are listed as independent, someone will eventually reshoot one and leave the other, and the resulting cut will show a person celebrating something that didn't happen.

Then re-check by watching the whole passage, not the shot that changed. A relabeled control is a reshoot. A new approval step is a re-edit: the words, the performance, the cut, and whatever the end card implies. Unconfirmed capability stays a question in the treatment, or comes out — it should not survive into the proposal as a promise that launch will make true.

What to ask for, and from whom

The passage you want is one whose visual treatment can change without quietly changing the product. You get there by settling two things early: the action the viewer has to understand, and the name of the person who confirmed it, in which build.

With those attached, everything else is ordinary craft. The close-up, the macro, the cleaned-up background, the swapped insert — all of them are decisions about how much of a real behavior the viewer sees, made by people who know what they're showing.

When the treatment comes back with a beautiful screen nobody can place, ask the specific question: which shot, which action, which build, whose confirmation. If those four have answers, you can shoot. If the last one is blank, you haven't written a demonstration. You've written a feature.

Frequently asked questions

What is the basic rule for filming a changing product interface?

A shot may change how much of the product the viewer sees; it may not change what the product does. Before establishing the frame, settle the action, the conditions it depends on, the version or dated snapshot, and who said so and when. Attach a person's name to the answer before getting a storyboard, because phrases like 'it's basically live' travel fast and arrive in a script as settled fact.

What kinds of material can be sitting on the screen at once, and why is staged data a warning?

Behavior that works in a build someone can point to, staged data such as invented names or coverage placed inside a real screen, recorded material from an actual session, and planned interactions that exist only in a design file. Staged data is free only when the fabrication carries no claim. Adding a room from a fourth neighborhood to a results list for visual variety, when the product lists rooms in three neighborhoods, depicts coverage the product does not have; the fabricated part is rarely the part you are watching.

How do Passage A and Passage B differ in the Halyard booking example?

Passage A changes framing, scale, background, and adds a macro insert, but the number of decisions and who makes them stay the same: search, select, confirm, with Confirm booking creating the booking. Passage B cuts from typing a date to a screen reading 'Booked' with no Select and no Confirm, and the voiceover says the system finds and books the room. The problem is not that time was compressed — it is that no required action survives in the picture, the spoken line, or how the cut is built. A line like 'Select a slot, confirm, done' is better than nothing, but it cannot out-argue a picture that contradicts it.

What changes when version 4.3 keeps the required actions but rearranges the screens?

The summary screen is gone, each result row carries its own Book control, and selecting and confirming merge into one action. The screen insert must be reshot because label and layout changed; the actor's tap and reaction can stay; the voiceover should tighten to describe one tap; and the later calendar cut can stay. An insert is only modular if swapping it does not invalidate what surrounds it. If the performance depends on what the screen says, the treatment should admit they are tied, and planned screens should be labeled as planned before they go to a client.

What must change if version 5.0 turns bookings into requests?

The screen insert must be rebuilt, the actor's tap can stay, the reaction must change because nothing is booked at that moment, the voiceover must be rewritten, the later calendar shot should be removed or moved after the acceptance beat, and what the story claims is different. A replaceable insert cannot absorb this case: the screen is swappable, but the reaction is the point of the scene. A shot record should bind the insert to the voiceover and the actor's reaction, and the treatment should keep asking: which shot, which action, which build, whose confirmation.

Further reading

• Record an Interface Walkthrough for a Commercial Treatment — When it is time to record the screen for the treatment, this covers preparing a clean state, capturing one bounded path, checking the exported file, and labeling what changed.
• End the Commercial at a Real Next Step, Not a Fictional Button — When the closing frame promises a transaction, this works through naming the real next action, following it to its first result, and matching the wording to the route.