Summary
Before this work, deals between advertisers and publishers were negotiated almost entirely offline, through account managers. Media Marketplace is a new section of Ad Manager with three connected surfaces: publisher discovery, a public inventory catalog and a personal deals workspace. I was the sole designer, in close partnership with a dedicated PM.
Role
Senior Product Designer, UX and research (architecture, flow mapping, logic validation). A separate UI designer handled visual execution.
Team
1 Product Designer, 3 Engineers, 1 PM
Deliverables
Journey map, flows, interactive prototype in Lovable
Impact
Designed to give self-serve advertisers direct access to inventory and deals
01 The problem:
Every step went through a person
Finding and activating publisher inventory needed an account manager at every step. The three surfaces had to work as one system, and a full in-platform negotiation system was out of scope.
- No self-serve way to discover publisher inventory.
- No path from finding a package to running it in a campaign.
- Only an account manager could enter an agreed deal and assign it to a campaign.
- A real constraint: negotiation had to stay offline.
02 What I found
I ran discovery sessions with advertisers, account managers and sales teams.
No visibility.
Advertisers couldn't see inventory without asking a person.
Hidden packages.
They were valuable but invisible to self-serve advertisers.
The Package Drop-Off Problem
The biggest drop-off was between finding a package elsewhere and using it in an Ad Manager campaign.
Deal performance.
Seeing it was a recurring request.
03 The decision
One system, not three tools
I started by mapping the full journey across the three surfaces, using AI for the journey map and for an early interactive prototype in Lovable. The prototype wasn't polished, but it showed stakeholders how context had to flow between surfaces and exposed a few navigation problems before any code was written.
The mapping showed that these couldn't be three separate tools in the same tab. Someone discovering a publisher needed a direct path to their inventory packages, and someone looking at a deal needed to see its performance without leaving the deals list. So every surface had to know where the user came from and where they were likely to go next. Any flow that made someone navigate backward was redesigned.
The custom deals workflow was the hardest part. A full in-platform negotiation was out of scope and the conversation would always happen over email, so the deal request form had to do the heavy lifting: structured fields, multi-publisher support and a clear summary of the request. It gave the offline negotiation a solid starting point and a reason for the advertiser to come back once terms were agreed.
- Discovery: searchable, filterable publisher cards with a direct path to request a deal.
- Catalog: public inventory with performance data and direct campaign activation.
- Deals workspace: request form, new deal creation, performance and warnings for underperforming deals.
- Auction Report link: deal IDs appear as a reason for lost bids.
04 The trade-off
Deals that happen over email
Because negotiation stayed offline, the deal request form had to carry the load. I designed it so the email conversation started from a solid base, and so the advertiser had a reason to come back to the platform once terms were agreed.
- Structured fields instead of a free-text request.
- Multi-publisher support in one request.
- Dynamic fields that change with what the user selects above, because some settings only apply depending on the tab or the partners chosen. With multiple partners, users can set one general budget for all of them or a custom total budget for each. The form had many combinations like that.
High fidelity prototype
05 The outcome
Power users need scalability and beginners scanability
It has not been developed yet, so there are no usage results. What it was designed to do: give self-serve advertisers direct access to inventory and deal management for the first time, and take account managers out of discovery and activation.
05 Looking back
Power users need scalability and beginners scanability
With Lovable's help I mapped the user journey and saw where things were unclear and where they needed improvement. Mapping before drawing screens is also what showed me this was one system and not three tools.