Reimagining a System to Overhaul the Ad Ops Workflow


In general, the Clarity products helped with specific business goals and were used internally by different departments at Discovery. NAMS was an internal tool I worked on that specifically tackled the workflow for Ad Ops. I wrote about the various goals of each member of the Ad Ops team, their involvement with teams outside Ad Ops, and how I organized the product based on user goals.


Product Designer, UX Designer, UX Researcher


Discovery, Inc.



Discovery created content which required a certain means of tracking and aggregated analytics to derive information for monetization. I worked on these products as a solo designer. Discovery Digital Networks specifically created web-based multimedia which included documentaries, web shows, and long/short-form written content.

I was able to visualize a complex system with the Ad Ops Product Manager that would have a major impact upon the Sales-to-Production workflow by working with four different teams (Production/Editorial, Sales, Product, and Engineering).

The Native Ad Management System (NAMS)

NAMS was an internal tool which organized and scheduled native advertising deals for Discovery’s multimedia content.

Essentially, the Sales team made ad deals and those deals need to be passed to the Production team. Production would then inject those ads into video; the Editors/Producers would select specific ads to surface for written/video content in the Uploader.

Native advertising accounted for more than 50% of advertising revenue; thus, there was a clear incentive to try to up those deals, and encourage Sales to make them.

Native advertising is the use of paid ads that match the look, feel and function of the media format in which they appear. — Outbrain

Contextualizing the Current Workflow

The problem here was that the Sales workflow was too prone to human error, insecure, and not scalable because they used spreadsheets. Clarity already had an internal set of product tools to help with the workflow (such as listing all existing campaign deals) and it made sense to evolve that product to make Sales’ dealmaking more efficient.

Of Ad Ops, there were two major users: Inventory Managers (who check on possible ad availability of shows by date and created holds), and Sales Planners (who required specific features like editing holds, reviewing all campaigns, and communication based on notes).

This is an early iteration of the NAMS system. The first image is a mock of the ad information that needs to be associated to an episode. The second shows how a date picker could be expanded to include ad options. And the third is a calendar showing inventory for sales/managers to do quick editing and navigation by date.

Interesting Obstacles by Understanding User Goals

By talking with Ad Ops, I had understood that their organization process was based on dates and schedules. I was thinking about taking something more analog (text/dates on a spreadsheet) and changing it into a conceptual representation of time to help users better organize their deals. So, I solved that by creating several pages that were populated with relevant information based on the goals of the page and user.

For example, an Inventory Manager (someone who checks on possible ad availability of shows by date) may only want to see the inventory (or the available space for ads) of a particular show, as opposed to showing all of the deal information on a particular campaign.

The Sales Planner will want to actively fill in campaign details and associate dates with particular types of ads to air. As you can see, these two users had different goals but may deal with the same ad campaign in a workflow.

In early iterations the inventory calendar included an editable right rail with all the campaign details, and it locked when the deal was signed off. This didn’t work because it was too info-dense—several segments of this page would be useless to someone working to reach goals outside of filling in details.

Eventually, with insight from Ad Ops teams, I decided to separate different types of information depending on what the user would actually need to complete their workflow. Instead of including all information into one page, I separated the visual of the inventory calendar from the campaign details. The campaign details would be referenced in a different page entirely.

This made sense since each role had different goals to achieve while working on the same campaign. On top of that, certain segments of Clarity were already made to break down details of existing campaigns. After consulting with the Engineering teams, this meant that it would’ve been simpler for engineering to integrate text-based data on an existing page.

The last few iterations, breaking out information into relevant pages. The goals of each page are more clear, and more specific to the role of the Ad Ops member.


Unfortunately, NAMS was frozen as we moved forward with larger projects and roadmap, including major site migrations and company mergers and I had to shift focus. But there were a few impactful ripples that came out of working on the project:

Discovery Product Team

Eric Mies (Product Manager)
Lehua Sparrow (Product Manager, VP of Product)
Ibu Madha (Front-end Engineer)
Jae Page (Front-end Engineer)
Robert Saurini (Back-end Engineer)
San Chung (Product Designer, UX Designer)