Creating a new video syndication workflow

Summary: For this project, I was the design lead for a team responsible for the editor-facing part of Vox's CMS, Chorus. The current video upload and feed management tools, Chorus Video, were updated to account for new syndication features. The media team responsible for doing so was then able to do this work with minimal developer involvement, and have a new workflow that could be taught to new employees.

Background

Before this project, the process for syndication of videos was technically complicated and handled by requests to developers. There were multiple employees using Chorus Video, but one person managed the process of syndicating videos. The goal of this project was to update Chorus Video and create a workflow that could be self-serve for the employees responsible for video syndication content, and could be taught to others.

However, there were a few unique challenges to this project that weren’t on others that I had handled while at Vox:

• The new workflow would need to involve changes to multiple tools within the CMS.
• Those changes would involve legacy and updated codebases and front-end designs.
• The team assigned this work was a "new" team of engineers reassigned to focus on an expanded scope within the CMS, along with adding a new PM and designer (me).

I also had limited communication with the main stakeholder, and no contact with the new employees that would be using it. These things made the process of working on this project very iterative and gradual as well all learned about the business and user needs of the project, and technical complications that would push in conflict with our timeline.

Old pages

Process

While the overall process involved a lot of communication and level-setting about the project, the main things I did throughout the project was:

• Gathered information from stakeholders/users to understand the current workflow and needs, along with needs for new employees
• Created designs and prototypes for both the "current" and legacy parts of the CMS
• Worked with the PM and engineering to make decisions on what work could be done in time for launch
• Designed an MVP experience balancing business goals, user needs, and technical limitations

I started off with a review of the previous design work, and also took time to understand the workflow for the colleague currently responsible for video syndication, and their main asks for the project. I also reviewed the video CMS to better understand past design decisions made that were specific to video teams. I worked with the PM to understand the business needs around the project, and get information about video syndication since they had a line of contact with the main stakeholder/user. I collaborated with the engineers early on to understand what legacy code could be updated, and what design trade-offs would need to be made for an MVP.

Through talking with the PM and engineering, I accounted for the required actions and data needed to create a video syndication feed. I created with some initial screens to account for the most basic required steps and information needed: associating the media partners, Vox brands, and created video syndication feeds together. The new additions to the app were using the updated style guide, while existing screens in legacy code would remain until they could be updated.

Workflow map

Next, I started to break things down to understand the remaining open questions. Ultimately, I was working backwards, but through getting some initial ideas formed based on limited initial knowledge, I was able to form my guiding questions for the rest of the project:

• What data was required by the system to create a video syndication feed? in what order? and where would it go?
• How much of that information needed to be entered by people?
• How would this people know that information?
• What did people need to do with that information?

As we received this information, product management, design, and engineering prioritized tasks and workarounds based on 1) time, 2) the critical tasks that video employees would need, and 3) time. There was pressure from other stakeholders that were involved in video creating and distribution, including the CEO.

I worked with the PM to gather requirements and anticipate user needs, and accounted for more of the new workflows that would need to be added to the CMS. I created new mockups and user flows to account for needed changes and additions to the app, that would then be brought to stakeholders for review. Working with engineering educated me about how app settings would and would not be inherited throughout the app. We worked together to make compromises so that and duplicate entry from users could be reduced.

Data entry order

But from there, I also needed to account for that order would impact the entire workflow. I started to incorporate each of the steps, in appropriate order.

Other changes involved also accounting for how videos would be added to new feeds within the video upload workflow. This existed in the updated part of the app, so I made changes to the existing pages and flows based on the CMS’s style guide.

As new requirements came in from stakeholders to account for make workflows easier for creating syndication feeds by duplicating old ones. This involved more technical lift that ate into development time. It also required rethinking what information would need to be entered or changed in the process. As a team, we worked together to re-establish stakeholder/user needs, and prioritize work in relation to other business goals we had.

On top of that, we also found “hidden” parts of the application that stakeholders didn’t know about, but then also needed to be accounted for in this workflow. My concern as the designer was reducing cognitive load; I didn’t want video staff to juggle too much when they worked under tight deadlines with other complex workflows. So while some compromises were made that would have to be learned by users to account for the order of how video data needed to be entered, I also worked with engineering to figure out wherever there could be simple inheritance rules that would require no human intervention.

An example of no human intervention

End Result

Ultimately, there were not many visual changes, but many workflow changes. It went from a single person needing to make requests to engineering to manually create syndication feeds, sometimes taking days or weeks, to having the process happen as needed by a team of people that could copy feeds, create new feeds, and adding videos as they were created. The workflow was much smoother operationally. It wasn’t as intuitive as I would have wanted, but it was an MVP that was self-serve, teachable, and update-able. We ended up with:

• An updated workflow for generating and managing video syndication content that was used by new employees
• Reduced engineering time spent on specific asks regarding syndicated video
• An MVP update to the application with the right amount of improvements and first-round fixes that balanced business, user, and technical needs within the project timeframe
• A new team that learned how to work together effectively

Old pages

New pages

Personal reflection

This is an example of a common project I have, where there isn’t an “ideal” design process, and tradeoffs need to be made for the sake of deadlines, internal restrictions, etc. Looking back on this project, my thoughts are:

• I would have done more research, have direct contact with stakeholders, and do more discovery. Due to circumstances, I wasn’t able to do so here, but ideally I want to talk to people directly and set up an iterative feedback loop on designs to move more quickly and avoid wasting work. I would have also liked to do more research up-front to avoid the classic “oh and one more thing” phenomenon that can happen with stakeholder asks in the 11th hour.
• I learned more about the value of having strong relationships with product management. The PM on this project had to act as my eyes and ears, and we had an established trust and communication such that it could work out on this project. In the meanwhile, I could take up more slack on doing research on other projects.
• I learned how to work better with a newly formed team. A team learning a new codebase works differently. I also needed to account for the time for them to get adjusted and know how to answer my technical questions. There was a lot we discovered together through each conversation, and I needed to adjust designs accordingly.
• I learned the importance of understanding that there is what the system does and what a user does within a larger context. It’s not just a matter of pure simplification to reduce every action a user needs to do to reach their goal. Not all of the actions a user does corresponds with every needed system action. Users sometimes act as a bridge between systems. Getting an understanding of how an app works means accounting for what’s invisible to the user, and as a designer, having opinions on what those things should be, and accounting for any needed workarounds that may lead to a not-as-perfect experience, but is still a step in the right direction.