Updating the Point-of-Distribution for Editor Efficiency


In general, the Clarity products helped with specific business goals and were used internally by different departments at Discovery. The Uploader was part of the internal CMS where our editors and producers laid out their content. I worked to research the pain-points of the existing Uploader and updated it for user efficiency.


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] specifically created web-based multimedia which included documentaries, web shows, and long/short-form written content.

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.

Understanding the Editor Journey

Initially, we already knew about a bug that was detrimental to the Editor workflow; the main problem we wanted to tackle was the reason for Editor teams to ask Product teams for help on deleting a scheduled post. We assumed that there was a disconnect between the front and back-end, where deleted posts weren’t completely deleted from our servers. However, after diving into some research about their day-to-day, I found multiple different pain-points in our Uploader that also included the main issue.

This is a journey map in the form of a BPMN (Business Process Management Notation) chart. You can see the typical editor’s process overflow into the Product team. The Product team needn’t be involved with typical editor work in the CMS—unless something technically went wrong with the CMS. This happened often enough that it became part of the map.

A few of these issues were discovered simply by shadowing the user and contextualizing their actions. By interviewing, I was also able to hear their perspective on the product, and list some feature requests. Knowing that we were on a strict sprint meant that I had to prioritize my own solutions based on qualitative and quantitative information, versus the requests of the user. Luckily, those requests overlapped with the necessary solutions that I created which allowed me to further prioritize multiple solutions.

This is the map after I worked with the Editor and Product teams by creating solutions that fixed usability issues. As you can see, the entire workflow is now contained within the editor team.

Design Iterations

By working with engineering on understanding technical capabilities, and working with PMs on goals for the CMS in the long-run, I was able to design and prototype various solutions that could be implemented based on our time constraints. I had not only discovered the root cause of our main problem, but I also created multiple solutions for our users to smoothen out the wrinkles in the CMS product they were using every day.


This project was an excellent step towards establishing a more UX-geared design process at Discovery.

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)