Studio Connect

Contract Licensing Application

Design Process

Motivation

During our initial talks with clients, which included major film studios and platform distributors, they expressed a strong need to automate their licensing processes. Most of their operations related to pricing and licensing workflows were done manually which involved looking through tons of emails and poring over complicated spreadsheets. There was no singular way where different users could collaborate and keep track of changes to their contract terms.

To understand the challenge ahead and identify market fit, we performed extensive research and competitor analysis. The results we found were astounding! Although a few in the industry did address some of the glaring problems in the digital supply chain, almost none of them had successfully built an end-to-end solution, keeping usability and performance at the forefront.

Thus, the idea of Studio Connect was born, with a vision to connect digital content producers and distributors by empowering them with the requisite tools to manage their data and streamline their licensing workflows.

INITIAL WIREFRAMES

After several whiteboard sessions, the next step was to take the ideas and concepts and convert them into tangible use cases. I used Balsamiq as my wireframing tool to build out initial mockups to visualize some of the user flows. Getting feedback early and often was our mantra and the team worked hard towards that goal. Since we had internal users, it was a lot easier to test our user flows and get instant feedback on what worked and did not.

Below are a couple of initial screens that over time went through a series of iterations.

Design Challenges

After determining the information architecture and innovating over good solutions for the commonly traversed use cases, it was time to jump into Photoshop to add some life and color to those screens!

Since we were dealing with tons and tons of data and this was an enterprise-level application, we had to be extremely careful about the interactions we built out. A large chunk of our user base came from an "excel-mindset" so trying to find that balance between quick data entry and clean interactions posed a massive challenge for the team and I. We, however, fought our way through after hitting some much-needed roadblocks. Following are some of the design challenges we encountered along the way.

1. Data Filtering

Problem

Designing user interfaces for filtering data tables can be challenging, especially when dealing with a lot of different parameters, each with multiple values and inclusion/exclusion criteria, and then tying all that with a keyword search.

Our users wanted the flexibility to edit every parameter that the data is analyzed across. Additionally, they wanted the ability to select individual values to include and exclude. Good old and well-established design patterns do exist for a majority of these scenarios. However, when you throw in decreased real estate, contextual actions and ease of use, the problem becomes much larger.

Ideas we scratched out

We went through a multitude of approaches, some of them being: a collapsible tray section with dedicated filter options, an extended search box that converted search keywords into tags, an "assisted search" approach which provided pre-set parameters to filter table content by, and contextual column filters that offered the flexibility of selecting (and deselecting) individual values for different parameters. Though many of the tested approaches addressed different problems, none of the above provided an end-to-end solution.

Solution

After testing with our users and whiteboarding various solutions, we came to the collective consensus to combine a few of the approaches mentioned above. This gave rise to our sophisticated column filter approach which gave users granular control over the data they were analyzing and making decisions on. A user could filter by various selection criteria like contains, not contains as well as perform an exact match, Combine this with the auto-complete search box, and you have yourself a potent tool to slice and dice your data!

2. Stepped Form (Wizard)

A stepped form or wizard is a structured series of dialogs that takes inputs/questions from users and uses the choices/answers to produce a result. Furthermore, it guides users through the interface, step by step, to do tasks in a prescribed order.

Problem

As the list of information required by the user kept increasing, with the introduction of country-specific metadata, it soon became apparent that a simple, scrollable form layout is not going to work. The creation process was fairly complex, and we had to think of a solution that was less overwhelming for the end user.

Solution

We chose the wizard-style approach as it helped break down the complex workflow into recognizable and manageable sections, thus simplifying the data-entry process for the user. Labeling the steps further helped identify where a user is in the process and how much more work is required. Moreover, our form had some dependencies where early data influenced later data, so a stepped form helped create the right pace by preventing unnecessary information.

3. Batch Editing

Batch editing simply means that you can edit properties of elements simultaneously, without the need to apply changes to each element separately. In our use case, users would typically find themselves changing date ranges or language and territory values for a piece of film or TV content they would like to make available to their customers across the globe.

Problem

Since most of the elements had values assigned to them, we needed a clear visual way to convey this to the user. More so, a user would come in and change only 1 or 2 fields and leave the rest unchanged.

Solution

We iterated over a few variations and came up with the idea to display input fields with a disabled "no change" placeholder text and add a lock icon to denote a locked field. On clicking the icon, the field is "unlocked," and the user can now override the existing value. The icon now changes to an open lock to indicate a value has been edited and overwritten. We could have simply kept the field enabled and shown the value, but the issue there was sometimes a user could forget which values were changed if they are interrupted or multitasking.

Known Issues

Although this approach solved the problem at hand, it gave rise to some smaller issues. There was no way to expose what the existing value(s) for a field were. Since the user could always exit out of the modal context and find this information in the data table, we were not wholly concerned by this. This solution prevented users from adding multiple values to each field. So for example, if a user wanted to change the current language for an on-demand movie release from French to maybe English and German, there was no good way to do that in the existing model. Without getting into the technicalities of why this wouldn't make sense, it is safe to say this was not a typical use case that we needed to optimize for.

4. Collections

Since many of the daily actions are done asynchronously, a user could come in one day make changes, enable filters, perform their analyses; and come back another day and take action on the analyzed data. To provide users an easy way to reference this data later, we came up with the concept of "saving your current workspace as a collection." This tiny tool packed in a lot of power as it opened doors for cross-team collaboration, creating an approval workflow process and performing bulk operations.

Usability Testing

Since we followed an MVP (Minimum Viable Product) approach, it helped us reduce actual complexity by eliminating unnecessary features. Our basic approach to gathering feedback was to engage participants in one-on-one sessions, observe them and ask probing questions as they attempted to use the interface to accomplish tasks. One of the crucial takeaways was it helped us find where users got stuck. We validated some assumptions around our approaches and found pain points that the team failed to catch during the ideation and development phase.

Ending Thoughts

After having successfully built version 1 of our product and testing it out with users, we planned on using the data to build a roadmap. It was important to center our roadmap on what problem areas we failed to address in the prior version and which ones we could work on improving. For cases where our assumptions were disproved, we planned to consider a pivot. Our mantra always being "fail fast, or keep climbing."