Designing for publishing tools

Whether it’s a simple feature update or a brand new application, the design of tools is complex. Chorus, the product I’ve worked on over the past few years, is an ecosystem of tools to support all facets of modern media, like story creation, asset management, analytics, and ads. Any change made to one tool affects another. Both user experience and designing for scale are at the forefront of every design decision we make.

Our most recent update to the platform this year was the launch of Chorus Video, a tool that allows users to upload, manage, and publish video content across various platforms such as Youtube and Facebook. Chorus Video was the second application to test and implement Resonance and required the design of entirely new workflows as well as refreshes to existing video functionalities. In this post I’ve highlighted key points that we remain mindful of when designing publishing tools.

1. Understand your user(s)

Unless a tool is created specifically for one person, chances are it serves a variety of users. Even if a tool only serves a single function, say ‘upload’ for example, it will still be encountered by different types of users. Understanding the variety of users, what their roles are, and how they work is crucial to managing any workflow.

For Chorus Video, we learned early that we have many different user roles, like producers and social media managers, and that each role managed a very specific function throughout the video creation process. This meant that most of our users wouldn’t be using the application in its entirety. A producer may check the dashboard for recent updates or start a video project, while a studio editor may come in halfway through a project just to upload a video file. A social media manager may access Chorus Video at the very end to copy a link or publish to YouTube.

Given the various roles, we had to be cognizant that there would be various points of entry throughout Chorus Video, and no single page should be designed without clear direction on how to navigate the application. Given the growth of video teams across Vox Media as well, being mindful that there would always be new users to the tool was also a design factor. Adding tooltips for further context, or clear input fields on video requirements, are some of the design choices that we made to provide clarity and keep information present.

2. Applying a design system

We were fortunate to have a design system in our toolkit to establish the visual guidelines of Chorus Video. Given that the visual identity of an application can itself be an entire project, the system saved us a ton of time and allowed us to focus more on product thinking and design, such as how each component would interact with one another, layout, and general user experience.

Another advantage of having a design system for Chorus is that it helps to unify the experience of all of our tools. If a user jumps from the Chorus story editor to uploading a video, they will not have to re-learn any behaviors or visual nuances. It also helps us prepare for a future where our tools merge and become part of the same application instead of living in different areas.

The more features and tools that use a system, the stronger it can be become. Design systems are only effective if they are being used, and they can only grow based on feedback from actual users.

3. Test, test, test

This is a given: if a tool isn’t tested with real users, you won’t get effective results. The timing of testing is important as well. Waiting until the very end of an almost built applications puts a tool at greater risk of problems being caught too late or users feeling limited with what they’ve been provided.

On Chorus Video, our goal was to test the application in various stages. After initial user research and stakeholder interviews, we began to share wireframes early to make sure the designs matched user needs. With the help of our wonderful user research team, we were able to summarize findings after each stage and create a relationship with users. This allowed the users to become comfortable sharing their ideas and feedback and it also allowed us to schedule testing more often.

When it comes to testing, we are always learning and evolving; there’s no one method that fits all. We recently experimented with creating a live, clickable prototype with unique links that allowed us to test in production. This is a major improvement from using static mocks or fake interactive prototypes, since the live prototype lets us observe how users interact with the application as a whole with both new and existing features (while not affecting any of our actual data).

4. Thinking about scale

It’s rare that a tool is ever “done.” Either an application dies out and can no longer be worked on or it’s merged with another. Tools are meant to grow—not just to serve company goals but also help users perform their tasks more effectively over time.

In every page and feature that we designed and built for Chorus Video, we thought about scale. Whether it was a dashboard or a form experience, thinking about how a design can evolve over time allows space to add further functionality without redesigning entirely.

The conversation around growth often begins prior to any design. As a team we discuss every feature that needs to be built and all the current and future use cases. This allows engineers to create durable development plans and designers to create buildable foundations. Thinking about scale doesn’t mean that you keep empty blocks throughout the tool that can be filled in over time. It means creating consistent patterns that your users don’t constantly have to re-learn, or making a table that looks just as good with three elements as it does with 15.

If a tool ever gets to the point where a component has to be redesigned, we think about an effective way to teach and communicate the change to users, as we never want to surprise or misguide them. This is a great example of where testing a new feature comes in handy because it teaches you how users react to something different and how to prepare for that.

5. Audit for accessibility

The importance of auditing for accessibility in our tools ties back to our values of making experiences easy and equal for everyone. Vox Product provides a helpful checklist of accessibility guidelines that anyone who is designing, building, or writing can go through. While most items can be caught early, others can show up in later stages such as testing or general user feedback, which is why it’s important to always be mindful of accessibility at every stage.

Two recent examples from our tools came up when establishing background colors and toggle styles. Since Chorus tools are usually very content heavy we try to only use color purposefully and use a neutral palette to create a bit of background depth. However, some of the backgrounds we had chosen were so light they began to blend in for some users, including our project manager who kept providing feedback on legibility on our tables due to his color blindness.

Another instance came up in the Chorus story editor around toggle styles that relied on color to indicate on and off states. Adding a check mark icon to the on state allowed us to better communicate the change through an additional indicator. Since our tools are beginning to use the same components and behaviors, any changes that are made to Resonance are swiftly communicated to designers and engineers so that they can use the latest and most effective version of the system.

---

The beauty of designing for tools is that there’s always an interesting challenge to solve. Whether it’s designing an upload experience or researching a better testing method, there are opportunities to grow your application in every corner. As with any project, the final secret to designing effective tools lies in collaboration. Making sure that designers are communicating often with engineers, researchers, PMs, and other team members ensures everything from technical to roadmap implications are being considered through the design process.

If you’re reading this post and come from an organization that designs tools, we’d love to hear how you ensure you’re making the best products. What has proven to be most effective, and what advice would you give designers and teams tackling tools?

You can reach me via @ramoved.

The launch of Chorus Video could not have been possible without Ed Clinton, Katie Kovalcin, Tessa Harmon, Michele Cynowicz, Kevin Coletta, Kyle Johnson, Greg MacWilliam, John Ratajczak, Miriam Nadler, Nicole Fenton, Nancy Seay, Max Martin, Gregg Bernstein, Mila Djordjevic, Katie O’Dowd and the rest of the publishing product team.