Design Teardown — Cinebody Selects
“Cinebody is real-time storytelling delivered at the speed of social — revolutionizing the content creation process for brands, agencies, and creators.”
About Cinebody
The core concept of Cinebody is simple. People film things using the Cinebody app for iPhone. The app uploads these videos to a cloud-based platform. Once an upload is complete, any member of the project team can download it. Editors can also upload final videos to the platform. These core features coalesce to make collaboration fast and efficient.
The previous version of Cinebody introduced a simple-yet-effective workflow. Over time, the Cinebody team began to notice some areas for improvement, and soon enough, the feature requests started to come in. One of the most common requests was better content organization and management.
We hadn’t anticipated how the Cinebody ecosystem would facilitate human management of massive floods of content. Small projects were not a problem. Large projects — with hundreds of filmers shooting thousands of clips — were another matter; an editor or project manager might spend hours sifting through clips. This inefficiency was a major problem. After all, one of Cinebody’s primary selling points is the speed it enables.
The previous version already included some helpful features. Our last iteration included the ability to create a “Shot List” for a project. This allowed project managers to provide some guidance to filmers. Via the Shot List, a filmer could select a shot and label it as, say an “action” shot, for example, as opposed to other types like “sound bite” or “venue setting” shots. We had also implemented the typical sorting and filtering options.
Unfortunately, these features fell short. Sorting and filtering are table stakes and easy to ignore. The Shot List was useful, but it’s easy for a filmer to forget to select a different shot when they’re caught up in the moment.
Introducing Selects
The Cinebody team approached us with a new idea: Selects. The idea was:
- Filmer shoots a clip
- Moderator approves or rejects the clip
- Editor downloads only the approved clips
- Editor uploads an edit
- Moderator approves or rejects the edit
Both the value and the intention of this concept were clear. We could enable a faster workflow by making collaboration easier. The Selects feature also had the potential to make Cinebody a more robust tool for managing video projects end-to-end.
Luckily, one of Cinebody’s existing clients was already interested in the Selects functionality. Their eagerness provided us a great opportunity to soft-launch the new workflow, allowing us to test it in the real world almost immediately. To minimize our turnaround time, we focused on retrofitting our existing UI components rather than building new ones.
While the soft launch was functional, the experience still needed some polish. We moved very fast and focused on functionality. By focusing on one client’s needs, we were able to do a lot of hand-holding. This hand-holding approach enabled us to execute efficiently, but we realized that it wouldn’t scale.
Cinebody has a range of clients in industries from professional sports to show business to food-and-beverage. Every industry has its own vernacular, and every client has their own way of doing things. To make the Selects feature a success, we needed to eliminate some complexity in the interface, and improve communication regarding the new feature.
Before the soft-launch, we suspected that there would be a need to go beyond a perfunctory Band-Aid-on-the-bullet-wound approach to making Selects camera-ready. After a few weeks, the Cinebody team confirmed our suspicions in the form of client feedback. Internal confusion around the feature abounded. Our hand-holding fell short, even with a single client, as soon as more individuals on their team began interacting with the platform and trying to understand the Selects feature.
This meant that we would need to redesign other parts of the platform, without further confusing existing users. “Project Settings” was a key area of focus. It became necessary to add some controls related to the visibility of content with the new Selects feature.
Opportunities
After an assessment of the most pressing problems, our team discovered opportunities for further improvements as well — low-hanging fruit, which we could harvest and deliver with the larger feature release.
Filtering and Sorting Improvements
We identified some easy wins around our filtering and sorting options. This interface had grown cluttered, with a hierarchy that didn’t reflect actual, observable user desires. We could improve the sorting options by cleaning up the sidebar and sorting options.
Making Crucial Actions Easier to Find
Prior to introducing Selects, every Cinebody project had a “Shoot Status” that determined whether anyone could shoot new clips to it. With the introduction of Selects, we needed to add a way to control which clips, if any, could be seen by the public.
These settings have a lot of influence over a project. If a user doesn’t understand that they have to make the project’s Shoot Status “Active”, for example, they will likely be disappointed when no new clips have been shot for several days.
Shoot Status and Publish Status had been buried in a settings pane. This strategy caused a lot of jumping back and forth among users; in other words a loss of efficiency.
Feature Education
We also challenged ourselves to re-think our user education and on boarding strategy. Earlier feature releases had made it necessary to build in some on boarding flows for first-time users unfamiliar with Cinebody, as well as existing users seeing new features for the first time. Until now, we met this need by implementing bite-sized tours to walk users through the interface. And, after completing these tours, they disappeared forever.
You can probably see the problem with this approach. By front-loading all the education and then dismissing it forever, we had made it far too easy to forget about important feature details. With the Selects feature around the corner, now seemed an appropriate time to figure out a better way to introduce users to new features in general.
Solutions
Improvements to sorting and filtering were some of the easiest wins. The goal was to reevaluate the hierarchy based on how real users were interacting with the platform.
The addition of an icon to the sidebar communicates its purpose more quickly. The less often used “Notify Team” button was made smaller and placed closer to “Teammate” filters. We found that Shot Lists weren’t often being edited after their creation, and made the “Edit Shot List” button into a simple icon. The icon button added to the sorting options enables users to toggle between chronological and reverse-chronological sorting of the clips shown below it.
Making important actions easier to find was another important improvement to introduce as soon as possible. Again, because we were introducing more complexity with a new feature, we had a responsibility to make things easier for the user. We arrived at the conclusion that there are two key actions, and one important piece of information for any Cinebody project.
Shoot status is crucial, because it affects whether filmers can shoot to a project or not. Publish status, as mentioned, is critical, because it affects what the public can see. Finally, the public join code allows participants outside of the team that owns the project to join it. Users shouldn’t have to dig for such a key piece of information.
In terms of on-boarding, the biggest problem was communication. We needed the platform to explain to users what these new features were doing.
For example, a user could misinterpret the function of the ‘thumbs down’ button. We also needed to explain how the approval process differs for clips and edits; for edits, approval generates a public video page, while for clips, approval acts more like a label.
To improve communication, we nixed the tour strategy. Instead, we opted for an approach that contextualizes information when it’s pertinent to a user’s goals.
When a user takes an action for the first time, an interstitial modal displays a little bit more information. From here, they can learn more on an external FAQ page. The interstitial will return every time the user takes that action, unless they select the “Don’t Show Again” option.
It was important as part of the Selects feature to introduce controls over the visibility of a project’s clips. Any project in Cinebody can be public or private. The team that owns a project may want none, some, or all of the clips to be visible to the public. To communicate the relationship between Publish Status and Selects, we adopted a strategy of progressive disclosure.
The project’s privacy settings are sparse by default, but interactions reveal more information, little by little.
It’s easy to ignore communication details such as these. They aren’t the most exciting problems to solve, but there is some real value to a solid solution. An interface that communicates well saves time by providing relief to the customer support team, who would otherwise have to explain the same things ad nauseam.
Takeaways
Ultimately, our experience with Cinebody Selects was an exercise in managing “scope-creep”: How could we roll out some much-needed improvements with a new (but unrelated) feature, without breaking our deadlines or our customer support team? It’s easy to dream big, but much more difficult to keep things sane and realistic, while providing value to users.
As a side-note, while designing Cinebody Selects, we discovered a useful process-related solve for managing scope-creep during the design phase. Instead of starting from scratch without limitations, we used screenshots of the live platform as our jumping off point.
The problem with a blank slate is that it’s easy to propose nit-picky changes that inflate development timelines without realizing it. Working with screenshots is a pain. You have to mask them, make duplicates, rearrange masks, and you can’t edit little details like color and font size. The screenshot-first approach adds some friction that makes scope-creep less likely. Coupling this difficulty with a tight timeline forced us to focus on adding the right amount of changes.
Starting with the constraints of the existing product also helped keep expectations realistic. Of course, we still captured great ideas for more sweeping changes in the next major version.
