Why Design System Education Matters
Design Systems aren't just tools—they're culture changers. Educating teams on how and why to use them is critical to shifting the way an organization builds, collaborates, and ships products.
Design system education engages everyone to be more thoughtful about the user's experience and representing the company’s brand. Too often, organizations prioritize delivering components over investing in education, assuming the system alone will speed up product development. But without guidance, teams are likely to repeat old patterns and make inconsistent or misaligned decisions. Education—and clear, evolving documentation—are what turn components into a cohesive, scalable practice.
An Efficient Comms strategy
In a world of constant pings, posts, and emails, getting the word out about design system updates takes more than just announcements—it takes intention. You’re not just sharing progress; you’re competing for attention.
An efficient communication strategy borrows from the Gary Vee method: create once, distribute everywhere. Record a single piece of content—then adapt it for blog posts, Slack messages, micro-shares, podcasts (or audioblogs), and presentations. I try to be efficient, not loud.
With a background in Creative Writing as well as Computer Education and Cognitive Systems—and time spent learning from expert teachers—I’ve seen how engaging content captures minds. Design system teams often find themselves stepping into the role of instructional designers. To land the message, we have to not just inform, but also educate and inspire.
Getting the word out
A snapshot walkthrough of my process in creating educational content via blogs and audioblogs and sharing with the audience.
Step one:
Write the blog post
I draft a clear, engaging written piece that informs about a specific area of the system and highlights considerations for improvement.
Step Two:
Record the reading
Using my sound production skills, I record myself reading the blog post and mix in pleasing sounds. Audioblogs are great for accessibility.
Step three:
Post everywhere
Finally, I share the content across various channels using templates I created for each. Channels include email and Slack.
Listen to a recording of the Design Systems podcast
Learning as much as teaching
When I start at an organization and typically before I start teaching what design systems are, I seek to learn about the people and the organization I’m bringing into the design system world. I do this in two distinct ways:
Customer insights — I send out a wide net survey to the whole organization, essentially asking what is your experience with design systems. In the results, I learn what they know and what I need to focus on for system education.
Customer interviews — While I’m onboarding with the organization, I’m also onboarding with the teams I support. I set up 1:1 meetings where I learn about each individual’s challenges and ask questions. I also encourage them to ask questions.
The insights I gain from these methods help me identify major problem areas, knowledge gaps, and opportunities for quick wins.
Measuring for impact
How I’ve capture insights for system education
Views — Measuring for reach and awareness
Reactions — Number of likes and emoji reactions
Comments — Captured as sentiments
Survey — Directly and simply asking if the education content helpful to gain a CSAT or NPS score
Attendee count — Number of people for educational workshops
Confluence makes this easy by showing a blog post analytics. Similar with Zoom.
These sentiments and insights are captured in a quarterly or bi-annual report.
ABout Support and Governance
Snapshot of customers
Indeed Janus: 80 product designers, 100 product managers, 20 content designers, 30 design techologists, 40 UX engineers
Redfin Blueprint: 25 product designers, 35 product managers, 10 content designers, 1 design technologist, 60 software engineers
Remitly Tangram: (20 product designers, 1 design technologist, 3 content designers, 40 product managers, 120 software engineers)
My approach to governance
I don’t believe in playing “design police.” Instead, I see governance as more like air traffic control—guiding ideas, not shutting them down. The goal is to support passionate, engaged teams with great customer service.
When a request falls outside the system, I offer one of three responses:
A better, in-system alternative
A clear path forward (like testing with users before contributing a new component)
Or, if there’s no fit, a respectful: “That’s not on our roadmap at this time.” 😉
Support and educational programming I create
Blog (w/ audioblogs) [Audioblogs have been the favorite, short video messages with visual examples are a close second]
Working groups (for foundation or component audits)
Educational workshops and presentations
Design systems onboarding (for new hires, wayfinding, where to get help) (Download onboarding presentation — PDF)
Design system office hours
Support channels (on Slack and Jira)
Documentation as a system
-
Micro documentation
A golden rule of effective communication is meeting your audience where they are. Instead of forcing designers to jump back and forth between design files and a separate doc site, I bring the guidance to them with in-context hints, usage tips, and component notes right inside Figma.
-
Paired documentation with content
Something I’ll often do is pair system documentation with system updates. For example, if I’m writing about the color system in a blog, I’ll mention updates within the color system toward the middle or the end of the blog. I’ll make sure to mention it in tool changelogs or the docsite also. Repetition helps people retain information.
-
Source of truth documentation
A common issue with design systems is losing track of the source of truth—especially when parity between design files, documentation, and code starts to slip. Establishing and maintaining a single, reliable source of truth is essential for building trust in the system and keeping teams aligned.
