Helping planners decide across four networks
oOh! Plan is the tool oOh!media’s sales teams use to build campaign options for clients. The brief was to support more networks. The real problem turned out to be a decision: planners couldn’t compare options inside the tool.
Sole product designer · oOh!media · PM, product owners, BA, engineers, sales · Two releases, Dec 2025 and Apr 2026
Adoption signal: about 30% more campaigns created in the tool the month after launch.
The brief, what planners actually did, and the problem I chose to solve.
The problem in three lines
The business asked: support more networks. Add Rail, Billboard and Retail to a tool that only handled Street.
What planners struggled with: comparing options across networks. They compared from memory and kept notes outside the tool.
The problem I chose: help planners compare multi-network options and choose one with confidence, in one tool.
Why this wasn’t a simple feature request
oOh! was selling Street, Rail, Billboard and Retail, so more client proposals spanned several networks. But planning happened across legacy systems, sales re-keyed data, and planned didn’t always match booked.
Each network had its own pricing rules, owned by different people. Adding networks meant more options to compare, more rules to reconcile, and more room for mismatches.
What I saw that changed my direction
• With four networks, every card got long. Planners compared options from memory and kept notes outside the tool. They didn’t need more fields; they needed to see options side by side.
• In prototype sessions, planners asked “Why is pricing here?” Pricing had to come with the network they chose, instead of sitting in setup.
The principle behind the decisions
Planners set up options in order to compare them, so I designed setup and comparison as one flow. We still delivered all four networks.
Decision 1: creating a pricing model that balanced business rules and planner simplicity
The challenge
Each network had different pricing rules, so the initial approach was to create separate pricing models for each network.
The tension
Product wanted to preserve network-specific pricing logic, while Sales wanted one unified model where planners only configured the information they actually needed, and it adjusted to budget and flightling. Engineering also needed to avoid unnecessary complexity.
My approach
I worked with Product Owners to understand the pricing logic, aligned with the pricing team on business rules, and partnered with Sales to identify which pricing inputs were essential for planners.
I then used prototypes to compare different approaches with stakeholders and make the trade-offs visible.
The decision
We moved from separate pricing models to a unified, dynamic pricing model. It supported network-specific rules behind the scenes, while giving planners a simpler workflow focused on the inputs they actually needed.
The trade-off
Pricing shipped after the core form, and discounting moved to the next phase.
Decision 2: from cards to a comparison table
The Product Owner wanted to keep the cards: familiar, and faster to build. A fair point. But with four networks, planners compared options in their heads. Instead of arguing, I prototyped both and tested them with six planners. With the table, they compared without going back to their notes, and the Product Owner agreed. I took the effort concern to engineering as a sequencing problem.
One row per option, one column per decision, grouped by network. The gap to the client’s request is visible at a glance.
Decision 3: a detail page, not a hover
The table helped planners shortlist. To help them commit, each row expands, then opens a detail page.
The team suggested a hover, which adds no step. But planners asked “Can I see more detail before choosing?” For a high-value recommendation, one extra step was worth it.
Decision 4: designing the wait I couldn’t remove
Results took time to load, and speed sat with the data team. In testing, planners asked “Is it still loading?”, and some re-submitted or left. I couldn’t remove the wait, so I made it understandable: processing, delayed, timed out with a next step, and complete.
What shipped, and how it got built
One workflow from setup to decision: pricing that follows the network choice, a comparison table, a detail page and clear waiting states.
In my fortnightly design review, engineers flagged the risk of building everything at once. I worked with the PM and engineers to ship comparison first, then filters and the detail page, and signed off every staging build.
What I chose not to do
Movable cards in release 1. Planners moved between cards to compare options, and I proposed making them movable, but the Product Owner didn’t prioritise them: the cost was higher than the value then. I kept the problem on the list.
Discounting and special deals in pricing, moved to the next phase.
And an all-at-once release: we kept the full scope and changed the build order.
Faster setup, more planning in the tool
Release 1: with engineering’s integrations, campaign setup went from over 30 minutes to under 2, timed with 12 users.
Release 2: in the month after launch, campaigns created in the tool were about 30% higher than the month before, while booked volume stayed flat. Most of the growth came from multi-network campaigns. An early adoption signal for the whole release, not proof that design caused it.
A sales manager told us comparing options takes less effort and proposals are quicker.
Next to measure: multi-network share over several months, time to first option, and how often planners rebuild options.
What I’d carry into any product
• The brief asked for more networks. Watching planners keep notes outside the tool told me what to build.
• When a decision depends on rules I don’t own, I align the owners first, then design.
• Next time, I’d agree success metrics with the PM at kickoff, so each decision is measured.
Untangling a complex B2B workflow?
I’d love to hear what you’re working on.