Who this is for: Product teams preparing clear software update communication.
What to prepare
- An approved migration procedure with applicable source and destination states.
- Prerequisites, role requirements and documented recovery guidance.
- A verified completion check and support contact.
Draw the decision map before timing scenes
Start with the conditions that determine which path applies. Account role, current configuration and migration status may matter more than the order of screens. Use a working map with a branch for each consequential difference, then choose the single path the video will demonstrate.
For every branch, record its prerequisite, action owner, approved action and checkpoint. A missing checkpoint is a production gap: without it, the viewer may see activity without knowing whether the migration succeeded.
- Entry check: does this procedure apply to this workspace?
- Preparation check: are required inputs and permissions ready?
- Action check: has the approved operation completed?
- Verification check: does the destination satisfy the supplied acceptance criteria?
- Help path: what should the viewer do if a check fails?
Worked example: move a saved report definition
Imagine a fictional analytics tool replacing a report builder. The illustrative procedure moves a saved report definition, not historical data. The owner supplies a migration action and requires comparison of filters, grouping and column labels afterward. Those assumptions are planning material, not product instructions.
The map begins by checking whether the report still uses the old builder. If it already uses the new builder, stop. If the viewer lacks editor permission, hand the task to an editor. Otherwise, record the original definition, run the approved migration action and inspect the destination definition.
- Checkpoint A: the source report identifier and builder version are confirmed.
- Checkpoint B: the required editor role and source definition are available.
- Checkpoint C: the new definition exists for the same report.
- Checkpoint D: filters, grouping and column labels match the approved expectation.
- Failure branch: follow the owner's supplied recovery or escalation instructions; do not improvise a destructive reset.
Show one path and signpost exceptions
The main sequence can follow an eligible editor moving one illustrative report. State the prerequisites at the opening. At the permission branch, a brief label can identify who should continue. More complex exceptions belong in the linked procedure if they cannot be explained clearly in the video.
Use consistent identifiers across the old and new views. If values legitimately differ after migration, explain the supplied reason. A matched screenshot alone cannot establish equivalence of definitions or underlying data.
End at verification, not the progress indicator
A completed progress bar confirms only the status it actually represents. The storyboard should reserve time for the acceptance check the product owner specifies. In the example, that is inspecting the migrated definition rather than claiming all reports are correct.
Keep procedure references and version details with the asset. Migration guidance can become stale when either endpoint changes. Recheck the video against the current approved procedure before reusing it for another release.
Review checklist
- The video identifies the starting state it supports.
- Role and preparation requirements are explicit.
- Every branch has an owner and approved next action.
- The final scene verifies the intended destination state.
- The procedure version remains traceable from the asset.