Clarity: Internal Tools for Discovery, Inc.

Description

In general, these products helped with specific business goals and were used internally by different departments. 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.

Role

Product Designer, UX Designer, UX Researcher

Company

Discovery, Inc.

Date

2015-2016


At a glance, these are some of the products I worked on as a solo designer while I was at Discovery. Discovery [Digital] specifically created web-based multimedia which included documentaries, web shows, and long/short-form written content. If you’d like to know my process for the Uploader and Dashboard, shoot me an email!

The Uploader

The Uploader was an internal tool that worked with the homegrown CMS. Its main purpose is to be a point of distribution for Discovery’s multimedia content. A few important product aspects of the Uploader was that it was a means of using pixel tracking, aggregating viewer numbers, and applying relevant advertising tags to the content being uploaded. The content itself is then distributed to YouTube, Facebook, Twitter, and audience-facing O&O websites.

I resolved a handful of issues (with the help of Product and Engineering) and substantially improved the experience for producers and editors who interact with the product multiple times a day by applying UXR strategies.

Prototypes of some solutions I chose after conducting user ethnography.

The Native Ad Management System (NAMS)

NAMS was an internal tool that 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; editorial would select ads for their written content in the Uploader.

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

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

This version of the form that appears with the calendar for sales to do quick editing.

Sales required specific features like creating new deals, editing those deals, an approval flow, status changes, and creating holds.

The info given to production teams (from the sales workflow) would include dates, the type of ad, and potentially a script for the product placement.

A few design challenges were to work with the pre-existing design system for Clarity, knowing when to evolve it, having a point of inputting Sales information, and displaying approved information as a schedule for Production teams (who have to write/record the video content weeks in advance).


The Analytics Dashboard

The Dashboard was an internal tool that brought all the statistical and analytic information into one hub. It was accessible to any department at Discovery Digital—its main purpose was to have specific sets of data readily available and easily digestible by anyone who required it internally (e.g. executives, product teams, social media managers). I worked directly with the VP of Product and consulted with Engineering.

After my time at Discovery, I took it upon myself to revisit the Dashboard and improve the product over the course of ~2 years (on and off) by critiquing my own design and reprioritizing UX design alongside product goals.

Its first iteration was a rough hodgepodge of the requested content. It lacked proper UX features but included all of the relevant data. This was the version that went into production.

version 1.0, 2016

These are the changes I made by critiquing my old work and applying UX strategies (after my time at Discovery):

version 2.0, 2016. The start of segmenting and organizing the page into digestible sections.

Breaking down the UI into segments allows a method of navigation by section (rather than scrolling through an impossibly long page of data and charts) and segmenting proper information into their respective pages.

The first design is approximately 7,500 pixels long and with an average of 400-600 pixels per scroll wheel on a typical analog mouse (information here & here), it would take too long to get to a certain section and even more to scroll back up. So when the data and UI expands, the new dashboard would be flexible enough for an engineer to add on, and easy enough for a user to navigate and view applicable information.

I found a lot of help through Matthew Ström’s post about the best ways to present data, and data tables.

The last iteration of the Dashboard now includes a means of navigation on the left, a cohesive branding experience (with some artistic liberty), and a better display of data in a digestible format for those who need it.

The final iterations.

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)


Top