A media plan rarely asks for one banner. It asks for a skyscraper, a half page, an MPU, a leaderboard, a mobile banner and often a few custom sizes on top, sometimes in several languages. Building all of them at once from a design file looks efficient. In practice it multiplies every open question by the number of sizes.
The alternative is simple: pick one key size, build it properly in HTML5, and get it approved before the rest of the set exists. Every later size inherits decisions that have already been signed off instead of decisions that are still being argued about.
What the key size has to settle
The key size is not a draft or a rough animatic. It is a finished, working banner that answers the questions a full set would otherwise answer five times over:
- Layout logic. Where the logo, headline, product and CTA sit, and what moves when space gets tight.
- Motion and pacing. The order of the scenes, how long each message stays on screen, and how the animation ends.
- The final frame. What the viewer is left with when motion stops, which is also what the backup image should show.
- Technical behaviour. Click-through, loop count, file weight and the platform the set is going to.
Once those are approved in one live unit, the rollout becomes adaptation rather than design.
Choose the size that carries the most decisions
The best key size is usually the one where the creative has the most room and the media plan has the most weight. A 300×600 or a 300×250 often works well: both are common in display plans and both show the complete message without heavy compromise.
Avoid starting with an extreme format. A 320×50 or a 728×90 forces early compromises that do not apply to the rest of the set, and approving them first tends to drag the larger sizes toward the constraints of the smallest one.
Review the live banner, not a screenshot
Approval should happen on a live preview link, in the real pixel size, with the real animation. A static frame cannot show whether the second message stays on screen long enough to read, whether the CTA arrives too late, or whether the end frame feels finished.
That is also the cheapest moment to change motion. Adjusting timing in one GSAP timeline takes minutes. Adjusting it after twelve sizes exist means repeating the same change and checking it twelve times.
Roll the approved master out across the plan
With the key size approved, the rest of the set follows the same structure. Each size gets its own layout, because a leaderboard is not a squeezed half page, but the scene order, the messages, the timing and the final frame stay the same. Shared assets and a shared timeline structure keep the set consistent and make later copy changes predictable.
In my workflow the first key size is usually ready for review within 1–2 days, and once it is approved the full set typically follows in another 1–2 days. Large sets, many languages or extra revision rounds take longer, and the schedule is confirmed with the quote before work starts.
QA every size against the approved one
The approved key size becomes the reference for QA. Every size in the set is checked for the same things: file weight, click-through, the final frame, the backup image and readable copy at its real size. Differences between sizes should be deliberate layout decisions, never accidental drift.
A short checklist for the key size
- The key size is a finished HTML5 banner, reviewed on a live preview link.
- Layout, scene order, timing and final frame are approved before rollout.
- Platform, click behaviour, loop count and weight limit are confirmed for the whole set.
- Every later size is adapted from the approved master and QA’d against it.
- Late copy changes go back into the master first, then out to the sizes.



