A polished successful take is not enough for a smart hardware demo. A shot that product, marketing and post-production teams can all approve needs to connect five things: the device’s starting state, the user’s action, the device’s visible or audible acknowledgement, the confirmed result, and the conditions required to reset the product for another take.
This is what we mean by a “state chain.” It is not a laboratory report, nor does it turn a commercial into an instruction manual. It is a shot-planning and continuity method that protects product truth while still giving the edit enough freedom to move quickly.
A normal storyboard describes action; a state chain records cause and change
A storyboard might say, “The user taps the app and the door unlocks.” That describes the picture, but it does not prepare the set. Was the lock definitely locked at the start? Which account was signed in? After the tap, when did the app, indicator, sound and bolt change? Before the next take, who returns the door, lock and app to the same starting condition?
A state-chain shot records six fields:
| Field | Question to record |
|---|---|
| Starting state | What are the product, app, account, network and physical environment doing before the action? |
| User input | What exactly does the hand, voice, button or other input do? |
| Acknowledgement | Does the product indicate receipt through light, sound, haptics, interface or physical movement? |
| Result state | Where can the viewer confirm completion rather than merely see “processing”? |
| Failure and recovery | If it does not complete, how is that shown and how does the user return to a retryable state? |
| Reset condition | Before the next take, must the team relock, unbind, clear an account, change a fixture or restore a connection? |
This does not replace the earlier method for synchronising hardware, hands and interface timing. Our guide to filming connection and setup steps focuses on keeping several timelines aligned. A state chain goes further by recording how the same function behaves across success, recovery and changed conditions.
A hypothetical smart lock: three paths are more useful than one successful take
The following is a method example, not an ONCE client project, and it does not claim that any real lock has these features. The final script must follow the approved production sample, firmware, product documentation and market version.
Path one: successful unlock, with proof that the state changed
Before filming, the bolt is in the approved locked position, the app uses an authorised test account, and the phone’s network and Bluetooth state are recorded. After the user taps unlock, the camera holds long enough to capture the app’s pending state, the real lock sound, light or motor movement, and then an approved result such as the physical bolt position or a confirmed status screen.
No feedback should be invented from generic smart-home conventions. If the product has no indicator light, do not add one. If the app reports “unlocked” before the mechanism completes, record the real timing difference instead of forcing both events onto the same frame.
Path two: obstruction or incomplete action, with an honest recovery
Google Home’s public LockUnlock trait distinguishes locked, unlocked and jammed states. That does not mean every lock must use the same interface, but it illustrates an important production principle: issuing a command is not the same as confirming the result.
If the product team genuinely needs an obstruction-recovery demonstration, an engineering owner should approve a reversible, safe test condition and confirm which messages belong to the release version. The shot should show that the product did not reach the unlocked state, how the device and app report the condition, and how the user retries after the condition is removed. Do not fabricate an error in post, and do not ask talent to block a mechanism unsafely for drama.
Path three: changed conditions without implying universal compatibility
Weak connectivity, a different door installation, environmental noise, glare or low battery may change either the real behaviour or the viewer’s ability to read the feedback. Only conditions defined by the product team and safely reproducible on set belong in the script.
The purpose of a weak-network scene, for example, is not to make the product look unstable. It is to confirm whether this specific product displays a wait state, an error, an approved offline function or something else. A successful take on one test door does not prove compatibility with every door. A clear alert recorded in a quiet studio does not imply that the same alert will be equally audible in a noisy corridor.
A commissioning shot needs a communication job, not another generic tutorial
Google Home’s public Matter commissioning overview describes discovery, secure session establishment, device information, network provisioning, operational discovery and commissioning completion, with a fail-safe that can roll the device back if commissioning does not finish. A film does not need to explain the protocol, but it should not treat scanning, discovery and a success screen as one event.
If the film only needs to establish that the product can be added to a home system, it may retain three critical moments: discovering the device, confirming the user’s choice and demonstrating final control. If the asset must support customer service or channel training, create a separate continuous version that retains permissions, network choice, waiting, failure and retry.
The key procurement decision is simple: the short commercial can compress information, but the production day should first preserve an uninterrupted process master. Without that master, editors cannot tell whether a wait was compressed honestly, and teams cannot easily decide which shots remain reusable after an app or firmware update.
When may the edit move faster, and when is continuity essential?
The edit can accelerate repeated waiting, approved interface transitions and gaps that do not imply product performance. Even after compression, the viewer should still understand who triggered the action, how the product acknowledged it and where the outcome appeared.
Keep a continuous master when:
- the shot is demonstrating response order, success conditions or a recovery path;
- the product team must confirm that app, sound, indicator and mechanism came from the same operation;
- the commercial could reasonably imply connection speed, unlock speed or recovery capability;
- the footage will later support tutorials, sales demonstrations or localised interface versions.
For advertising in the United States, the FTC’s advertising substantiation policy considers both express and implied claims and expects advertisers to have a reasonable basis for objective assertions before dissemination. Visual timing matters: deleting the wait, moving a success sound earlier or replacing the status screen can imply “instant response” even when the script never says it. The brand should therefore approve performance language, real timing and editorial compression for the intended market.
UI replacement, sound design and AI may improve clarity, not rewrite behaviour
Filming a phone screen can introduce flicker, reflections and finger occlusion. A clean screen recording or interface replacement may be clearer, provided its buttons, states, messages, order and timing come from the approved build. The asset register should distinguish direct capture, official screen recording, post-produced recreation and explanatory animation.
Sound needs the same provenance. Record the real mechanism and product alert separately before deciding how they sit in the mix. An enhanced sound added for mobile playback should not be presented as the product’s actual loudness. Generative tools can help previsualise an environment, extend a background that carries no product claim or build a clearly identified explanatory transition. They should not invent an interface, feedback signal or installation condition.
The current C2PA Content Credentials specification can help retain information about how an asset was created and edited. Provenance is useful, but it does not prove that a product function or performance claim is accurate; the brand still has to approve the underlying behaviour.
If the hero film also has to communicate industrial design, performance and lifestyle value, use ONCE’s broader video production solutions to assign each shot a clear communication job, then write each functional shot as a state chain. A beautiful close-up no longer has to prove finish, function, speed and compatibility at once.
A state-chain shot card you can use on the next production
Before the shoot, the product owner, director and script supervisor can complete one card for every critical function:
| Item | What to specify |
|---|---|
| Function and audience task | Is this for commercial understanding, product-page evidence, training or internal approval? |
| Product version | Sample ID, firmware, app build, language, account and accessory state |
| Starting state | Physical position, connection, battery and relevant environment |
| Input action | Who triggers what, where and by which method? |
| Approved feedback | Interface, light, sound, haptics and mechanism, in their expected order |
| Completion criterion | Which observable result confirms actual completion? |
| Failure branch | Which incomplete state should be filmed, and how can it be triggered and recovered safely? |
| Continuous master | Camera, sync cue, screen-recording filename and production-sound filename |
| Reset steps | Who restores which state before the next take? |
| Approval owner | Who signs off product fact, brand expression and final edit? |
During review, do not only ask whether the shot feels smooth. Watch once without sound to see whether action and result remain understandable. Listen again to check whether feedback has been moved out of sequence. Finally, compare the edit with the card to verify version, state and recovery. If the result only makes sense because of narration, or if the failure shot has no defined starting point for a retry, the chain is incomplete.
Not every shot needs this treatment. A pure design hero, an emotional lifestyle beat or a brand transition that carries no product fact should not be slowed down by engineering documentation. But whenever a picture is meant to prove connection, control, recognition, notification or recovery, a state chain reduces the expensive gap between a smooth edit and an inaccurate product story.
If you are preparing a launch for a smart lock, connected appliance, wearable or another networked device, share the product model, target markets, approved functions, sample and app versions, planned channels and launch date through ONCE’s product video production service. We can turn the highest-value functions into filmable, resettable and reviewable state chains before planning the hero film, product-page demonstrations and shorter versions together.
