Who this is for: Product, marketing and customer teams choosing a suitable release communication workflow.
What to prepare
- The current approved migration procedure.
- Source eligibility, role and preparation requirements.
- Destination acceptance criteria and documented recovery guidance.
Copyable creative brief
An authored planning example. Replace illustrative details with your approved product facts and assets.
Illustrative planning brief: orient editors to moving a fictional report definition from an old builder to its replacement. Identify the report and source version. Check editor permission and the required source record before showing the approved migration action. Then inspect the destination filters, grouping and column labels for the same report. Keep the scope explicit: the example moves a definition and does not establish historical-data migration. If a checkpoint fails, direct users to the supplied recovery or support instructions. End at the acceptance check rather than a progress animation. Treat this as a planning example until the actual procedure, screens and verification facts are provided.
Assess fit and readiness
Use video when a transition has a visual sequence, branching decision or destination check that benefits from explanation. The strongest inputs include a stable procedure and identifiable starting conditions. A migration whose requirements are still changing needs a controlled source packet before production.
Video alone is a poor place for long commands, extensive exception lists or frequently changing operational details. Keep the authoritative procedure accessible and use the video to orient users, demonstrate a bounded path and explain the checks.
Map the checkpoints
Record entry, preparation, action and acceptance separately. Each gate needs a pass condition, owner and failure route. Do not invent recovery behavior or omit a required step to fit the desired runtime.
- Entry: the user has the source state covered by this procedure.
- Preparation: permissions and required records are ready.
- Action: the approved transition is performed in the documented order.
- Acceptance: the destination meets the supplied criteria.
- Failure: the user follows verified recovery or escalation instructions.
Build the demonstration
Choose one clearly labeled illustrative object and preserve its identity across the transition. The destination must be inspectable, not simply replaced by a green confirmation card. If the product legitimately changes a value, explain the approved transformation.
A short asset can introduce the gates and point to the full guide. A longer walkthrough can teach the chosen path in detail. Label the scope so viewers do not mistake an orientation film for exhaustive migration instructions.
Maintain procedural truth
Have the procedure owner review the actual final asset, including any shortened waits, omitted screens and recovery wording. An animation can create a false impression of automatic success even when the script is cautious.
Keep the procedure version and source evidence with the asset. Changes at either endpoint can invalidate a migration lesson. Recheck shortened waits, omitted screens and recovery wording whenever the procedure changes, and keep the video's automation claims within the behavior the owner has verified.
Review checklist
- The starting state and authorized role are explicit.
- The demonstrated path follows the approved procedure.
- Acceptance checks match the actual migration scope.
- Every failure condition has verified guidance.
- The asset remains tied to a current procedure revision.