A 90-second product explainer: fictional production plan

One viewer and one task

The intended viewer is a volunteer coordinator preparing a small performance. The film's job is to explain the fictional tool's request-to-handover sequence, ending with an invitation to inspect a fuller demonstration. It should not attempt to sell a complete management system or imply capabilities beyond the invented brief.

The narrative follows Noor, who needs a blue lantern for rehearsal. The opening shows two ambiguous paper notes on a cupboard door. The resolution is a single request with an assigned collector and a visible ready-for-handover state. Those states are assumptions of this imaginary product, not verified behaviour of any software.

A task-led 90-second sequence

Keep the illustration of the volunteer's situation visually distinct from the interface demonstration. For a real product, exact interface actions would need approved captures or another verified production method. Generated interface imagery alone would not establish that the product behaves as shown.

• 00–12: Noor reads two conflicting cupboard notes; neither identifies who is collecting the lantern.
• 12–25: The explainer names the task: one request that everyone can understand.
• 25–43: Noor creates a Blue lantern request with the rehearsal date.
• 43–60: A collector is assigned and checks the item description.
• 60–76: The request moves to Ready for handover; Noor sees the updated state.
• 76–90: The film recaps request, owner and status, then presents one next step.

A claim ledger before polished narration

This sample ledger separates the invented product premise from claims that a real client would need to substantiate. It also identifies an unsupported marketing line that should not enter a final script without evidence. Even a natural-sounding claim needs review.

The proposed narration for the middle section is: “Name the item. Give the request an owner. Keep the handover state visible.” It explains the task without inventing a quantified benefit.

Claim: “Each request shows its owner and current status.”
Example status: Fictional product assumption.
Real-project evidence required: Approved product version and demonstrated workflow.
Proposed line: “Save hours every week.”
Review status: Unsupported; omit unless suitable evidence and scope are supplied.
Visual claim: Blue lantern status changes after a handover action.
Real-project check: Product owner verifies the actual trigger and interface state.

Two reviewers answer different questions

At Story, the product owner verifies the task and claims while an unfamiliar viewer checks whether the problem makes sense. At Board and Look, review the interface implications and the distinction between illustration and demonstration. At Voices, check the product name, terminology and pace.

At Animation and Cut, compare the final sequence with the approved claim ledger. Confirm that labels, transitions and the final call to action describe the same workflow. Do not let a late visual flourish introduce an unreviewed feature.

What a real explainer evaluation would measure

A real project would need to verify interface accuracy, production usage, revision effort and the final delivery specification. Ask test viewers to explain the product's purpose and the three-step task without replaying the film. Record misunderstandings rather than assuming a finished animation communicates successfully.

If the business later measures demo interest or another next-step response, report the observed method and scope. This fictional plan supplies no conversion baseline, customer outcome or claim that animation improves sales.

Questions & answers