< Back to portfolio

Resonance Design System


Over the past several years, the product team at Vox Media has worked hard to build the best in class tools to serve its editorial needs. Historically these tools were built on a bespoke basis and within individual teams. As the number of brands, users, and needs of the tools grew a system was needed to implement a more efficient method of creating new tools and features.

To solve these needs we built an internal design system, Resonance, that consists of a flexible pattern library, thorough documentation, and a solid UX foundation to help implement the system on existing tools and lay the groundwork for new ones.

do we really need another design system?


There are a plentiful amount of thorough and flexible design systems out in the wild and before we started working on ours, we really had to ask ourselves if this was truly necessary. Could we borrow from an existing system or make do with components from one of our better tools? Was the effort of creating one from scratch worth it?

The short and long answer was yes.

  1. We weren’t just making a design system for one tool, we were making it for multiple. The set involved would also eventually be available to outside publishers as part of our Chorus Saas business. We needed a public identity that would be truly ours.

  2. While some of our tools were more developed than others, none carried a robust system that accounted for all the components and we unearthed during our audit. Other open source systems also carried the same issue.

  3. And finally, our toolset was projected to double over the next few years. To create dozens of new apps without a documented pattern library would be chaotic.


Where do we begin?


In order to make a system for our tools, we had to understand the function an depth of our tools. We started by doing an audit of every existing tool within the company to better understand the needs they were serving as well as the structure of their components. We also interviewed several editorial staff members from various teams on their day to day workflow. In our findings we unearthed over 50+ internal tools and 40+ external tools.

In interviews we looked to uncover:

  • What are the most important problems to solve?

  • What does a successful system look like?

  • What are some blockers that might interfere with success?

the process of making a component

Resonance 2 Copy 9b.png

Aside from visual identity and implementation, I found creating a component to be one of the most challenging parts. Each component had to be flexible enough to work across multiple applications while visually treading a thin line of not being super bespoke or generic. In order to tackle this I carefully designed each item in phases to allow for iterative changes along the way.

A sample component cycle went as follows:

  1. Audit
3. Variations
2. Base Design

4. Build
5. Implementation / Testing
6. Documentation

Color and Type


Defining a visual identity was an important part of bringing life to the system. Given that most of our apps are text heavy we had to account for colors and type that wouldn’t compete with common user tasks. Fonts were tested live in staging browsers so they could be tested within the environment. Each visual style was also tested for accessibility and contrast.

^ Living pattern library

^ Living pattern library

Documentation Site


All of the visual styles, UX practices, and components are documented on an internal site. Each page contains guidelines for designers and developers on usage, code, and a history log.

Resonance 6 Copy 5.png

Testing & Implementation

The first application to use Resonance was the Chorus Story editor. We integrated ourselves with the team temporarily so we could roll out the system as intended and test it thoroughly. We started iteratively with small steps such as swapping fonts and colors and then implemented each component one by one.

^ Before (left) &amp; After (right) Resonance application

^ Before (left) & After (right) Resonance application

Resonance 7 Copy 8.png

was the system effective?


After the successful implementation of the system on two major Chorus applications and three that are currently in testing, I’d say yes. I don’t believe a system is ever done because like applications they should always be growing but it’s been built in a way that is adaptable. Designers are able to spend more time on user experience than nitpicking visual styles and developers have a building block of components that don’t need to be re-engineered each time.

To make this system evolve over time we are currently working on establishing a governance system where other product members can contribute changes. Creating an animation library is also on the roadmap as a delightful addition as well as continually strengthening design and engineering roles.