Tell a Commercial Through Interface Actions, Not a Tour of Screens
Tell a Commercial Through Interface Actions, Not a Tour of Screens
A screen-based treatment usually arrives as a numbered list of places. Lock screen. Home screen. Thread. Map. Camera roll. Checkout. Confirmation. Every panel is drawn, every screen is one you'd recognize, and nothing has happened.
The first thing to check isn't the drawing. It's whether anything is different after somebody acts. Open an invitation and close it again and nothing has changed: that's a visit, not a scene. Decline it and you've changed Saturday, and changed who's expecting you. Only one of those earns a commercial.
So the working question for every beat in a screenlife treatment is a question about difference. Either the person's situation moved — a commitment made, an option spent, something recovered — or the viewer learned what they need in order to understand the next move. A screen that does neither is a tour stop, and a tour is the most expensive way to say that a product has screens.
What follows is how to get from that question to a written sequence. The example, worked end to end below, is invented.
Give the person a goal outside the interface
Start with what they're trying to arrange, protect, decide or recover. That goal lives off-screen. The interface is where it becomes expensive.
A calendar entry matters because of something the calendar can't show you: the person who'll be alone if you go to the other thing. A profile screen matters if someone is deciding whether to trust the person in it. Strip away the off-screen pressure and the same screen becomes inventory — a demonstration that the product has a profile, a calendar, a confirmation page.
This gives you a diagnostic you can run in a couple of minutes. For each screen in the draft, write two sentences: before this screen and after this screen. If the two sentences say the same thing about the person's situation, either cut the screen or fold it into a neighbour. If "after" is only "they have seen it," you've written a tour.
Order follows from the goal rather than the product's navigation. Product surfaces are organized by where they sit in an app. A scene is organized by what's pressing on the person. The same screens rearranged by pressure read completely differently, and usually two of them disappear.
Write actions between states
Write the sequence as a chain of verbs. Selecting. Editing. Submitting. Waiting. Backing out. Changing your mind. If you can't name the verb for a beat, there probably isn't one, and you're describing a view instead of an action.
Keep the person's actions and the interface's answers in separate columns, because they carry different risks. A cursor crossing a button is something a person does. A row of dots, a spinner, a checkmark sliding into place: those are the interface answering. They're useful, and they also make a claim. If your treatment shows the app gathering, sorting, summarizing, suggesting or confirming, you've written a product capability into a story beat, and an animation can't quietly supply one that doesn't exist.
Include the intermediate state where the uncertainty is the point. A half-typed message that hasn't been sent is a different fact from a message that has. A form that's filled but not submitted is where a decision is still reversible, and sometimes that's the whole scene.
Waiting deserves its own rule. Show a wait only if the wait is the story. If it isn't, cut it whole rather than trimming its length in the edit. A shaved load time is still a claim about speed, an inflated one is a claim in the other direction, and neither claim was the commercial's job. The same goes for interruption: a call, a notification, a person walking into the room. It earns its place only if its arrival changes what the person does next. Otherwise it's a rhythm device, and you can get rhythm from the cut.
Navigation, finally, has two legitimate jobs: telling the viewer where they are, and standing in the way of something. Cut whatever does neither. What you can't cut is the viewer's ability to say which invitation, thread or account they're looking at right now. In screenlife, confusion isn't usually a mood. It's usually a missing establishing beat.
Two kinds of beat, judged by different rules
A sequence contains changes and costs, and it's worth naming them, because they fail for opposite reasons.
A change moves the situation: a response submitted, an option spent, a commitment made.
A cost changes nothing at all. It's the thumb that settles on the button and doesn't press. A cost is allowed only if it makes the next change expensive — test it by cutting the beat and seeing whether the following change still costs the person anything. If it doesn't, you've been decorating. If it does, the cost beat is load-bearing, and it can hold a couple of seconds without owing anyone an explanation.
Make the consequential information readable
Divide what's on the screen into two piles. The first pile has to be read exactly: a name, a time, a status, a count. The second only has to be recognized: the app itself, the chrome, the avatar, the button shapes, the colour scheme. Design and direction spend their attention on the first pile. The second pile just has to be plausible enough not to distract.
Often the exact figure isn't what matters. In the scene below, no viewer needs to know that the party starts at seven. They need to know that both things start at the same time, which is a comparison rather than a value, and comparisons can be staged: hold longer, or re-frame so the two times sit in the same shot instead of forty pixels apart. That's a framing decision, and it doesn't assert anything about the product.
Holding is a director's tool, and it's cheap in the sense that matters here. How long a camera rests on a list implicates no capability. Put the duration where the decision is, rather than spreading it evenly. And you don't have to show every control the screen contains. Enlarging a label or letting background detail recede is presentation. Removing something the app genuinely displays is closer to a claim, and it's worth raising with the product owner rather than settling it quietly in a frame.
There's a temptation to reach for a reading-speed figure and divide the duration by it. Those figures come from situations where reading is the entire task, one line at a time, with nothing else competing. A viewer inside a commercial is reading a status in an unfamiliar layout while following motion and sound, which is not the same task and doesn't convert. The check is the check: play it at the size it will be seen, at the intended timing, with the music in, and then ask someone what they got. A composition that reads on a large monitor at arm's length is not evidence about a phone held in one hand, in a room, with a soundtrack. Those are different viewing conditions, and only one of them is the one you're buying.
Separate story invention from product representation
An invented interface is a legitimate teaching device, and occasionally a necessary one — it lets you work a sequence end to end without borrowing someone's product. Say so in the treatment. Unlabelled fiction inside a spot for a real product stops being a device and becomes a promise.
If the product is real, get confirmation of the actual interaction before you write it into something you'll have to defend. Ask specifically about what's visible to whom, what happens on submit, what appears afterwards, what's optional and what's the default. Those answers change scenes more often than they change copy.
The line to hold is between presentation and capability.
Presentation: enlarging a label, quieting background detail, choosing a longer hold, framing out a control you don't need, deciding what the camera does while a decision lands.
Capability: adding a warning, a suggestion, a summary, a sync, a badge, a status, a view of other people's choices, or access to something an account doesn't have. Speed is a capability. Visibility is a capability. Automation is a capability.
The practical version: the treatment can say hold on the guest list until the count lands. It can't say the app flags the clash. The first sentence is a camera instruction. The second is a feature, and if the product doesn't have it, you've written a spot for something else.
The sequence, written before it's drawn
Here is the scene as a passage, in prose, before any panel is drawn. It's unbranded and invented. The behaviours it assumes — that a guest list can be seen, that responses can be changed, that a status is displayed — are stipulated for the example, not observed anywhere.
An invitation list on a phone. Two entries near the top. Priya's housewarming, Saturday, 7:00 p.m. Rosa's dinner, Saturday, 7:00 p.m.
The list holds. Nothing is pressed. Ines opens Priya's.
Priya's invitation fills the screen. Below the time, the guest list runs long enough to keep going past the bottom edge of the frame. Under it, the response control: Going. Can't go. Ines moves to Going. She doesn't press it. She backs out to the list.
She opens Rosa's. Same Saturday, same 7:00 p.m. The guest list is one name, Rosa's, marked as going. Ines stays on this screen after she has finished reading it. Nothing on it moves.
Back to Priya's. She presses Can't go. Her response changes, and the entry now reads as answered.
Then Rosa's again. She presses Going. Rosa's name is no longer the only one on the list. The passage ends there, on a guest list with two names where there was one: no confetti, no checkmark ceremony, no music cue telling the viewer how to feel about the evening.
What each beat is doing. The held list changes nothing; it's orientation, and it has to establish the collision, which makes it the first thing to check at viewing size. Opening Priya's gives the viewer the crowd. The hover is a cost beat with no state change at all, and without it the decline is housekeeping rather than a choice. Rosa's single-name list is information the next change gets measured against, and it's held, because that's where the decision is. The decline is change one: an option spent. The acceptance is change two, and the second visit to Rosa's is not a repeat of the first — the first time she looked at it, Priya's was still unanswered. Same screen, different weight. The last image is the change itself.
What it doesn't say. The passage arranges a long list and a list of one. It doesn't say what Ines concluded. Any line of copy explaining her motive turns one invented evening into a claim about how people behave, which is not something an invented scene can support.
Strip it back
Now remove everything that isn't a change or a load-bearing cost. What survives:
- An invitation list. Two entries. Same time, readable as the same time.
- Open A. Guest list long. Response control present. No action.
- Open B. Guest list: one name.
- Open A. Decline.
- Open B. Accept.
- B's guest list gains a name.
Six beats. The list records visits and states, never back taps: each move between A and B is a cut. Those returns can stay cuts in the edit rather than being animated — you don't have to show every back tap, as long as the viewer never loses track of which invitation they're in. What you can't cut is the alternation, because the alternation is the story: A, B, A, B, each visit sitting on a different state than the last. Drop the return to A and she accepts the dinner with the party still unanswered, which leaves an acceptance where the sequence wanted a decision.
That's a playable scene description, and it came out of prose rather than a storyboard.
None of it has been built. No interface, no prototype, no timed viewing test, and no production account or authorized spot stands behind the example above; there's nothing here that was inspected first-hand, so treat it as editorial construction rather than a case. The behaviours it assumes are the fiction. If you were carrying this structure into a spot for an app that actually exists, these are the things you'd want the owner to confirm before you defended the treatment:
- That two invitations with the same time can appear together in one list, with both times visible at once.
- That an unanswered invitation looks different from an answered one.
- That a response can be changed after it's given.
- That other people's responses are visible to this person at all, and at what level of detail.
- That accepting puts you on the guest list.
- That the list updates without a manual refresh.
- Whether declining notifies the host, and whether the product says so.
- Whether the product does anything about conflicting times — in which case you've just found a better scene than the one you wrote.
Write the passage first, in prose, with no panels. If it reads as a story on paper, you have something to shoot. If it reads as a list of places, you have a product tour with a voiceover, and you can find that out before anyone draws a screen.
Frequently asked questions
What is the working question for each beat in a screenlife treatment?
Ask whether the person's situation moved—a commitment made, an option spent, something recovered—or whether the viewer learned what they need to understand the next move. If a screen does neither, it is a tour stop. Opening and closing an invitation changes nothing; declining it changes Saturday and who is expecting you.
What is the before-and-after diagnostic for cutting screens?
For each screen, write two sentences: before this screen and after this screen. If the two sentences say the same thing about the person's situation, cut the screen or fold it into a neighbor. If 'after' is only 'they have seen it,' you have written a tour.
How should waits and interruptions be treated?
Show a wait only if the wait is the story; otherwise cut it whole rather than trimming its length in the edit. An interruption—a call, notification, or person entering—earns its place only if its arrival changes what the person does next. Otherwise it is a rhythm device, and rhythm can come from the cut.
What is the difference between presentation and capability?
Presentation includes enlarging a label, quieting background detail, choosing a longer hold, framing out a control, or deciding what the camera does while a decision lands. Capability includes adding a warning, suggestion, summary, sync, badge, status, other people's choices, account access, speed, visibility, or automation. The treatment can say 'hold on the guest list until the count lands'; it cannot say 'the app flags the clash' unless the product does.
What does the Ines sequence demonstrate, and what does it not establish?
It shows a collision—Priya's housewarming and Rosa's dinner both Saturday at 7:00—and stages a decline and an acceptance through interface actions. The held list is orientation, the hover is a cost with no state change, Rosa's single-name list is held for the decision, and the final guest list has two names where there was one. It is invented and unbranded; the behaviours it assumes are stipulated, not observed, and if carried into a real product they need confirmation on list behaviour, response changes, visibility, updates, notifications, and conflict handling.