Video Strategy
Part of Screen recordings and software tutorials
Choosing the task a software walkthrough should cover
Choose one software walkthrough task by defining the viewer, starting point, screen changes and recognisable result.
Choose a software walkthrough task that ends in a result the viewer can recognise. Start from a user question, name the starting conditions and decide what the recording must show. “How do I invite a colleague to this workspace?” describes one possible outcome. “Tour the admin area” does not.
Find the task behind the request
Look at support enquiries, onboarding questions and searches in your help content. Check the existing written answer before choosing a recording: a missing prerequisite or outdated label may be the real problem.
Write the candidate task in this form: For this user, starting here, how do they reach this result? Name the account role, relevant permission and product state. If the proposed walkthrough starts halfway through another process, decide whether its prerequisite needs a brief explanation or a separate guide.
Identify the screen change worth showing
List the moments a viewer needs to see: the control they may struggle to locate, a choice that changes the path, or the state that confirms completion. If the answer consists mainly of exact settings to copy, make those available in text. The recording should have a specific visual job.
Question / Record in the brief
- What must the viewer finish?
- One observable outcome
- Where do they begin?
- Page, role, permission and prepared data
- What must appear on screen?
- The uncertain action or change of state
- How is success recognised?
- The confirmation or next available action
- What belongs in text?
- Exact labels, values, conditions and recovery steps
For a hypothetical appointment system, changing the opening hours for one location may be one task. Setting up the entire business is likely to contain several paths. Split the work according to the actual product and audience, rather than a fixed video length.
Set the boundary
Sketch the shortest truthful path from start to result. Include a choice when it affects the outcome; leave unrelated detours for another answer. If roles follow materially different paths, identify the role shown or prepare separate instructions. Do not splice the paths together as though everyone sees the same controls.
Record the version or interface context if it affects the route. Give the written steps an owner and a review trigger when the interface changes. The brief is ready when another person can identify the outcome, the screen changes that must be shown and the work left for another guide.
