Ask anyone who produces display advertising where their time goes, and the answer is rarely "design". It is everything around the design: the sizes, the versions, the corrections and the approvals. These costs don't show up in a brief, but they decide how fast a campaign can move.
Problem 1: one idea, many sizes
A campaign is one idea that has to exist in a dozen formats — square, skyscraper, leaderboard, mobile, sometimes more. Each one is rebuilt or adapted by hand, and each one can drift slightly from the others: a cropped product here, a different font size there.
What helps: design once, then generate the other sizes from the original, keeping the layout and only adjusting what each format needs.
Problem 2: product data that changes
Retail campaigns carry products, and products change: prices move, items sell out, a new colour arrives. When product names and prices are typed into each banner by hand, every change means opening every banner — and every banner is a chance to miss one.
What helps: keep product data in one place — a product feed or a spreadsheet — and build the banners from it, so a change is made once.
Problem 3: inconsistency across a team
When several people build banners, each one interprets the brand slightly differently. Colours are picked by eye, tooltip styles vary, and the result looks like three campaigns instead of one.
What helps: a shared brand kit — approved colours and default styles that new banners start from, with the critical ones locked.
Problem 4: approval loops
Feedback arrives by email, as screenshots with arrows, often about an older version. Nobody is quite sure which file was approved.
What helps: send the client the real, working banner with a place to comment on it directly, and record the decision against a specific version.
Problem 5: ad server details
Each ad server wants the package its own way — click tags, manifests, size tags, weight limits. Getting one detail wrong means a rejected upload and another round trip.
What helps: export for the ad server you are actually using, with its requirements built in, rather than adapting a generic file by hand.
The common thread
None of these problems is about creativity. They are about repetition — doing the same small task many times, by hand, with room for error each time. The teams that move fastest aren't the ones that work harder on those tasks; they are the ones that stop doing them by hand.
That idea is at the heart of how we built iBannerly — read how iBannerly approaches these problems.
