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 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).
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.
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:
- The concept of a new product, to overhaul the current sales workflow and encourage more sales towards native ads, brought more awareness to multiple teams that native advertising was a major revenue stream for the company
- Talks about NAMS educated stakeholders who were not normally working with sales or advertising clients on how the current process works, and how it keeps itself afloat
- Creating the concept injected confidence about the Product team and its far-reaching function/influence within the company; this included awareness of the complexities of Clarity and how it could be utilized and thought of as a helpful tool
- Because a good chunk of revenue was coming from ad impressions, talks to improve ad inventory management and strategies to evolve the current internal tooling were always relevant to business goals
- If I were given the chance to test these concepts with teams, I’d look for metrics like an increase in the number of deals created, the change in ad revenue, the completion rate of Inventory Manager to Sales Planner flows, completion times of Inventory Managers and Sales Planners respectively
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)