Dueling design systems: content design systems reconsidered

Ask 10 content designers how they define a content design system and they’ll give you 10 different answers. There’s no clear definition and no standard set of sections or artifacts that it must contain. Many would say that it should contain content components (which themselves are often defined differently), or that it should include content guidelines tailored to design systems components. Some would say that terminology lists and taxonomy materials should be included. It may be easier to explain what it’s not, as all or most of those 10 content designers would likely agree that it needs to be more comprehensive than a style guide to truly merit the term “content design system.” In the words of the Mr. Bean character in Love Actually, a content design system is not just a style guide—it’s so much more!

That concept (style guide=basic; content design system=comprehensive) has led to many people (like myself!) wanting to frame their style guide projects as content design systems, if they go far enough beyond what we might think of as a basic style guide. And that makes sense, especially since UX folks who work on “systems” are often viewed as more strategic and systems thinking is becoming a hot skill that many content designers are developing. Content designers are tired of their design partners and leadership viewing their greatest strength as wordsmithing, and many of them want to be viewed more as designers and systems architects. What better way to do that than by creating a content design system?

There are other reasons why framing such a project as a content design system might seem useful as well. Language, like visual design, can often be broken down into atomic units (components and sub-components), and UI content is just as important to the interface as the visual design components it interacts with. Content design is design, as we’re so fond of saying, and it can be done more consistently at scale with a content design system. So if we’re going to the trouble of creating componentized content governance, why not give it a name that conveys its importance? And a name that may also elevate our field by emphasizing that like UX designers, we’re increasingly taking on more technical roles, making use of more complex systems, and in many cases spending less time on tasks that stakeholders may view as creative writing. This is a distinction that can have major ramifications in terms of the level of respect we receive from stakeholders and leadership, the ease with which we persuade design partners to adopt our guidelines, and sometimes even what we’re paid.

Now if you built a content design system that’s largely separate from your design system and you’re getting great adoption from your design partners, great! That’s pretty rare though, so what’s much more likely is that your team is struggling with adoption. More than ever, we really need our colleagues to embrace our content governance. Content creation is becoming increasingly democratized as AI enables more stakeholders to create UI content than ever before, and with less oversight from content designers in many cases. So content guidelines are becoming even more critical than ever as guardrails. Without all of our content creators using them, it's difficult to ensure that product content is backed up by research and a consistent set of standards.

If you really need your design partners to adopt your content patterns and guidelines, keeping them in a separate content design system isn’t ideal. Not only because it makes it more difficult to access them (they need to have the link), but also because needing to go somewhere for documentation that’s not the main design system adds an extra layer of effort and requires motivation. If they have to go to a document or site owned exclusively by the content design team, it gives them more leverage to dismiss it as a “content thing.” Including your content guidelines and patterns in the main design system doesn’t guarantee adoption, but it’s far more likely if “Content” is just another section like “Foundations” or “Components.” It’s an established principle of systems that it’s far easier to get people to use something that’s part of a system they already use regularly, so hitch your wagon to the design system they’re already using. Also, think about it—if someone came to you requesting that you adopt new guidelines in your work, would you rather learn from something called a “guide” or a “system”? Learning a new system sounds like a far more intimidating proposition than using a guide.

When writing about content design systems, I would often wonder what the best term was for the main design system. I needed a term to use to differentiate it from a content design system. “A visual design system”? “The main design system”? Now I realize that part of that taxonomic difficulty stems from the awkwardness of thinking of a content design system as a separate design system that sits parallel to the other one. That creates a situation in which there are dueling design systems, like Thunderdome. And that’s not a situation that lends itself to great adoption of content guidelines and patterns.

Now it can be easier said than done to fully integrate your content guidelines into the design system. While many design system teams are eager to embrace content design, many are still more interested in protecting their turf. There’s a lot of possible reasons for this—not wanting to lose control of their system, limited resources to support expansion, not thinking of content design as “real” design or as something that follows atomic principles—but it can result in design system teams being reticent to work too closely with content designers.

I love this quote from Nathan Curtis’ article Documenting Components: Serve a System’s Audiences with Well-Architected Content:

“The arc of design systems bends towards collaboration across disciplines not limited to designers and engineers. If you intend to scale, advocate for content that serves a widening audience.”

Design systems were already becoming more interdisciplinary and cross-functional even several years ago, but especially now as UX design becomes ever more infused with AI, one of the marks of a mature design system is increasingly becoming that it incorporates content from (and intended for) more than just UX designers. In some cases the best we can do is emphasize to our design system teams that in order to become more mature and innovative, there’s really no way around the fact that they need to incorporate content patterns and guidelines. Or in some cases in which they already do, that they should do so in a more comprehensive and sophisticated way. If your design system is not interested in working with you to integrate content guidelines, calling your materials a content design system (if you think they’re comprehensive enough to merit the title) might not be a bad idea. It does raise the specter of “dueling design systems,” but that might actually be a point of leverage that helps convince them in the long run to join the right side of design system history.

If your design system team does want to work with you to incorporate content, think twice about saying that you want to add a “content design system” into their design system. Not only will that be confusing from a taxonomic perspective, but having “Content” be just a section like the others (“Foundations,” “Colors & Fonts,” “Patterns, “Components,” “Design for AI,” etc) will make it seem like it’s a fully integrated part of the design system. It’s often very effective to merge content guidelines and patterns that are specific to a certain component into the design system’s documentation for that component, but you will still need a content-centered section for the rest of the content guidelines. As far as what to call it, that will depend on your design system IA and taxonomy, but it could be something like “Content,” “Content Guide,” “Content Design,” or “Content Design Guide.” Though keep in mind that including the phrase “Content Design” could give the impression that it’s just for content designers. Calling it a “Content Style Guide” is a possibility, but “style guide” has an editorial ring to it, and design partners are often prone to dismissing style guides, thinking that they contain only “superficial” guidelines (like casing) and that a focus on style is subjective and not as important as other elements in designing an interface.

I don’t think we should completely stop using the term “content design system”, but we need to be more intentional in how we use it. Calling your guidelines and patterns “a content design system” can be problematic, but using it as an adjective to identify a certain category of guidelines (“content design system documentation”) can be helpful as a way to distinguish it from visual design system documentation. Eventually though this distinction will likely become less and less relevant, as design systems become more and more powered by AI. When we’re using an AI assistant to find relevant design system documentation, or when a design system AI assistant reviews our designs and points out compliance issues, we’re not thinking about the design system’s IA, and distinctions between content design system materials and visual design system materials will increasingly blur and dissolve.