Introducing Resonance

Over the past several years, the product team at Vox Media has worked hard to build the best in class tools to serve our editorial needs. These tools were historically built in separate teams, each building individual products. We realized that this solution wasn’t the best user experience possible, straining all of our teams to learn a variety of different tools with different interfaces and workflows. We knew that to in order to build the best experience and suite of tools possible, we had to have a design system powering all of our tools. To meet this goal, we created a team to audit, research, design, and engineer our internal design system, Resonance.

After nearly three years we are excited to share that we are nearing completion of two core applications on Chorus using and contributing to Resonance, with more teams onboarding soon. The road to get here has been a learning experience and we feel that our products and workflows are finally seeing the benefits of using a design system. We’re excited to share some of what we’ve learned.

Where did we start?

Given the depth of our tools we first wanted to understand how our users were utilizing them in their daily workflows. Just the story editor and video tool combined serve over a dozen different types of users, ranging from copy editors and freelancers to managers, and producers. We reached out to at least one person from each group and had them walk through their current workflows and any external tools they were using (Google Docs, Trello, etc). From this, we were able to understand the larger ecosystem of tools that are currently in flux and what we needed to prioritize in our work going forward.

After the interviews, we gathered almost 50 external and internal tools that were being used across product and editorial teams. We then conducted another audit where we carefully logged each component being used in the tools and then narrowed it down to a core set of approximately a dozen components based on frequency of usage. After the audit, we jumped right into exploring these in design.

What’s the foundation?

As any good builder will tell you, the foundation is the most important part. The foundational design work is what upholds the integrity of the rest of the system. Design had the luxury of being able to explore this work extensively, testing a wide range of options in a variety of products. For example, as we iterated on the color system in different application screens, we realized that our primary color (“Sky”) was too difficult to work with in many practical contexts and didn’t uphold one of our core visual principles of light, airy interfaces. Luckily, we had another color (“Jade”) in our system that served the primary contexts well, so we were able to adjust how the color system worked without altering the colors themselves. Likewise, our initial spacing scale did not work well in practical contexts for our front-end engineers. In the next iteration, we had design and engineering pair closely to determine a good, flexible scale that met the design needs that translated into numbers that worked well for our engineers to use. Now, having that shared spacing language that we both love to use has made future spacing work easy to implement for both designers and engineers.

Determining these foundational styles was a constant push and pull—too much color and visual details made the system too busy and distracting while the absence of it made it look stale and flat. Once these initial foundations were thoroughly vetted and established, it was important to continue to uphold the integrity of these systems in the future work. Now that we have our own user base of the design system to consider, we try to limit breaking foundational changes, as we know that is a pain point in the experience of using the system.

Resonance has 4 main foundational systems:

1. Color

We have a core set of 7 distinct colors, with 100-700 valued ranges for each. We have established primary and secondary color combinations, along with a set of neutrals. Some colors are assigned specific status meanings like success or error states. We document the informational meaning for each color and whether light or dark text is accessible against it.

2. Typography

Our typographic scale is based on a 1.067 ratio (Minor Second). Each type size increases incrementally by 1.067em. The initial base number was the most important step to get right, as every other value scales up or down from there. We worked with engineers to determine values for a typographic scale that not only look great together but are also numbers that work well in code.

3. Spacing

Our spacing scale is a nonlinear progression based on the unit of 4px. The spacing can be applied both at the micro and macro level—both within components themselves and in the spacing surrounding components.

4. Icons

Our designers tested out a variety of different icon libraries to find one that met our stylistic needs while also accounting for the variety of interface needs we had on our products. We landed on a library that has over 2,000 icons that has made adding icons a breeze.

After these foundations were implemented, it was much easier for us to consistently implement polished design details in our interfaces. The foundations are part of our shared vocabulary, and continue to be a language that designers and engineers can both speak to.

How was it validated?

Creating a system on its own is a rewarding experience, but it is only as good as how the teams ultimately end up using it. We started by importing over the foundational systems into our most robust product, the story editor. This is a product that thousands of our editorial colleagues use every day for their jobs, so we had to make the transition process as painless as possible. We converted the colors, fonts, and icons in the beginning to make our future component implementations easier while also reducing the cognitive burden to our users during this time.

As we implemented each component one by one, we needed to resolve discrepancies between what our products needed and what our components’ initial specs were. An example of this is when we implemented our “default” button style that has a transparent background. In isolation, the button worked well when we initially built it to spec, but when we implemented it on our applications, we realized we needed a version of this button that did not have padding so that the buttons could properly be aligned with other elements on the page. The team implementing this button for the first time resolved the issue by adding a “paddingless” attribute to the button component, and resolved this in Resonance before finally implementing it back in the consuming application.

This feedback loop of Resonance -> Consuming Application -> Resonance is one that served us well and will model how we work in the future. The implementation process will have its own post in the coming weeks, where we can dive into the details of this journey. The biggest takeaway from this process was to validate it in existing use cases as soon as possible. The insights we gained during this phase were invaluable.

Lessons learned

Our work on Resonance is only just beginning. We are excited to be in the position that we are in and look forward to growing and improving the system as we add more partners to Chorus. In the coming weeks we’ll share more specific posts about various topics we’ve encountered in the several years it has taken us to get to this point. The main takeaways are:

Systems emerge at the intersection of design and code

The actual system work began once our team became cross disciplinary. We had to set common goals for how we want our users to use it. How flexible should it be? How should we structure the CSS to achieve our design opinions? We had to document principles for using the system. What does it mean for an application’s design to be Resonance? What isn’t Resonance? We learned the importance of having a shared vocabulary so that we could speak the same language to build out the integrity of the system as a whole instead of a set of components What do we name a new component? How do we define attributes? It was only once we came together that a usable system emerged.

Validate in real use cases ASAP

It’s a delicate balance between having enough freedom to explore while also designing the best system for the constraints at hand. Knowing the constraints and finding the edge cases and pitfalls of individual components is an important step in the process. A design system is more than a set of components; it’s how they work together in real use cases.

Words matter

A design system needs words for it to effectively scale. Whether that is the structure of the documentation for an individual component, the name of an icon, or defining what a unique component is—words are at the heart of every design system as much as the colors or fonts are. Focusing on language early and often will continue to ensure that your teams are viewing the system in the same way.

---

Thanks to everyone who has contributed to Resonance over the past 3 years:

Mandy Brown
Gregg Bernstein
Dan Chilton
Michele Cynowicz
Holly Gressley
Kyle Johnson
Katie Kovalcin
Ramla Mahmood
Miriam Nadler
Katie O’Dowd
Matt Sullivan
And everyone who has provided invaluable feedback

Thank you to Yesenia Perez-Cruz and Nicole Zhu for their thoughtful edits.