Choose one task for a product demo

Write the question before collecting screens. 'How do I find requests waiting for my review?' describes a task. 'Show our dashboard, filters and notifications' describes an inventory. The first gives you a reason to include or exclude each action.

Specify the viewer's starting knowledge. Someone evaluating the product needs an explanation of what a request represents. An existing user may need only the route to the review queue. Mixing those audiences usually adds introductions for one group and omits prerequisites for the other.

Consider this illustrative planning example for a fictional request tracker. The intended viewer is an operations lead evaluating how to find unfinished reviews. The supplied product evidence includes a populated request list, its filters and a request detail screen.

• Candidate A: configure the whole workspace. Viewer goal: begin using the system. Prerequisites: administrator access, team structure and routing decisions. Visible completion: saved settings, but no demonstration of the review task. Set aside for onboarding.
• Candidate B: find a request awaiting review. Viewer goal: identify today's next item. Prerequisites: a configured account and sample requests. Visible completion: the filtered queue and an opened matching request. Select this task.
• Candidate C: describe every reporting widget. Viewer goal: unclear until a reporting question is chosen. Prerequisites: a defined dataset and reporting period. Visible completion: no single result. Reserve for a separate dashboard explanation.

The selected illustrative task becomes: 'In an already configured account, filter requests to Awaiting review, select Sample request R-014, and verify its review status in the detail panel.' The opening says 'Find the next request to review.' A small prerequisite label establishes that requests already exist.

Keep the account, date range and sample request identity constant. End when the detail panel visibly confirms the chosen request's status. Actually approving the request is a different consequential action; including it would change the demo's promise from finding work to deciding it.

Remove workspace creation, profile preferences and reports because they do not answer the chosen question. Retain the filter selection because it explains why the list changes. Retain the detail-panel hold because it lets the viewer verify the result rather than trust narration.

If the task cannot be understood without a long setup, choose a smaller starting condition or a longer training format. Do not hide setup and then describe the workflow as requiring no configuration. A shorter film is useful only when the task remains believable.