Who this is for: Product teams preparing a timed storyboard for an original launch asset.
What to prepare
- One verified capability
- Matching initial and resulting states
- Exact short copy
- Current product identity and access status
Scene-by-scene storyboard
15-second planning sequence · illustrative copy and visual direction
- 01
0–3s
Name the task
Show the supplied example item and a short task line.
On screen:Give this request a next owner.
- 02
3–8s
Show the capability
Use approved assignment states with one clear focal point.
On screen:Choose the owner.
- 03
8–12s
Hold the result
Show the same request with its actual assigned state and readable owner.
On screen:The next owner is visible.
- 04
12–15s
Close with context
Display approved identity and accurate availability.
On screen:Coming soon. Join the waitlist.
Make it your own
- Capability
- Choose one useful supported task.
- Result
- Use the actual completed or pending state.
- Closing action
- Match current availability.
Choose a complete small task
The request-assignment example is illustrative. Its proof is a visible owner on the same request, not a claim about overall coordination quality.
A single capability can be substantial if its input, action and result are understandable. Avoid adding unrelated screens merely to make the film appear broader.
Adapt the duration
If the task requires a prerequisite or unfamiliar category explanation, use 30 seconds and add that context before the action. A 60-second version can explain a meaningful limitation or a second bounded example.
Do not force a complex workflow into 15 seconds by removing consequential steps. Choose a smaller demonstration or a longer format.
Prepare the proof
Supply matched screens and exact role information. If the action is only a request for assignment rather than a completed assignment, use the actual pending state.
Keep the final identity scene simple enough to read. The closing action must match current access, even when the product demonstration is polished.
Review the storyboard without audio. The viewer should be able to identify what changed and why the final state supports the task statement.
Review checklist
- The task fits the selected runtime without hidden steps.
- Only one capability leads the story.
- The result is readable and accurate.
- The closing action is supported.