Who this is for: Founders and motion producers briefing an interface-led launch sequence.
What to prepare
- A short, recognizable problem statement
- Approved before, action and result screens for the same example object
- The product name and approved identity assets
- Verified availability and closing-action wording
Copyable creative brief
An authored planning example. Replace illustrative details with your approved product facts and assets.
Create a 30-second launch concept for PRODUCT_NAME. The viewer is AUDIENCE and recognizes PROBLEM_STATEMENT. Use the supplied before, action and result screens; do not invent controls, notifications, metrics or integrations. Treat all sample data as illustrative. Begin with the problem as one short on-screen sentence. Keep the background quiet enough to read it. Introduce the supplied starting screen and identify the one object involved in the task. Reveal the product name as that same object enters the main composition, so the name is connected to a useful job. Show PRODUCT_ACTION using the supplied states. Preserve the object's title and the relevant context during the transition. Direct attention to one active control at a time. Then hold the supplied result screen, with RESULT_LABEL readable and unchanged. The result must support the opening promise; do not add a success statistic or imply a broader outcome. Use restrained transitions between context, action and proof. Keep essential meaning visible without voiceover. End with the approved product name, CURRENT_AVAILABILITY and NEXT_ACTION. If the destination is a waitlist, say so clearly. Reserve enough of the final scene to read the actual closing copy. Flag missing or contradictory source states before production rather than filling the gap with invented behavior.
Make it your own
- PRODUCT_NAME
- Use the approved spelling and logo asset.
- AUDIENCE
- Name a viewer who recognizes the problem without lengthy setup.
- PROBLEM_STATEMENT
- Describe a concrete situation without an absolute or measured outcome claim.
- PRODUCT_ACTION
- Specify the verified action represented by the supplied states.
- RESULT_LABEL
- Use the actual status or visible result, not a decorative success claim.
- CURRENT_AVAILABILITY and NEXT_ACTION
- Match the current product destination; preserve a waitlist status when applicable.
An illustrative input set
For a fictional request tool, the problem could be “The request is here. The next owner is unclear.” Supply one request before assignment, the owner-selection state and the same request with an owner. Set the action to assigning that owner and the result label to the supplied assigned status.
This is a creative planning example, not a rendered output or a claim about Animro integrating with the fictional tool. The prompt describes material the producer must receive.
Adapt the opening without changing the proof
For an audience unfamiliar with the category, add one plain context line before showing the starting screen. Remove a decorative reveal if the extra reading time makes the sequence crowded.
For an audience that already understands the task, open directly on the unresolved state and make the problem line shorter. Keep the same proof hold. A more knowledgeable audience does not make an unsupported claim acceptable.
Correct common failures
If the reveal feels disconnected, keep the example object visible while the name appears. If the action becomes unclear, replace a large transition with a stable frame and a single highlight. If the closing message is crowded, remove a secondary benefit rather than shrinking the access condition.
If the resulting state is missing from the supplied assets, stop at a clearly labeled planning board. Do not create a plausible-looking confirmation and treat it as product evidence.
Review checklist
- The problem and final result describe the same task.
- The same example object remains recognizable.
- The prompt does not invent unsupported product behavior.
- Current availability and the next action agree.
- The final proof can be inspected in a paused frame.