ABOUT THE PROJECT
Mediamorph's Studio Connect is a web-based enterprise application that allows media content distributors to manage their contract licensing workflows across digital channels.
I was responsible for gathering this project’s requirements, architecting the web application, prototyping and creating visual assets for development.
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 on a manual basis 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 blaring 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.
As the team worked in a lean fashion, I immediately hit the whiteboard and organized several brainstorm sessions with the UI team as well as our stakeholders. It was important to involve stakeholders at this stage to ensure everyone was on the same page with the vision of the project. It also proved extremely advantageous as getting their input and ideas early on helped realize some concepts quicker than we imagined.
The next few days I spent sketching and creating minimal paper prototypes to get all the layouts and flows to a place where the interactions felt intuitive and cohesive. Going straight to sketching is usually my go-to as it allows me to see my ideas come to life, explore possibilities and evaluate them with stakeholders and users.
After several whiteboard sessions, the next step was to take the ideas and concepts and convert them to 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.
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 huge 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.
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 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 collapsable 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 provided 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.
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 an extremely powerful tool to slice and dice your data!
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.
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.
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.
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.
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 an 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.
Since we followed an MVP (Minimum Viable Product) approach, it helped us reduce actual complexity by eliminating unnecessary features. Our basic approach to gather 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.
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."