Playable Ad Brief Template, With a Completed Example

What a useful brief decides

The brief is the agreement between the creative question and the production work. It identifies what the viewer should understand and do, what material can be used, what constitutes the master, which changes count as variants, where the files must run, who approves them, and what can be observed at acceptance.

The one-page template

• Game and store URL; studio; product owner; review owner.
• Audience, campaign context, current creative, and the decision this test should support.
• Opening promise, desired player action, feedback, outcome, CTA, and anything the concept must not imply.
• Supplied art, audio, fonts, source formats, usage rights, missing assets, and brand rules.
• Master definition, variant list, language, orientation, target networks/products, and delivery format.
• Review points, acceptance checks, known limitations, source delivery, and changes that require re-estimation.

Good answers are observable

Fictional completed example

Fictional studio Northstar Pocket supplies a capture and approved layered art for a fictional game, Parcel Sort. The question is whether one direct sorting action explains the game's fantasy better than the current video. The master opens on three parcels and three destinations, teaches one drag, provides correct and incorrect feedback, completes after three decisions, and then presents the agreed store CTA.

The fictional variant set changes opening copy, first-board difficulty, and reward treatment. One language and portrait orientation are in scope. Two exact network products would be named before export. Acceptance covers loading, the interaction path, outcome, CTA behavior, responsive layout in scoped viewports, package inspection, and recorded limitations. No campaign result is claimed.

Asset checklist

• Layered editable source rather than flattened screenshots where animation or state changes are required.
• Font files and licenses, approved copy, app-store destination, and platform badges where used.
• Audio files and rules for sound-on behavior; alternate silent feedback where needed.
• Reference captures for the real game state and a list of intentional deviations.
• A rights owner for every client logo, character, gameplay asset, and licensed element.

Acceptance criteria

Criteria should name the exact build behavior: loads without an unhandled error in the agreed harness; waits for the required lifecycle signal; supports the scoped orientation; registers the intended input; displays correct and incorrect feedback; reaches win or fail states; opens only the agreed destination through the required mechanism; and produces no unapproved network requests. Add network-specific constraints only after checking the current source.

The brief remains a living record

Update the brief when an assumption becomes a decision. Preserve rejected directions and scope changes in the project record, but make the accepted master and active variant list obvious. A useful brief prevents hidden interpretation; it does not eliminate review.

Download the blank Markdown brief and the fictional JSON example. Both are ungated.