Show an operation with actual evidence of its input, action and result. A magical door opening can illustrate possibility, but it does not demonstrate a software export or a physical product function. Use fantasy to attract attention, then switch to a clearly labelled demonstration or diagram for the factual claim.
Choose what the viewer should learn
An explainer can introduce a problem, teach a step or prove an outcome. Decide which job each segment performs. A beautiful transformation may work as an introduction while failing as instruction because the viewer cannot identify the control used or the file returned. Do not describe generated interface imagery as a current screen recording.
For a real operation, list its entry point, required input, relevant setting and inspectable output. Verify those against the current product. If a setting or output is unavailable, revise the claim before recording. Avoid using an animation to conceal the absence of a functioning step.
A fictional image-workflow tutorial
An invented creator wants to explain making a postcard from a travel photograph. The opening can show a suitcase unfolding into paper scenery, labelled as illustrative AI footage. The teaching section should instead show the actual photograph, the chosen transformation and a returned image. Exact printed text and mailing preparation are separate tasks.
The resulting story is problem, operation and inspected artwork. A postcard flying into a postbox would not prove that the platform prints or mails anything. If used as a decorative ending, it needs a boundary that the service supplies digital artwork, not physical fulfilment.
Build an evidence chain
- Show the real starting material without private details.
- Identify the actual tool or workspace being demonstrated.
- Show the setting that affects this task, not every available parameter.
- Show the result from that task rather than an unrelated favourite example.
- State what still needs review or completion outside the platform.
Keep task records privately where appropriate. Do not display balances, email addresses or unrelated user assets in a public demonstration. If the result is an earlier owned example, label it as such and avoid pretending it was generated during the recording.
Give illustrative scenes a different role
Imagild's film workflow can help plan or generate narrative scenes. It does not make generated screens reliable evidence of the website's current interface. Capture real interface material through an authorized recording method and assemble it with the illustration in a suitable editor. Use the actual film controls available rather than promising arbitrary compositing features.
Review the finished explainer with the sound off and then with narration. The visual evidence and spoken claim should describe the same operation. If the narration promises a working QR code while the screen merely shows decorative squares, neither a polished shot nor a disclaimer elsewhere fixes that mismatch.
Can I use a metaphor as the whole advertisement?
Yes for a clearly fictional brand story, but it should not be presented as a tutorial or proof of a specific capability. Say what the service actually delivers.
Must I show the entire wait for generation?
No. An honestly labelled time cut can remove waiting. Do not turn that edit into a claim about measured generation speed.
Sources and related reading
For a different vendor’s creative demonstration, see Runway’s product-shot-to-social-ad tutorial. That tutorial is not evidence of Imagild functionality or of factual fidelity in every generated product image.