INGEST AND PREP RECORDS


The broadcast supply chain in Translator, our enterprise media management software, helps NBCUniversal deliver on-time and high quality content.


I lead the design and usability testing to transfer a large workflow from Google sheets to our own Translator software.

INTRODUCTION

Translator is a heavily-used application by many of NBCU’s employees. It communicates with different databases and fulfillment services, such as Mediator, to efficiently prepare work orders so third-party distributors can air our content.

NBCU Translator

There is a feature in Translator to enter a production delivery date for our content. The same date is also used in another workflow external of Translator...

“The Single File Tracker” is a shared google sheet used by Program Operations Managers (POMs) and Technicians. First the POMs will enter list items of content that needs to be prepared to send to our clients. The list often contains variations of the same content to meet certain requirements such as ratings, delivery dates, and text versions. POMs will comment edit requests in the "NOTES/EDITS" column for Technicians to fix so the media will meet industry standards.

The technician will open the same spreadsheet to find the highest priority fix requests to complete. Once all the fixes have been completed properly, the content can be sent to our clients for airing.

Single File Tracker

MY ROLE

I referenced requirements from the product team to design this feature while following the Translator theme. After we agreed on our first mocks I created prototypes and ran multiple rounds of user testing.

During this whole process I was integrated into the development team’s agile sprint cycle. I conveyed to them my user centered design solutions while documenting everything with clear annotations.

SKILLS UTILIZED

  • Sketch

  • InVision

  • Usability Testing

  • Wireframing

  • Jira

  • Design Thinking

  • Collaboration

EARLY MOCKS

Ingest early mocks

Based on the product team’s user research (I didn’t get access to them until late in the process) and direction I designed the Ingest and Prep modal above.

Each record is a specific rendition of content at the production level. The POMs would fill out this table completely to prepare content for delivery. If the record has QC problems, a POM will enter edit requests in a separate view. Once the Technicians finish all the edit requests (or there are none), the record gas assigned “QC Pass”.

Ingest early mocks

This is a dynamic view where POMs would fill in edit requests and a technician would mark it as completed. I was assigned to follow the behavior of another bulk edit form in Translator.

The product team ran a demo of this proposed workflow. Overall it fit their needs; they only had very technical update requests like adding/removing input fields. But we could do much better...

WHY WE FAILED

  1. No way to create more records in the modal

  2. The design of the two views is inconsistent

  3. Notes/Edit View

  4. a. Font too small

    b. Overload of UI for simple technician workflow

    c. Cards are too long; not enough room to display many records in viewport

REDEFINE THE PROBLEM

When our intern and newest designer started, I facilitated a design thinking session to reconceptize solutions. By framing the problem at hand and encouraging the group to use divergent thinking, we all came up with great insights.

PROBLEM STATEMENT

POMs need a fluid Translator interface that transfers their complicated workflow into a simple and intuitive one to ensure the timely delivery of high-quality content and efficient collaboration.

POM USER PERSONA

role

ROLE

  • This user manages the delivery of content by recording delivery dates and making sure is ready in time

  • Conducts quality control and records what needs improving

  • Requests technicians to fix content on specific assets

  • Marks all edits as completed until none left so content can deliver

  • Communicate back and forth with technicians to fulfill the request

role

PAIN POINTS

  • Currently there is no way to view the edit request without going into the comments of google docs - is hidden

  • No way to flag priority

  • Too much checking/unchecking/mouse clicks

  • No easy way to assign specific users edit requests

  • No permissions - anyone in google doc can edit anything

role

NEEDS

  • Needs a way to add multiple edit request on different asset versions

  • Needs to tag technicians

  • Needs ability to mark an edit as completed or not needed

  • Needs ability to create new edits

  • Needs organization of edits based on priority -> delivery date

DESIGN CHARETTE

  • A | Header with summary & pipeline visualization (3)
  • B | Checkbox on asset level to edit (1)
  • C | Pop-Up with edits per asset (3)
  • D | Sidebar with bulk actions menu; possibly extra metadata is only one asset selected (1)
  • E | Duplicate an edit button/icon (1)

NEW VISION

After the ideation session with my co-workers I got back to work designing my new vision. Below is the updated ingest & prep dashboard and edit request modal. I ran a demo with the users and got feedback about my new design- the updates are already reflected in these mocks already.

Ingest v2

I transformed the ingest modal into full page view to allow for more working space. The bulk edit and other misc features were moved to the sidebar. I also added call to action buttons to clone records and request edits.

Ingest v2

Single Record Fixes

Ingest v2

Bulk Records Fixes

I turned the fix request form to a small modal instead of full screen view and made the styles consistent so there is less disconnect between the two views. Users said they mainly entered fixes one at a time, so now each record has a card and the fixes are stacked on top of each other to allow for a more natural input entry.

If users want to enter/edit fixes in bulk, they could press the “JOIN” button to enter or edit them all at once.

I ran another demo/user testing session with the users and they were happy with the update design, even though they had a lot of technical feedback again.

Little did we understand at the time though that this design had a major flaw….

WHY WE FAILED

Although the new fix request modal was much cleaner and user friendly, the bulk/single mode wasn’t practical. It consolidated all the edit requests into one, therefore it didn’t give users the power to dynamically request/edit fixes in bulk.

FINAL MOCKS

After a couple more rounds of demos/user testing, these are the final designs we landed on...

final ingest

Final Fix Request Form

THE COMPROMISE

Although I really wasn’t a fan of the bulk edit view we previously landed on, we decided to go with it because it provides users the dynamic bulk edit power they need. Also the bulk behavior was already coded in another feature which we could replicate, which would save development time.

To make a better version of this bulk edit view, I matched the styles to the Ingest dashboard, made the cards slimmer to allow more request to fit in the viewport, and added color coordinated boxes in the sidebar to map the checkboxes with the correlated inputs.

final ingest

The final Ingest & Prep Dashboard

USER PAIN POINT

The users current workflow is in Google Sheets, which auto saves. Our team didn’t have the bandwidth to develop that, therefore I added many elements to prevent users from leaving the view without saving.

  • If there are unsaved records, they now have a light blue background

  • I created different “Save” button states- if there are unsaved changed the button will be blue. If there are no unsaved changed, the button is grey

  • I added a leave confirmation prompt if there are unsaved changes

  • I added a saving tooltip with a progress circle after the user clicks save

final ingest

The final view fixes modal

THE BIG WIN

Although we didn’t use my small and simple fix request modal for creating/editing fix requests, we discovered it still had a lot of value for viewing fixes one at a time. We created a way for users to view fix requests on the main asset dashboard. This way technicians can easily view, comment, and mark them as completed without going into the ingest dashboard or bulk fix request form, which isn’t relevant to their workflow.

The Translator team is finally wrapping up development on this feature and we are expected to release it into the production environment in mid November!