Sony Pictures : Runner
‘Multi-Cart’ Case Study
PROJECT OVERVIEW
My Role: Lead UX Designer
Tools: Sketch App and InVision
BACKGROUND
Runner is a next-generation cloud storage and sharing platform to centrally store, manage, review and distribute digital files to users worldwide. Runner supports the workflows of teams all across Sony Pictures Entertainment as well as assisting outside vendors.
As our team retired older DAM systems and migrated all users and content in to Runner, it became apparent that we would need to start adjusting functionality to better suit the needs of our users.
What’s the problem?
PROBLEM NUMBER 1
The initial problem statement that came to the design team via our Product Owner was that is was just too difficult dealing with "a ton" of assets. Now that everyone was using Runner and filling it with tons and tons of content, it was becoming harder for people to complete their work in a straight forward manner. Depending upon a users access permissions and search terms, they could be sifting through hundreds of thousands of assets at a time
EXAMPLE SCENARIO
The example given to us was "Let's say that I want to create an email share with 400 assets... it takes so long for me to batch it them up, add them to my cart, select them all again, send the share and then remove them" Looking at the absolute minimum amount of clicks to accomplish this series of tasks, we're looking at a minimum or 54 clicks.
WHY?
Pagination was put in place throughout the site for two reasons:
To increase technical performance site wide
To help users focus on the most relevant content
Unfortunately, when it came to large batch actions, having to click through multiple pages, make your selection(s) and repeat, became a huge strain.
PROBLEM NUMBER 2
After sitting with and observing multiple Runner users from different groups, with different workflows, a theme started to develop. Users have multiple projects, both big and small, that they need to be working on in the same general timeframes but when they started adding all of these assets to their cart, it became a total mess. At the same time that I was observing this behavior and hearing these frustrations, a user sent an email to one of our business relationship managers asking to have a "date added" field added to the cart page. People all over were running in to the same problem but were vocalizing it in all different ways!
OBSERVED BEHAVIORS - WORKAROUNDS
As users would showcase the problems they were facing working in their cart, they would also detail the workarounds they were using.
Users were creating new folders (and whole folder trees) in the system as a staging area before moving things to their cart and taking action on them.
Users were permanently changing the names of assets in order to add a unique text string that could be searched for at a later date.
These workarounds, while potentially clearer to the user, adds many more steps to their work flow and potentially alter the experience for other users in the system!
PUTTING IT ALL TOGETHER...
So, we have a few problems that our users are facing that on the surface may seem separate from one another. But as one of our users put it:
Problem Number 1 was focused on wrangling up and dealing with large quantities of assets going in and out of the Cart while Problem Number 2 was all about maintaining organization in the cart. These take-a-ways also re-enforce pain points and needs that had been highlighted in our User Personas.
Ideation
WHERE DO WE GO FROM HERE?
We put our focus on Cart organization and handling batch actions as being the most complex part of the web of problems. We started to try and think about other websites and platforms that allow for building and organizing lists of content. Knowing that both personas we were dealing with were open to innovation but also had speed as a key need, we wanted to look at high traffic consumer facing platforms in hopes of finding intuitive examples.
When you think of a cart, you think of shopping. The initial name and functionality of the feature were pulled from an e-commerce experience but we found that it no longer held up. The ability to organize a shopping cart was pretty much non-existent.
So we shifted our thinking and began thinking about playlists. When you boil it down to the essentials, a playlist is a cart full of things you want to listen to, not buy. Where we saw the biggest correlation was that you could create different playlists, name them, arrange and distribute them. We began looking at the top music and video platforms to see what they did that worked, specifically, how they handled the interaction of adding content to a playlist and how users were able to navigate through their different playlists.
'MULTI-CART' IS BORN...
With everything that we learned, we began to explore what a "Multiple Cart" feature would and could look like. In our minds, it would allow users to create separate carts for their individual projects which in the end would also make it easier to take action on those assets.
ITERATION #1
I began sketching out possibilities and one that I was most fond of is shown above. In the sketches, a users carts would be laid out in a list. This would provide plenty of room for related metadata to be displayed as well as context menus and a prominent 'Create Cart' option. However, with further review, this design would just get in the users way. No matter what cart I wanted to look it, it would always be 2 clicks away.
So I went back to the users to learn more about their interactions with the cart. While the narrative of an overloaded cart carelessly juggling multiple projects continued to come up, a new narrative presented itself. While there are some people who flat out never use this feature, there are also people that use it in very short and direct ways.
Moving forward, we had to realize that we were walking a tight rope between potentially opening up a whole new world of added functionality for some, while trying to make it seem as though nothing had really changed for others.
ITERATION #2
Keeping in mind what I learned from my first design, what our users had told us, we started to explore merging the list of carts with the list of cart contents in to one view. Using a structure found elsewhere in our system, I explored the idea of a static side bar to house our cart list and showcasing the contents to the right. This too created problems.
If the user never used the multiple cart feature, this is a ton of wasted screen space.
At smaller screen sizes, content would be cut off. Even with allowing the user to scroll left to right, they would never be able to get a complete overview of their content.
ITERATION #3
With Iteration #3, we finally landed on something that could give us all of the desired functionality while also confidently walking the line between a lot of changes and no changes. Again, looking to use structures found elsewhere in our system, we looked to the search filters drawer. Like the static column from before would live off to the side and would combine our cart list with our cart content in one view. The major difference was that this drawer could be collapsed to hide out of sight, thus allowing for our users to see their content lists fully.
ALSO...
For our users that had no need or desire to use this functionality, the system would remember whether the user left the drawer opened or closed and use it as a temporary preference for their next visit. This meant that if I closed it once, it would stay closed for all of my return visits, until I opened it again. As a result, visiting the cart would have no noticeable impact on this user group!
Add to cart
Now that we had the cart page(s) roughed in, we needed to focus how users would get assets in to their carts to begin with!
As with the cart pages, we needed to consider two very different scenarios in which this feature was going to be used. We had users that would most likely be adopting the functionality while others who would want these changes to stay out of their way.
The current 'Add To Cart' functionality was to select your assets and click the Add To Cart button in the secondary navigation. Very simple. Our initial iterations were to have that same button click extend a dropdown context menu with the users 5 most recently created carts, an option to create a new cart as well as view all carts.
This option was similar to a lot of the examples that we looked at early on but was scrapped for several reasons:
While it visually maintained the look and feel of our current context menus, the way it behaved was a fairly large departure.
The context menu model felt like it was quick to access, but ended up feeling limiting. Super users would regularly have to click twice and drill down in to 'View All Carts'. Users would not be able to add assets to multiple carts at once. etc etc.
We ended up going with a modal approach because it gave us the space to solve all of the above shortcomings and then some.
The modal also stayed true to our design system
Users would be able to browse their full list of carts, not matter the count
Assets could be added to multiple carts at once.
Users could create and name a new cart, add assets to it as well as existing carts at the same time.
This design even allowed for users to create multiple carts at once if need be.
The modal provided us with the real estate to show validation for any number of scenarios that required it.
ALSO, while keeping our non-users in mind, we wanted to make sure that this would have the least impact on those with only one cart. In the event that a user only had their default cart, the modal would open upon clicking 'Add To Cart', their single cart would be preselected and they would just need to select 'Confirm' to move forward.
While it technically is an added click, we wanted to keep the option of additional carts open to them if they decided they needed it down the line.
The little things…
While there we large design challenges that came with this solution. The real magic that our users would experience was going to come to them via small additions throughout the process.
100 ASSETS PER PAGE
The big thing that added to a users click count was navigation the pagination. We added a small toggle to all of our listed views (Search, Folders, Cart) that would allow users to change from viewing 50, to viewing 100 assets. This allowed them to stick with 50 for increased performance during normal browsing, but toggle over when they wanted to dig in and get to work.
500 ASSET LIMIT
Runner currently has a limit on the number of assets that can be handled by our batch actions (Download, Email Share, etc). That limit, is 500. When we started throwing around the idea of allowing users to have multiple carts, the conversation always got to "where do we draw the line?". Looking at the numbers, none of our users had carts with over 500 assets so we drew the line right there.
SELECT ALL IN CART
A true Select All (more than the current page) was not an option in Search or Folders view because it opened us up to too many bad scenarios. However, those concerns no longer held up for the cart now that we were dealing with a set number of assets. Putting a true Select All in Carts allowed our users to completely bypass pagination when taking action on their assets in Carts. Another huge boost to productivity!
Final design
The results
Looking back at the original scenario, users were spending a minimum of 54 clicks to add 400 assets to their cart and send an email share. With the improvements to the Cart workflow that we designed, users were able to cut their workflow by more than half to a measly 18 minimum clicks to complete the same task!
When Multi-Cart went live in production we saw an instant adoption from our user base with an average of 30+ new carts being created every day. At the time of this write-up, 300 users had created new carts with an average of 5 carts per person. Even looking at the "non-users" that we designed for, within a week they were all running multiple carts.