Content in Design Systems

I’ve spent a lot of time lately working with, thinking about, and studying the role of content in design systems, and I think I’ve discovered a pattern.

Three kinds of content

When accounting for content in design systems, I think we’re talking about three things: content in, for, and about the system.

Content IN design systems

Content in design systems guides system users and documents details of the system. This kind of content is most often shared on a design system’s website or internal documentation site, as well as in onboarding and training programs. I’ve also worked on systems that include component-specific guidance directly in the tool the designer is using (typically Figma).

The content that’s intrinsic to a design system includes:

• user documentation — detailed information and instructions on the principles that guide the system, how to use and contribute to it, how the component library is organized, style guidance, etc.
• developer documentation, including code snippets
• accessibility guidelines
• you could also argue (and Torrey Podmajersky would) that brand assets like logos, icons, and illustrations are also intrinsic design-system content

Content FOR design systems

Design systems are there for a reason — to create coherent, consistent experiences that help end users do a task or learn something. Content designers (whether or not they actually have that title) provide the content that guides end users through the experience. Content engineers and back-end developers provide the information that populates instances of the design with the specific substantive content that the end user needs.

The content that’s needed for a design system includes:

• UX content — UI strings, CTAs, error messages, etc. — that guides users through the experience
• substantive content that populates instances of the design with the information relevant to the specific experience — product details, article elements, etc.

Working with this kind of content creates some delightfully complex content-management challenges.

• UX and substantive content may be obtained from any number of sources — spreadsheets, Git repos, Figma frames, string-management tools like Ditto and Frontitude, headless CMSs, product information management systems (PIMs), etc. — so you may need to improve your organization’s content-orchestration capabilities.
• Since design is a process, you might be working with different resolutions of this kind of content at different stages. This could be anything from the dreaded lorem ipsum to low-resolution draft copy, from self-descriptive helper text to real or simulated instances of the actual content. The challenge here is to discover the best way to align your content resolution with your design partners’ needs and the expectations of your product and engineering colleagues.
• This content often needs to be localized and may sometimes be expressed in different brand voices or other context-specific language (platform-specific error messages, for example). This can look daunting at first, but applying content-modeling principles often reveals manageable solutions.

Content ABOUT design systems

Content about design systems captures the institutional learning and lore behind the system. In my experience, in most organizations this information exists in people’s heads or in team-level procedural documents. 

Content about a design system might include:

• onboarding and training program content
• governance documentation —  information about how to develop, maintain, and update the system
• release notes and similar information that documents the evolution of the system

After a few decades of watching this kind of knowledge slip from organizations’ grasp, I’m getting a little discouraged. Ever since I discovered Doug Engelbart’s proposals for collaborative knowledge work in the mid-1990s and the existence of the field of knowledge management shortly thereafter, I’ve been waiting for (and doing my best to model) better knowledge-capture and -sharing systems. It’s not hard to discover the need for this kind of content or to design ways to gather and use it. In my experience, it has been difficult to convey the value of such efforts to managers and executives with staffing and budgeting authority, so your best chance to improve here may be at the team level.

• • • • • • •

I’m not claiming that this is a definitive look at this topic. It may very well make sense for your organization to think about its design-system content in other ways, according to your unique work patterns. I just wanted to share this insight with you all. If you think about this stuff differently, I’d love to hear your take on the subject.

• • • • • • •

Designing and managing evidence-backed design-system content

Like any modern content program, design-system content should be intelligently designed (modeled, structured, semantically connected/connectable, etc.), managed in a CMS (possibly more than one), and supported across its span by UX research (both evaluative methods like usability testing and generative methods like user interviews).

• • • • • • •

If you need help with a design-system content project, please contact me. I’ve got some availability beginning in late May, and I can also make referrals to my network of design system content experts.

• • • • • • •