A product explainer should preserve the controls and behavior that a customer will encounter. A viewer who learns how to send an invoice should be able to find the depicted action in the product and understand what its result means.
Animation can simplify a busy screen or explain behavior that a recording cannot expose. The producer still needs to distinguish a faithful reconstruction from a conceptual illustration. An unlabeled invented dashboard can leave viewers expecting an interface the product does not provide.
Decide what the picture needs to establish
A screen recording shows the product performing a task. An accurate reconstruction gives the animator more control over framing and timing while retaining the relevant interface. A labeled diagram can explain a relationship that the interface does not display directly.
For a fictional invoicing tool called Petal, a recording might show a user sending invoice INV-204. A reconstruction might enlarge the sent status while preserving the invoice ID. A diagram might explain how a payment notification updates that invoice. Each depiction serves a different purpose.
The demo and explainer comparison helps choose the format. The decision should follow the viewer's question and the evidence available for the task.
Build a reference package for the scene
Before detailed animation, create the example in a safe demo environment and record the full path. Use sanitized or fictional data that follows the product's rules. Retain the relevant screens and output with the product version or capture date.
For Petal, the package should establish where Send appears, which role can use it, what confirmation follows, and how the product later learns about payment. If an operator manually records payment, the film must preserve that action. A sent invoice does not become paid merely because the scene needs a satisfying ending.
Record any prerequisite that the capture does not make obvious. A configured payment integration or verified email address may explain why the demonstration succeeds. The product owner should resolve unknowns before the animator fills them with plausible behavior.
Connect visible claims to their sources
A small evidence table keeps product decisions reviewable:
| Depiction | Supporting source | Limit to preserve |
|---|---|---|
| Send appears on the invoice detail screen. | Current screenshot from the authorized demo role. | The screenshot alone does not prove the click's outcome. |
| Sending changes Draft to Sent. | A recording of the action and resulting status. | Sent does not prove the recipient opened the invoice. |
| A payment changes the invoice to Paid. | A verified payment-event demonstration. | The film must retain any required integration or manual step. |
| INV-204 appears in the final list. | The sample-data record and scene output. | The amount and customer identity must remain consistent. |
These are example evidence requirements for an invented product. In a real production, attach the actual references. The product-truth worksheet provides a reusable table.
Prefer shared sample data when several scenes use the same record. Deriving the invoice ID and amount from one source prevents an animator from changing them accidentally in a later shot. Keep labels and interface references versioned so a redesign has identifiable dependencies.
Treat clicks and transitions as claims
A cursor clicking Send tells the viewer that the control exists and performs that action. Verify the target, the permissions, and the state that follows. The cursor should reach the control before the click, and the result should follow its cause.
Camera movement can also mislead. A transition from Sent directly to Paid may imply an automatic relationship even without a cursor. Add the actual intervening event or an explicit time transition when the explanation needs it.
A camera can crop navigation or bring the status closer. Keep enough context to associate that status with INV-204. Detaching a label from its record may make the typography readable while hiding which invoice changed.
Review the reconstruction before adding motion
Compare the major still frames with the current product. Check field names, hierarchy, selected states, and the relationship between panels. View the frames at the intended player size so the relevant evidence remains legible.
Then review motion to verify the sequence. Accurate opening and closing images do not prove that the depicted interaction between them is correct. Watch the full cut after narration and audio join the visual sequence.
The storyboard guide records the starting state and result of each scene. The production guide carries those decisions through stills, motion, narration, and audio.
Handle incomplete or changing products explicitly
An unfinished interface can still support a useful explanation when the film identifies what exists and what remains a concept. Label a proposed workflow as a concept and avoid presenting its controls as available features.
A product redesign may require a new capture or reconstruction. Review the dependent narration and captions too; a renamed status can change more than the visible label. Keep the prior accepted cut as a historical version rather than treating it as proof of current accuracy.
An accuracy exercise
Choose one scene that includes a user action. Produce a reference package and a table covering the control, its prerequisite, and its result. Compare the scene against the source recording while keeping the sample record visible across both.
The scene passes when the product owner can reproduce its path, the viewer can identify the changed record, and the narration makes no stronger claim than the evidence supports. If the scene uses a conceptual diagram, the viewer should recognize that distinction without an extra explanation from the producer.
Why explainer videos look cheap covers readability and continuity defects that can remain even after the product facts are correct. You can also watch examples or request a preview.