Most playable rebuilds are not caused by bad execution. They are caused by a brief that named a game and a colour palette and left every consequential decision to whoever opened the editor. The builder guesses the win state, guesses how long the interaction should run, guesses where the CTA belongs — and then the guesses come back in review as changes, one round at a time. A brief that pins down nine things costs an hour to write and removes most of that.
1. The mechanic, described as an action
Not the genre. "Match-3" is a category; "swap two adjacent tiles to line up three of the same colour" is an instruction someone can build from. The distinction matters because most genres contain several mechanics, and the one you pick determines whether the interaction is legible in three seconds. A merge game can be drag-two-together or tap-to-combine, and those feel completely different in a ten-second ad.
Write the mechanic as the sentence you would say to a player who has never seen your game. If that sentence needs a subordinate clause, the mechanic is probably too complex for a playable and you should pick the simpler half of it.
2. The win state, and what happens on failure
Every playable needs a defined end. Specify what counts as success — three matches, one completed level, the crowd reaching the gate — and specify what happens if the player does nothing at all, because a meaningful share of impressions will do exactly that. The usual answer is a prompt after a few seconds and a move to the end card after a few more, but it has to be a decision rather than an accident.
Failure states are the part briefs skip most often. If the player can lose, say whether losing ends the ad, restarts the interaction, or quietly makes the next attempt easier. An ad that lets a player fail twice and then leaves them stuck has spent your impression on frustration.
3. Session length before the CTA
Give a number in seconds and a number in interactions. "Around ten seconds, or three successful taps, whichever comes first" is buildable. "Short" is not. This single line settles a surprising number of downstream arguments, because it determines how much tutorial you can afford, how many rounds the mechanic runs, and whether an intro animation is possible at all.
4. The CTA moment
Name the moment the CTA appears and whether it is persistent before that. There are three common patterns and they perform differently: a CTA visible from the first frame, a CTA that appears after the first successful interaction, and a CTA that appears only on the end card. The first maximises immediate clicks, the third maximises qualified clicks, and the second is the compromise most teams land on. Pick one deliberately rather than discovering it in review.
The line most briefs are missing
"The end card is reached from the game's completion event via a Go to Scene action." Without it, the builder may produce a playable that runs beautifully and never advances to the CTA screen — which passes a casual preview and fails the campaign.
5. Target networks, named
The network list is not an afterthought, because it sets the constraints everything else has to live inside. Meta holds the HTML under 2 MB while most others allow 5 MB. Google takes a ZIP and needs ExitApi; Unity takes a single HTML and needs an mraid.js tag; Moloco explicitly forbids that tag and refuses a ZIP entirely. A brief that says "all networks" is really saying "build to the strictest of them", and it is better to say that outright.
If Meta is in the list, the 2 MB figure should appear in the brief as the working budget, because it will change art decisions — how many unique sprites, whether the background is a photograph or drawn in code, how many animation frames you can afford.
6. Orientation
State whether the creative must work in both orientations or only one, and if only one, which placements you are giving up. Networks serve into both portrait and landscape slots, so a portrait-only build either forfeits inventory or renders badly in it. Deciding this up front is much cheaper than discovering mid-review that the layout was built against a single assumed screen shape.
7. Assets, with the gaps named
List what exists and what does not. Source art at what resolution, in what format, with or without transparency; the app icon; the store URLs for both platforms; the fonts and whether you have licence to embed them. The last one catches teams out regularly — a font that is fine on a website may not be licensed for embedding in an ad creative, and it has to be subset and inlined for a playable to work offline.
Where an asset does not exist, say who is making it and by when. "We will need a 3-frame celebration animation" in the brief is a task; discovered during the build, it is a delay.
8. Localisation, if any
If the creative is going to more than one market, decide now whether you are shipping one file per market or one file carrying every language. One file per market is almost always right under a 2–5 MB cap, because a single multi-language build pays the size cost of every language on every impression for the benefit of one. Either way, the strings that need translating — usually just the headline and the CTA — should be listed in the brief so they are written once rather than extracted later.
9. The success metric
Name the number this creative is trying to move, and name the post-install event you will judge it on. "Lower CPI" is not enough on its own: a creative can win on CPI and lose on retention by attracting people who tap readily and never return. Deciding the success metric before the build also stops the post-hoc argument where a creative is defended on whichever metric happened to improve.
What a good brief is not
It is not a design document. Nothing above specifies where the button sits, what colour the panel is, or which easing curve the tiles use — those are the builder's job and they are better at it than the brief writer is. The brief's job is to remove ambiguity about intent, constraints and success, and then get out of the way. A brief that specifies pixel positions produces a creative that looks exactly like the brief and performs exactly as well as the person who wrote it imagined, which is rarely better than what a good builder would have done.
The test for whether a brief is finished is simple: hand it to someone who was not in the meeting and ask them what the ad does. If they can describe the interaction, the ending and the CTA moment without asking a question, it is ready.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker