Choose one product action and define the audience
A demo should resolve a specific task: finding a setting, reviewing a transaction summary or understanding a supported feature. A broad “introduce the ecosystem” brief usually produces vague claims and fast cuts that hide the actual operation.
Record the product version, supported environment and prerequisites. Explain what the viewer needs to know beforehand and where the demonstration stops. Do not imply that the product, asset or promotion is available to every viewer.
Prepare a recording environment with explicit boundaries
The brand should prepare the environment rather than asking a creator to expose their personal wallet. Use a test flow where possible, and make the distinction clear. Simulated values must remain labelled as simulated rather than presented as customer results.
A demo can explain navigation without moving real funds. If a transaction is necessary, the brand’s authorised product owner should define and operate the demonstration safely; this guide does not authorise the creator to transact.
| Item | Brand input | Recording boundary |
|---|---|---|
| Feature | Verified steps and limitations | Show only the supported flow |
| Environment | Test, sandbox or production | Label what the viewer sees |
| Account | Approved demonstration account | No personal balances or identifiers |
| Security | Redaction list | No secrets, recovery phrases or tokens |
| Audience | Market and eligibility review | No universal availability claim |
| Claims | Evidence and permitted wording | No return or safety guarantee |
Write a shot plan that keeps cause and effect visible
For each step, specify the action, screen state and explanation. Keep enough time for a viewer to understand what changed. Cutting from an input to a completed outcome can hide a confirmation step, warning or delay that matters to the user.
Include the unsuccessful path where it resolves a likely question: an unsupported network, a pending state or a validation error. Use documented product behaviour and avoid manufacturing an error message. The creator’s job is to make the explanation clear, not to invent the interface.
Put the approved shot plan inside the crypto creator campaign brief. The Web3 video production guide explains which recording method should carry each part of the message.
Inspect the cut for security and meaning
The FCA’s social-media financial promotion guidance applies to communications within its perimeter. It calls for clear, fair and non-misleading promotion; appropriate approval may be required. Route the actual product and audience to a qualified reviewer rather than assuming an educational format creates an exemption.
Disclose the brand relationship for relevant audiences and keep personal experience honest. A creator who used only a sandbox should not say they have relied on the product for months.
| Surface | Inspect |
|---|---|
| Screen capture | Account names, addresses and notifications |
| Audio | Accidental reading of credentials or private data |
| Overlays | No unsupported safety or return statement |
| Transitions | Warnings and confirmations remain visible |
| Caption | Environment and sponsorship context |
| Destination | Current permitted product page |
Use a worked example without turning it into a testimonial
For a hypothetical account-settings demo, the shot list might show opening the settings menu, identifying the relevant option, confirming the effect and explaining how to reverse the change. The voiceover should describe that supported action rather than promise financial benefit.
If a test screen displays a balance, label the environment in the same viewing context. Do not use a dramatic simulated balance as social proof. If the interface has changed since recording, request a product review before publishing the old cut.
Hand over a reusable asset with a recheck date
Deliver the final file, clean screen capture where permitted, caption sidecar, claim references and product version. Identify which edits the rights schedule permits. A later editor should not remove the test-environment label to make a shorter hook.
Set a recheck trigger for feature, interface, availability or policy changes. A clear demonstration can remain useful, but only while it describes the actual product. Keep product education separate from promises about price, returns or universal security.
Sources and further reading
Prepared with AI assistance using the linked references. Planning tables and worked scenarios are illustrative, not client results. Check current product, platform and market requirements before using them.
