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.
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.
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.
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”.
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...
No way to create more records in the modal
The design of the two views is inconsistent
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
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.
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
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
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
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.
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.
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….
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.
After a couple more rounds of demos/user testing, these are the final designs we landed on...
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.
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
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!