Challenge #1: Build Out a Consistent Design Framework
The Problem
When anything is built out bit-by-bit over a long period of time without any tangible plan, it runs the risk of lacking consistency. Individuals have their own vision of how features should look and function, and without going through a central person to help guide decisions with informed thought, the end product can result in a collection of “piece mail” experiences.
With Premiere’s applications having a mix of functions to help assist a variety of end users, product managers and developers ran into a cycle of building features without anyone stopping to ask why and whether it solved the bigger issues. So the products started seeing pages with similar workflow functions look and feel differently because. Individuals whose work overlapped these different pages experienced conflicting components, which led to some confusion, especially during the onboarding process. One of the more frequent criticisms of Premiere’s onboarding process is its relatively steep learning curve, which requires a lot of time and practice to figure out due to the inconsistency in its components and experiences. These challenges ranged from each individual sub-page appearing and behaving slightly different, down to their filter settings. Not to mention both entire applications had completely different styles to their components. While not necessarily an inherent bad thing, it was important to be able to establish integrity in choices, so there would have to be intention to have both applications work from the same design source.
The Goals
To put it simply, rebuilding the applications to have a consistent design language was the ultimate goal. This would be broken down into the following:
- Rebuild previous features that reflect the design system
- Composing a design system that all features would adhere to (both future and retroactively)
- Build new features that reflect the design system
The Solutions
Developing A Design System & Design Guidelines
In order to establish design consistency, a design system, in addition to general design guidelines, would need to be developed. I had worked on a similar initiative with a previous employer, so I was comfortable with laying out the important aspects of the design choices that would need to be adhered to (and also retroactively modified in what was currently used in the UI).
Collaborating with the product manager, we decided we would base our design system on Material Design. Given how mature, robust, and streamlined Material Design is, it made a lot of sense for us to use it as a framework instead of trying to reconfigure components from scratch. Additionally, our developers were inclined to use a template library, and we found one based on Material Design, so it was an efficient and effective choice. With that said, some customization to features was included that would more uniquely help our users.
Example screen from PDS Design System Guidelines (Confluence)
Example screen from PDS Design System Guidelines (Confluence)
Implementing Changes into the UI
Colors in Practice
Redesigned Order Screen where deliberate color usage is executed
Buttons and Fields in Practice
Redesigned Advanced Filter example (with field selected) where different button and field types are utilized
Buttons vs. Links Distinction
Previous iterations of the UI made no active distinction between usage of buttons versus links. It is generally accepted that a link should take users somewhere, while buttons execute an action.
In the new version of the UI with the established guidelines, it was important to make this distinction to help the integrity of the UI elements. If users understand this (explicitly or implicitly), whenever they interact with these elements, they will have a better experience with the consistent expectations.
Challenge #2: Expand Intuitive Usability Throughout the Platforms
The Problem
In addition to issues with the consistency of the UI, many areas of the experience needed a re-examination to improve efficiency and general user-friendliness. A large undertaking of the product team was to was to work with various end-users to find out what kind of goals they had in their workflows. As mentioned, many features were built without exploring if they were the best solution for the challenges the clients faced. As a result, different pages of the applications with similar functions had different experiences.
For sake of a user-friendly experience (and the integrity of the applications), not only was there a challenge to bring consistency to individual components, but also improve the consistency of flows and the general experience.
Along with those challenges, there were several examples of problems users faced that either weren’t being addressed, or they were only addressed with short-sighted solutions. Digging into users’ experiences and figuring out their larger goals would help the product team—and myself as the designer—explore solutions that could improve overall usability.
The Goals
The goals for this initiative were a natural continuation from the first—using the information we gained from research to make improvements to the experience. Taking that information, (some of) our goals could be broken into as follows:
- Identify experiences that cause major pain points and require usability improvements
- Fix inconsistencies in workflow experiences to help improve overall application experience and integrity
- Build and improve experiences to better serve users unique workflows without taking away from current workflow experiences
The Solutions
Application Redesign
With a design system and guidelines in place, the bigger, more impactful initiative was to redesign our applications—PDX being the first and higher priority. The product team met with different end users to figure out which aspects of PDX were working and which weren’t. Through iterative and agile project structure, we broke up our goals into separate mini-initiatives, focused around the individual tools that the application provided for users.
Filters
Tool Function
Much of Premiere Digital’s tools are made up of data tables, so giving users the ability to filter results is a key feature. Ease of use and the general convenience of regular functionality are some of what make filters work seamlessly.
Example Pain Points
- Filters across different tools/tables are inconsistent in form and function and require slightly different learning curves
- “Quick” filters take up too much vertical real estate (that could otherwise be used for working data)
- Difficult to switch access between advanced filters and results data quickly
- Lack of flexibility in working filters to save for regular use
Example "Quick" Filters
Example Advanced Filters #1
Example Advanced Filters #2
Changes
UI Consistency
With the design system and guidelines in place, all UI elements across all filters would look and behave in the same manner.
Likewise, filters of tools of the same type(e.g. all data tables, all dashboards) would have identical functioning filters/advanced filters and be very similar between the types (more on this with Changes to Advanced Filters).
Example Redesigned Advanced Filters (Data Table)
In-Column Quick Filters
Instead of dedicating a large area at the top of the screen for some designated quick and heavily used filters, we moved all standard filtering to their respective columns. This not only significantly reduced the vertical space previous taken up, but also gives users the ability to quickly filter any data type that is currently present on the table (instead of a select handful of designated ones).
A smaller, but desired additional function was to allow users to show and hide the column filters, in order to give them even more space to do their work.
Example In-Column “Quick” Filters
Changes to Advanced Filters
While making filters across the different tools consistent, there were some instances where compromises needed to be made. In previous versions of advanced filters, depending on the tool, advanced filters created an overlay on the screen, thus making it impossible to interact with anything other than the filters while it was open. This proved to be inconvenient in many used cases, especially those that required switching between filters and data results (e.g. dashboards).
For dashboards, we decided that having the ability to manipulate any desired filters at any time was the way to go, without needing to go through executing an overlay or panel. This would reflect the look and feel of the advanced filters of data tables (vertical interface on the right side of the table), but have the appropriate filters available.
While Advanced Filters would itself be panel that opens and closes, it would still allow users to engage with the data results while the panel is open. This solves all mentioned pain points users have had in regards to this functionality.
Example Redesigned Advanced Filters (Dashboard)
Column Configuration and Filter Presets
The lack of flexibility for an individual user’s workflow was a major pain point for many. This was actually an intentional choice by some stakeholders. Unfortunately this choice made it inconvenient for those who don’t work directly on the operations team (and actually several of those on the team had voiced frustration with lack of flexibility as well).
The product team recognized the importance for that flexibility. We were proponents to introduce the ability to configure columns based on what data each individual wanted—giving the ability to add or remove columns, as well as the ability to rearrange the order of chosen columns.
The concern from stakeholders was needing everybody in a given meeting to see the same data at the same time. Recognizing that as a valid use case, we incorporated a new feature where saved filter sets could be quickly accessible. This would give both individuals and specific teams the ability to adjust the layout of a given table and be able to select the desired filter preset without conflict.
Each filter type represents a column that can be locked/unlocked and rearranged which is reflected in the table
Filter Presets designated by admins, users, and colleagues
Work Dashboard
Tool Function
The Work In Progress (WIP) Dashboard is where users from the operations, mastering, and fulfillment teams access the information to accomplish their day-to-day workflows. They can create orders, see which assets have outstanding actions needed, and whatever additional mastering and fulfilling is needed to complete an order.
The typical flow for users is to go from the dashboard to a respective Order Item or Task that they have prioritized.
This serves as PDX’s landing page.
Example Pain Points
- The process of drilling down to get to the desired results - each click resulted in the page reloading the display the filtered information
- Dashboards of similar function were not as easily accessible
Work in Progress Dashboard
Changes
Drill Down
With the inefficiency of the WIP Dashboard’s drill down, one solution to course correct was to keep all data on a single screen, without directing users to new pages for each filter. A nested table was the clear choice in pursuing this, as it keeps all data transparent, and reduces any time lost in the information reloading. Additionally, keeping all the information on a single page gives users the ability to access other data if they desire. If the user wants to view results of a different subset of data, they can easily do that without needing to redirect back to a previous drill-down level.
Along with that, in keeping with the new guidelines of links taking users somewhere, every data link would now take users to their results of that listed amount. This creates the consistent expectation of this process.
Redesigned Work Dashboard with expanded single-page “drill down”
Additional Dashboard Access
While the WIP Dashboard was one entry point for some users, PDX provided other, similar dashboards depending on a user’s use case. The WIP Dashboard by default had all in-progress tasks organized from an Order Item’s perspective.A secondary dashboard within PDX was the Task Dashboard, which used the same data but provided it from the perspective of prioritized individual tasks a user would need to make on a given Order Item’s Asset. In the previous versions of the Task Dashboard, it was its own isolated experience. Because of the shared data, and because the WIP Dashboard was the default landing page of the application, merging the experiences together was a reasonable and welcomed suggestion.In addition to the WIP and Task Dashboards, admins within the organization had another view of similar data, but instead of work in progress, they wanted to see the data of completed Order Items and the associated dollar amounts. This was also added to the landing experience.With Material Design’s hierarchy of information, we separated sections between “In Progress” and “Completed” in a tab view. From “In Progress” we offered a toggle between the Order Items view and Tasks view. Similarly from “Completed” we offered a toggle to show the Order Item data and the associated dollar amounts.Having the separate but similar experiences easily accessible and transparent on the landing page would help create better workflow efficiency.
Tab Elements and Toggle Elements give users the ability to quickly access other Dashboard-types
Orders
Tool Function
The Orders page is a table that displays all Orders in the database, as well as high-level data associated with each Order.
The typical flow for users is to view a respective Order’s progress, view Order Items within a given Order, and view the Order Item’s Asset Deliverables and/or Tasks to perform actions upon.
While not a heavily used tool, because of its relative simplicity, it became a template in updating features for data tables in the application.
Example Pain Points
- Available actions lacked clarity
- Visual reference could improve
Orders
Changes
Progress Bar
The main function of the Orders tool is to quickly reference the number of orders in process (and then decide what actions to do after knowing that information). The previous version of the progress bar didn’t do a very good job showing distinctions between Orders in progress versus Orders that had been completed. We knew there were improvements to be made visually so that users could do a quick glance to get the information they desired.
Early iterations included color coding differences between Orders not started (red), Orders in progress (yellow), and completed Orders (green), but that proved to not really be helpful in this context due to associations with red (urgent/problems) and yellow (caution). We eventually settled on showing Orders in progress in blue, while finished Orders would be indicated with green. But in addition to that, we felt making the progress bar both larger and the numbers associated with each other to be more visually clear would help the use case of the Orders tool.
Redesigned Progress Bar States
UI Element Changes
The previous version of the Orders tool (and data tables and dashboards as a whole) had no consistency with where access to actions resided, so that needed to be established more concretely.
Using other frequently used tools (e.g. Microsoft Office, Google Docs) for reference, we properly designated areas to represent where certain actions would live in the application.
- Selected actions would be available through a drop down element on the left above the table (i.e. action when a checkbox is selected)
- Non-selected actions would have designated buttons/elements to the right of the selected actions
- Filters-specific actions would be available on the right above the table (advanced filters button to the left of filter presets)
- Actions that affect the contents of the table directly would have icon buttons on the left
- Exporting options would reside as icon buttons on the right
- In-line actions would be available as well, to give users options (in case it helps their workflow efficiency)
Redesigned Orders
Flow Fixes
There were multiple mislabels that went without correction that we decided to fix for sake of clarity and application integrity. An example of this within the Orders to Orders Items flow was the mislabeling the Order Items associated with an Order (under Order Details) as Deliverables and Tasks. Because these were just specific Order Items associated with a selected Order, we decided to label them as such. This also helped a mental hurdle during the onboarding process, since new users (and employees) had a hard time with distinguishing what made something a Deliverable or Task versus an Order Item.
Order Items
Tool Function
The Order Items page is a table that displays all Order Items within the database, without the distinction of their respective Orders. Users can see statuses of the Asset Deliverables and/or Tasks and perform associated actions agnostic of the Orders specifically.
The typical flow is to view and filter results to specific Order Items, then access the Order Item’s details in order to perform their actions with the associated Asset Deliverables and Tasks.
Example Pain Points
- Available actions lacked clarity and had inconsistent functions
- Certain workflows felt inefficient
Order Items
Changes
UI Element Changes
Just as with the Orders tool, Order Items underwent the same changes to its action elements (in additional to an overall update in the UI).
Redesigned Order Items
Flow Fixes
A confusing feature in Order Items was that the associated links under “Title” did not navigate users to their respective Title page. Instead, it navigated users to the Order Items Details page. To correct this, we made the Title links direct to their associated Title pages and made the Order Item ID column a priority, and linked those to their associated Order Item Details page.
This was another example of a confusing decision that negatively affected understanding for new users in the application. In redesigning the UI, it was important for us to correct these kinds of oversights in order to improve overall integrity of the application.
Flow Enhancements
Given the variety of work that can be done from the Order Items page, giving users the ability to streamline certain redundant tasks was something we wanted to help accomplish as a product team.
On our first released version we provided the following enhancements:
- Show “Blockers Only” in Deliverables and Tasks column
When a user selects the “blockers only” icon button, the results filter out any non-red (blocker) deliverables and tasks so that the users can view and prioritize work that is preventing progress from being made on a given Order Item.
Order Items with Details Spilt Screen
- Open up Order Item Details in a split screen view
Users who need to quickly work on Deliverables and Tasks from an Order Item’s Details page previously would have to open up Order Item Details in a new window or tab and navigate between multiple windows and tabs to accomplish their work. Streamlining this process to open up an Order Item’s respective Order Item Details page in a new split screen view would allow them to do the work without having to exit from either page.
Order Items with Details Spilt Screen
Media Portal
Tool Function
Media Portal is PDX’s designated tool centered around the management of Assets within the database. Users have the ability to search for individual assets, ingest new assets, group them into Wishlists, as well as download the Assets and generate Orders.There is relative flexibility of the user’s flow from this section of the application, depending on their use case. Some users mainly seek the ingestion of Assets into the database, while others go through the process of grouping Assets, generating Orders, and downloading Assets to perform their duties on them.
Example Pain Points
- Available actions lacked clarity and had inconsistent functions
- Overall transparency of what actions were available for users
- Executing certain actions lacked consistency between screens within the tool
Media Portal - Assets
Media Portal - Cart
Media Portal - Wishlists
Changes
UI Element Changes
Just as with the Orders and Order Items tools underwent the same changes to its action elements (in additional to an overall update in the UI), since they were all data tables that required a similar consistency.Since the main user-base of Media Portal were external users and had their own set of needs and desires, it deviated from many of the UI choices of Orders and Order Items. We needed to rein those decisions back so that PDX as a whole felt like a cohesive application. Many of the UI changes within Media Portal were bringing in the rules and associations from the other data tables.With overall changes to the company’s design system and guidelines, actions that were previously hard to find or had poor location associations were able to be more transparent to users at all times with the new layout structure. For example, the main page (assets view), cart view, and wishlist view were put into a tabular structure so users could navigate between them easily, since they are where users operate out most frequently. Previously, the distinct views were grouped with other actions, and the wishlist was hidden in a catch-all “see more” menu dropdown.
Redesigned Media Portal - Assets Tab
Redesigned Media Portal - Cart Tab
Redesigned Media Portal - Wishlists Tab
Future Plans
The product team had many ambitious initiatives lined up to continue to make Premiere’s applications more consistent, user-friendly, and uniquely user-focused. Unfortunately, due to changes in priorities in the company, the team was dismantled and our visions were put on pause. However, I want to highlight a couple of initiatives worth mentioning, to achieve in the short and long-term.
Title Pages
After completing updates to tools focused on Orders (Orders, Order Items, Tasks, and the Work Dashboard) and Assets (Media Portal), we had our sights set on Titles, which was the final level of PDX’s structure. Since many of the work tasks within the application were associated by Titles (e.g. movies, television series, advertisements), being able to improve the experience around those was a high priority.
Some projects:
- Iterating on the Title playlist tool, where users can organize pre-roll and post-roll of content on streaming services
- Developing a dashboard specific to Title searching
- Updating the UI for Titles results (similar to the redesigns of Orders and Media Portal)
User Dashboard
During meetings with the VP of Product Management, we had many excited conversations about where we could take the user-focused experiences within PDX. We discussed very rough versions of what we wanted to become a User Dashboard. This would serve as the landing page and would be a proper dashboard where users could view and execute work that was unique to them. They would be able to create widgets from the different tools within the application so that it was hyper-focused on their workflows and changes to data that they cared about.
