← Selected work

Monetize: designing a 0→1 in-scene advertising tool

Frequency found a new revenue opportunity in advertising rendered inside the video itself. It needed an interface before customers could use it, and none of it existed yet.

Product
Frequency Studio · Monetize module
Role
Lead Product Designer
Team
PM (requirements), me plus 2 designers, Monetize domain experts, lead engineer
Timeline
2 months to dev-ready, 2026
Status
Design complete · in development · capability announced June 2026
Overlapping screens from the Monetize module: the distributor dashboard with ad-load and fill-rate metrics, an edit-endpoint panel showing supply ad tags, a placement-rule configuration with ad format toggles, and the ad creatives list. All data shown is demo data.

Summary

The problem
Frequency opened a new avenue of revenue: ads rendered inside the video itself. Taking it required a workflow that let customers add an ad, place it within their programs, and then monitor what those placements earned. None of that existed. The tool had to be built from nothing.
Why it mattered
Without the interface the revenue stream stayed theoretical. Every customer who couldn't place an ad, or couldn't see what a placement returned, was revenue neither they nor Frequency collected. A conference deadline set the window.
My contribution
I designed the core screens for the MVP, interrogated each requirement for the user need behind it, ran the review loop with the PM and then the wider stakeholder group, and allocated secondary screens to two other designers when scope outgrew one person.
The result
Designs were dev-ready in two months. The product is in development, and the In-Scene Advertising capability was announced publicly in June 2026.
  1. 01MVP scope from the PMMonetize is a large tool made of many features. With the conference close, we took requirements for the three most vital ones first.
  2. 02Interrogate each featureOur PM held the customer knowledge, so we asked the basic questions of every feature, its purpose and the need behind it, and derived the user flow from the answers.
  3. 03Design reviews with the PMBack and forth on the screens until each one matched the intent.
  4. 04Stakeholder sign-offPresent to the lead engineer and CEO, then revise until every stakeholder approved.
  5. 05Rework as scope arrivedRequirements and sub-features landed in fragments rather than as a whole, so later features forced edits back into earlier ones.
  6. 06Fix the process behind the reworkExtended our team's workflow skill so finalized requirements get captured and updated, since they kept shifting meeting to meeting.

01 Problem and context

Monetize is Frequency Studio's new tool for in-scene advertising. It gives channel operators one place to monitor monetization health, set per-channel placement rules and ad load, configure per-stream ad tags, and validate rendered creatives.

This was a true zero-to-one: no legacy screens to iterate on, no established patterns for the domain, and a user base that had never done the task anywhere.

It was also large. Monetize is not one screen but several features that together make a workflow, and the design ran feature by feature rather than as one clean sweep.

02 Role and scope

  • I owned: the main screens: dashboard, placement rules, ad tags and ad creatives. When scope outgrew one designer, I allocated the smaller screens to my manager and a fellow designer and kept the system coherent across all three of us.
  • The PM owned: requirements: which components each screen needed and the reasoning behind them. All customer feedback and competitor knowledge rolled up through him.
  • Together: repeated working sessions with the PM, Monetize domain experts, and the lead engineer to make sure each screen's stated purpose actually held up, which is where several features didn't survive.

03 Constraints

  • Customer evidence was proxied. All customer feedback reached us through the PM, so I could not verify a need directly. My countermeasure was to ask of every requirement whether a customer need sat behind it or someone simply wanted the feature. Sometimes his word was the honest limit of what we could check, but the question got asked every time.
  • A hard conference deadline set the two-month design window.
  • Requirements arrived in fragments. Sub-features surfaced one at a time rather than as a whole picture, so I could not see how the parts fit before designing them. Later features kept forcing revisions into earlier ones.

04 Key decisions

Cutting bulk review, after designing it far enough to know

It was hard to design because there was no purpose to design around.

A bulk-review feature was requested and I explored it seriously, dozens of screens deep. The exploration is what exposed the problem: it was genuinely hard to design, not because the interaction was complex, but because there was nothing to design around. Asking why at each step kept returning no customer need it would serve.

So I raised it. I worked through the purpose with the PM and then the CEO, and when we agreed no need existed, we dropped it. On a two-month clock, building something without a purpose costs the time the rest of the tool needs.

The descoped bulk-review exploration in Figma: several sections of screens exploring bulk review flows, all ultimately cut from scope.
The exploration that earned its own deletion. Descoping was not a shortcut. It was the conclusion of the work.

Fixing the process that caused the rework

The rework was not bad luck, it was structural. We started designing before every stakeholder agreed on what a feature was for, so alignment arrived late and expensively.

Our team already knew this was a pattern, and a colleague had built a first version of a workflow skill in Claude to force stakeholder sign-off earlier. Running it on Monetize showed me what it was missing: requirements kept shifting meeting to meeting, and nothing captured the version everyone had actually agreed to. I extended the skill to record and update finalized requirements, so the agreed scope is written down rather than remembered.

05 Where AI helped, and where it didn't decide

  • Ideation speed: I used AI to generate several early design directions, then adjusted the strongest against our design system and existing product patterns. The generations set the option space; fitting them to Studio was human work.
  • Blind-spot checking: I asked AI to produce the list of questions we should be able to answer for the project to be genuinely user-focused, then made sure we could answer them, so we weren't shipping assumptions.

06 The solution

Five areas, one module: a dashboard for monetization health (top of this page: KPI cards for ad load, requests, insertions, impressions, fill and render rates, with channel and distributor views), placement rules for controlling where and how densely ads can appear per channel, ad tags for per-stream configuration, ad creatives for validating what actually renders, and a guided learn-more surface for a task no customer had done before.

Placement rules flows in Figma: the empty state, populated rules list, create placement rule modal, and row-level edit actions.
Placement rules: empty state, populated list, creation and editing. Every list in the module shares the same interaction grammar, so learning one surface teaches the rest.
Ad creatives screens in Figma: empty state, expandable per-channel creative list, and a preview panel with a video player for validating rendered ads.
Ad creatives: operators can preview the actual rendered creative. Trust in a revenue product comes from seeing what viewers see.

07 Outcome

  • Designs reached dev-ready in the two-month window; the product is in development.
  • The In-Scene Advertising capability was announced publicly in June 2026: four ad formats, compatible with existing server-side ad insertion, deployable across Frequency's 2,500+ live channels.
  • Usage metrics don't exist yet and won't until launch. This page will get honest numbers when there are numbers to report.

08 How I would measure this

The product is in development, so there is nothing to report yet. What I would watch once it ships:

  • Placement rules created per active channel in the first 30 days. The tool only earns its keep if operators configure it themselves. Low numbers mean the setup flow is the problem, not the concept.
  • Support tickets per new Monetize account. This was a task no customer had done before, so tickets are the cleanest signal for where the interface fails to teach.

09 Reflection

Difficulty in the design was diagnostic of a gap in the requirement.

  • What this project taught me: "why" is a design tool. The features that were hardest to design were hard because they had no purpose.
  • What I would do differently: bring every stakeholder into the room at kickoff, with low-fidelity screens as the talking point. We reworked a lot at the end because the engineer, the other stakeholders and I turned out not to share the same picture, and we only discovered that late. Initial designs are cheaper to argue over than finished ones.
  • What I could not fully solve: the evidence chain. With customer knowledge proxied through one person, some decisions rested on trust plus interrogation rather than direct research. Post-launch behavior is where those bets get checked.