Who this is for: Product teams maintaining a library of software demonstrations.
What to prepare
- Scene-to-asset map
- Product version or capture date
- Behavior and terminology dependencies
- Verification and distribution owners
Record more than screenshot filenames
Track the scene, source asset, product area, captured version or date, claimed behavior and verification owner. An image filename alone cannot tell you whether a redesign changed only appearance or changed the task itself.
Keep scene boundaries around coherent actions so a local update can be replaced without rebuilding unrelated sections. This is a planning preference, not a promise that every future change will be cheap.
Illustrative dependency register
The fictional video demonstrates assigning sample request R-102. Its maintenance record contains three scene dependencies.
- Scene A, queue entry: queue-start.png; request-list area; captured for the approved sample version; depends on row identity and filter scope; owner: product-design reviewer.
- Scene B, assignment: owner-menu.png and assigned.png; detail-panel area; depends on role permission, selection and save behavior; owner: workflow product owner.
- Scene C, confirmation: queue-result.png; request-list area; depends on the saved owner being visible after returning; owner: QA reviewer.
- Copy dependency: “Choose a reviewer, then save” must change if the real workflow changes to another commitment pattern.
- Distribution dependency: record which page or placement uses this video so an outdated copy can be found.
Work through a change before swapping images
Suppose the Owner field moves into a side panel but its behavior stays the same. Replace the relevant screens, recheck the cursor path and adjust the crop. Then verify that callouts still point to the correct control.
Suppose the Save action is removed and a selection now commits differently. This affects behavior, narration and confirmation, not just pixels. Re-observe the task and rebuild the state sequence. Do not preserve an obsolete click because it fits the old timing.
Use triggers that indicate a real dependency change
Review after changes to the featured control, role rules, object state or public availability. A routine visual refresh may require asset replacement; a permissions change can invalidate the story even if the screen looks identical.
Keep a last-verified date and unresolved issues beside the register. If current behavior cannot be confirmed, label the video appropriately or remove the affected claim from publication. A current-looking date should reflect an actual review, not an automatic refresh.
Review checklist
- Every scene maps to a source and behavior owner.
- Copy dependencies are tracked alongside images.
- Changed interactions receive workflow verification.
- Published placements can be located for replacement.