Help team members understand the difference between a content strategist and a copywriter, which might be a role they’re more familiar with. One key part of your role is to emphasize that content strategists are strategic partners, and therefore should be included in early conversations about component taxonomy, website IA, system labels, or anything else that has to do with organizing or communicating about the system. Consider creating a What Is Content Strategy presentation. Take the time to explain how you support the development of content by establishing templates, structure, workshops and frameworks to facilitate subject matter experts in providing the information needed to support the design system.
Clarify goals of the system by interviewing stakeholders and teammates, both one-on-one and as a group. Ask a few of these basic questions: What does the phrase ‘design system’ mean to you? Why is it important for our team to invest in a design system? What are we trying to achieve? Speak to organization leadership, any stakeholders intimately involved in any previous version of the design system, or anyone with a strong opinion about the tool. Summarize your findings and present them back to the group. Ideally you’ll be able to align on top priorities for the team, as well as key value props you can communicate more broadly.
Reach out to design system contributors to understand their needs when it comes to the documentation process. For example, is there enough structure in place to support collaboration? What are the most common questions about the process? How can documentation be shared more effectively or broadly once it’s published? Are there ways your content can be modularized or repurposed? What types of training or workshops would be useful for documentation contributors?
As a design system matures, precision in communication and terminology will become more and more important. Does everyone on your team mean the same thing when they say “component” or “variation”? Do they understand the difference? Misalignment internally can be disastrous as you scale within your org. Host workshops and collaborative exercises to draft definitions together. Agree on who the decision maker will be ahead of time (as the content strategist, it should be you!). Capture intent with the group and refine the official definitions later to share out for feedback. As with all digital products, have the mindset of continuous iteration and improvement.
It’s often more efficient for designers or engineers to develop the first draft of documentation or component guidelines—people who build the components are truly the subject matter experts. Work with the team to include documentation and their point-of-view as a requirement for the build process. As the content strategist, your time is best spent in creating easy-to-use note-taking templates and playbooks that can be referenced throughout the component build process, and documentation templates that match the final format you’ll be uploading to your CMS. First drafts don’t have to be perfect—even bullet points from the team that built the component are better than learning a component from scratch just to write documentation.
Making updates to your component documentation strategy or format usually means making edits across dozens of pages. Ask Design and Engineering teams to recommend components that range from complicated to simple (understanding that complicated on the code side could mean simple for design assets, or vice versa), and use this group to test your new format. You’ll learn a lot about what is working globally and which types of components might be troublemakers. You’ll also be able to better estimate the lift of rolling this update out across the full library.