Teamwork makes the design work: Why your design system needs content strategy

The practice of designing digital products has shifted dramatically in the last 20 years. We’re no longer designing with static assets in a vacuum, and passing the baton for the next person to continue the sprint. We are working on large, cross-functional teams of designers, developers, UX writers, researchers, and accessibility consultants. To build great products, we need to run the race together, even if we’re each responsible for different parts of the process.

Like content strategists, designers are building complex systems, giving a common language to components and unifying the user experience across different platforms. How can we learn from each other’s respective disciplines and practices to create a natural workflow for managing the evolution of interfaces?

To build great products, we need to run the race together, even if we’re each responsible for different parts of the process.

Everyone thinks of content strategy differently, so I decided to look to an expert for a proper definition. And when I think of content strategy, I think of Kristina Halvorson. She wrote one of the first books on the subject, organizes Confab: the Content Strategy Conference, and she runs Brain Traffic, a leading content strategy agency. Brain Traffic defines content strategy as "guiding the creation, delivery, and governance of useful, usable content." They say, “As a practice, content strategy helps to define, prioritize, integrate, systematize, and measure content.”

Let's break down content strategy in terms of design systems

First, what is the content of a design system? The building blocks of a design system are components and, ideally, patterns, but oftentimes people confuse the two. I have sometimes used the words interchangeably, and I think we need to clarify exactly what we’re talking about when we say components and patterns. In Modular Web Design, Nathan Curtis describes components as “designed and built in code, ready for reuse by plopping in a sketch file or HTML page.” He describes patterns as abstract, principled guidance applied as you design and build.  More from Nathan on how Patterns ≠ Components.

What is an example of a component? Let's look at our smallest units and build from there. In a user interface, a component can be as simple as a button, a form input, a typography style, a color, an icon. We can then take small components and make bigger ones. Menus, cards, cells, headers, footers, etc. These, too, are also reusable chunks of UI.

Making systems out of reusable components

With the introduction of a multi-platform internet — internet on your phone, internet on your tablet, internet on your refrigerator — designers found themselves having to design digital products for multiple devices and viewports. We had to design components that would work in Safari on the new iPhone while still supporting older, smaller Android viewports.

At the same time that designers were figuring out how to deliver consistent design on multiple platforms, our content strategy friends were looking at how to deliver engaging content on multiple platforms.

During the rise of the responsive design era, when designers were figuring out how to deliver consistent design on multiple platforms, our content strategy friends also were looking at how to deliver engaging content on multiple platforms. Content strategists started working with more complex content management systems and having to model content for different platforms. One of the more well-known examples of this was NPR's use of the COPE (Create Once, Publish Everywhere) method in 2009.

The basic concept of COPE is that content producers are able to create content in one system and distribute it across multiple platforms and destinations. The main principles of this approach include:

• Build content management systems (CMS), not web publishing tools (WPT).
• Separate content from display.
• Ensure content modularity.
• Ensure content portability.

Designers borrow from these concepts to create systems of user interface components to support multiple designers working on one product. The first inception I saw of designers using the COPE method was when we designed UI using Photoshop and in the early days of Sketch, pre-Sketch 47. As designers, we put this into practice by collecting components in sticker sheets files in whatever design tool we happened to use. We could grab a component, copy and paste into the file, and build on top of it. But what would happen if you were a designer working with other designers and you wanted to update your component? That used to be a manual process that mostly meant recreating your files 🤪.

Once Sketch was widely adopted, we could finally stop designing interfaces in a photo editing app and use a faster vector-based Mac app. With the highly anticipated Libraries feature included in Sketch 47, designers could sync, share, and update Symbols, across all Sketch files using those symbols. Libraries allow designers to create their components once and distribute them to multiple files. Libraries have changed the way design teams work together and ensure the modularity and portability of design content.

Governance: Who’s in charge and what does that look like?

OK, so we have our components, but how do we manage those components over time? We establish a governance strategy! Content strategists were the first to use and understand the term “governance”: the long-term management of content. What does governance look like for designers in design systems? Good question.

Brad Frost, author of Atomic Design (which is required reading for anyone working within a design system), discusses governance for design systems in chapter 5, "Creating Maintainable Design Systems." Design systems need these 10 guidelines in order to exist, thrive, and evolve.

• Make it official.
• Make it adaptable.
• Make it maintainable.
• Make it cross-disciplinary.
• Make it approachable.
• Make it visible.
• Make it bigger.
• Make it context-agnostic.
• Make it contextual.
• Make it last.

While all of these guidelines are vital to a design system governance, I’m going to focus on making it adaptable and cross-disciplinary.

Designers and content strategists, adapting together

The most successful design systems I’ve seen are adaptable and flexible. Components exist to provide structure but should be flexible enough to allow for additions and changes. Teams will often choose one person per pod/squad/working group to be in charge of the components for the product or feature they are focusing on. I have also seen other teams create a group that is naturally interested in being involved in systems maintenance, and these groups often include a representative from the content team.

The most successful design systems I've seen are adaptable and flexible.

If we are structured in a cross-disciplinary way, can’t we just combine our design system with our content design system? Shouldn’t our content guidelines pair with the components that will serve as the vehicle for that content? I say yes.

Guidelines = teamwork!

A handful of design system teams have begun including content sections within their documentation sites. By doing this, they are defining so much more than just the voice and tone of content being written into the product UI. They are specifying naming rules. They’re helping people figure out what grammar and vocabulary to use. They also include content guidelines for each component, which helps understand what content to use for each specific context.

Because not every team has a dedicated content strategist, guidelines empower designers to take a first pass that can then be reviewed by their content partners before it goes out the door.

Design for each context — with your content writer, using content guidelines

One of the trickiest components I’ve seen is the header/subheader component. What happens if the header runs over one line? Do you go two lines for the header? Or do you cut off the copy and insert  an ellipsis? (IMO, please don’t use an ellipsis! That’s three characters you are giving away! And for what?) If you go two lines for the header, is that because you were working in a fixed-width container and, if so, is it OK for the container of the title and header to increase in height? How will this increase affect the layout of the rest of the screen?

Questions like these can come as unpleasant surprises late in the design if we haven’t worked with our content teams. Ideally designers, content strategists, and developers would have built components to allow for the different context of varying length headers. And the user will thank you for it.

Working with content strategists during product development only makes the product model stronger. Designers have come to recognize the importance of collaboration early and often with our engineering teams, and we have built systems around that process. It’s time to take advantage of similar opportunities to improve process by collaborating with our content folks and building them into our systems as well.

Want to learn more? Watch my Design Systems Are a Content Strategy presentation from Design & Content conference in July 2019 in Vancouver.