Who this is for: Product teams preparing focused launch motion briefs.
What to prepare
- An approved diagram of product parts
- Exact labels and relationships
- A supplied product screen
- One user task connecting the diagram to behavior
Copyable creative brief
An authored planning example. Replace illustrative details with your approved product facts and assets.
Plan a 30-second launch for PRODUCT_NAME using BLUEPRINT_PARTS and APPROVED_RELATIONSHIPS. Present the diagram as an explanatory illustration, not a literal system architecture unless that is what the source establishes. Use only the supplied components and directions. Begin with USER_TASK. Reveal the whole outline, then focus on one part at a time in READING_ORDER. Keep labels attached to their components with unambiguous connectors. Avoid adding technical-looking details that suggest capabilities or infrastructure not in the brief. After explaining the relationship, transition to the supplied product screen and show how the user encounters the relevant part. Hold PROOF_DETAIL. Keep the final composition readable without the moving reveal. End with CURRENT_STATUS and NEXT_ACTION. If a relationship is uncertain, flag it rather than drawing a confident arrow.
Make it your own
- BLUEPRINT_PARTS
- Limit the diagram to parts needed for the chosen task.
- APPROVED_RELATIONSHIPS
- Specify containment, sequence or connection precisely.
- READING_ORDER
- Choose the order that answers the viewer's question.
- PRODUCT_NAME and USER_TASK
- Name the product and the specific viewer question the diagram should answer.
- PROOF_DETAIL
- Choose the supplied interface element that grounds the explanatory diagram in actual behavior.
- CURRENT_STATUS and NEXT_ACTION
- Supply verified availability and the destination appropriate to this explanation.
Choose the diagram's question
For an illustrative planning product, the diagram might explain how a task, owner and status relate. It need not become a detailed architecture map.
Keep the drawing's role explicit: it explains a concept, while the supplied screen shows the actual interface.
Adapt the labeling
For small displays, reduce the number of parts and use sequential close views with a persistent overview. For technical viewers, retain the precise labels but still define unfamiliar relationships.
A longer version can explain one exception, not merely add more boxes.
Repair diagram ambiguity
If connectors cross or ownership is unclear, reposition labels before adding motion. If an arrow implies data transfer that is not verified, replace it with the correct relationship marker or explanatory text.
The final diagram should remain useful when paused.
Review checklist
- Every part and relationship comes from approved material.
- Illustration is distinguished from literal architecture.
- Labels retain unambiguous ownership.
- The sequence returns to product evidence.