Overwolf
Ad Control: Redesigning House Ads in the Overwolf Developers Console
Turning a global-only house-ad screen into a region-aware control surface, modeled on how developers actually think about an ad container.
Role
Lead Product Designer
Timeline
2026
Surfaces
Overwolf Developers Console, Monetization / House ads
Scale
Overwolf app-developer base (tens of thousands) · creative served to ~45M monthly gamers
Impact at a glance
Adoption
Structure
Capability
Project overview.
House ads are the fallback creative a developer runs when no Overwolf ad fills a slot. Partners, the studios that move the most users, mostly use it to promote their own content, a premium tier, a feature, a regional offer. They asked for regional targeting, and the old screen could not do it: one global image per ad size on a long scroll, with no overview and no way to see what was live.
The reframe that unlocked the redesign was simple. A default ad and a regional ad are not two things, they are two states of one container.
Approach
One table, not two
From two scattered tables to a single status surface.
The Problem
You couldn't see what was live without reading every block
The old screen stacked all six container sizes in one long scroll, one global image each, with status hidden in a small toggle. Knowing what was running where meant reading every block; tracking the inventory was the real pain, not editing it.
What I decided
Collapse two tables into one row per container
My first direction split default and custom ads into separate tables, but partners found it constant back-and-forth to manage one container. I consolidated to a single table, one row per size, with the default as a fixed catch-all and custom ads overriding it where they target.
Result
The whole inventory, readable at a glance
A developer now sees default coverage, targeted regions, and live status on one line per size. Partners and DevRel confirmed the model in the sessions that killed the two-table direction.
Outcome
model confirmed by DevRel
The sessions that killed Direction 1 also validated the consolidated table. Voice-of-customer proxy, not formal usability testing.
Default + custom, in one place
One container page, two tabs, an explicit guard.
The Problem
Default and custom were one object, managed as two
Each size opens to a single page with two tabs, Default and Custom. On the Custom tab a partner adds region-targeted ads with a country multi-select, and a custom ad must be explicitly enabled before it overrides the default, so nothing is overwritten by accident. Saving, deleting, and leaving with unsaved changes now confirm, which v1 never did.
Result
Regional targeting, without accidental overrides
Partners configure both states in one place, and saving, deleting, and leaving with unsaved changes all confirm, which v1 never did. The explicit-enable step keeps a default from being overwritten by accident.
What I decided
One container page, with custom as an explicit override
Each size opens to a single page with Default and Custom tabs. On Custom, a partner adds region-targeted ads with a country multi-select, and a custom ad must be explicitly enabled before it overrides the default.
Reflection
Partners use house ads mostly for awareness, promoting their own content without a hard call to action, so clicks run low by nature and are the wrong success metric. Adoption and regional coverage are the real ones. The broader lesson I would carry forward: the cleanest information architecture mirrors how the user holds the object in their head, not the data model. Default and custom were two rows in a database and one thing in a developer's mind, and the design only worked once it matched the second.
More projects.
Check out the rest of the featured proojects I've worked on.
