December 1, 2023

Design System Communication Strategies

The Question: Episode 4 Wrap-up

On Thursday, November 30 of 2023 we held the Episode 4 design system deep dive conversation as part of a series called The Question. Thanks for being part of it.

Review the FigJam file and the raw data from the Episode 4 deep dive. Major thanks to my friend and brilliant design system leader, Molly Covert, for co hosting this deep dive!

For the week’s question, I provided this context:

It’s become well understood that design system work is people and culture work. Because of this, one of the most important pieces of a holistic design system program is a communication strategy.

For the sake of today’s question, I’m defining a design system communication strategy as:

A program intended to spread or gather information throughout an organization about the past, present, and future of that organization’s design system(s).

This would include information about the evolution of the system (issues, features, releases, deprecations, etc), as well as more educational (“how to onboard to the DS”) or engaging (“what would be most valuable for you?”) communications.

With this context, I have two questions for you:

What groups are a regular part of your current design system communication strategy?

What are the core elements of your current design system communication strategy, and how would you change it if you had no constraints?

The Question was shared via email (to 172 people), on LinkedIn, and X and I received 43 responses this week.

The Answers

In answer to the first question, we had a wide range of responses.

In response to the question, “What groups are a regular part of your current design system communication strategy?”: a large majority of teams are including design, development, user experience, and product.

Molly pointed out how shocked she was to see “leadership” so low on the list with only about one third of respondents including their leaders in their communication strategy. However, we were both pleasantly surprised to see “content” folks included in almost half of the respondents.

What did we learn?

In the second question, I asked people to share about the core elements of their existing communication strategy. The answers had a lot of variety, but after looking through the qualitative responses, teams seemed to identify themselves as having either a very minimal communication strategy or a fairly robust communication strategy. Let’s take a look at some of the comments from each.

Minimal Design System Communication Strategies

Reading the responses from these folks, I could sense how spread thin some of these individuals were feeling. Here are a few quotes:

“…not really based on anything and we sporadically remind ourselves to keep communicating with the teams we support with our product”

“record demos at the end of sprints of new features and components in the library”

“a roadmap that is hosted in a public place where everyone can access it”

“mainly, we have a Slack channel and post in there”

“our DS site has a get started section with some guides, and a page for UI kit release notes”

After digging through this data, I identified a handful of fairly common practices these folks mentioned as core to their communication strategy:

documentation site
office hours
Slack/Teams channel
email/newsletter
publicly available roadmaps
release notes

There were also a couple answers that were hard to read—folks who are feeling undervalued by teams that are supposed to be true partners:

“other than weekly office hours, we don’t really have any core elements because leadership doesn’t currently value communication the same way it values components”

“we had a newsletter for a bit but it stalled because it was mandated by engineering to a design team without bandwidth to maintain”

This was a good reminder to me that communication tends to be de-prioritized on small teams in favor of shipping fixes or features. I understand this, but I’ve also seen really great components go unused without a plan to educate and engage with design system subscribers. It was hard to read about the situations these folks find themselves in.

Robust Design System Communication Strategies

The other side of the spectrum was encouraging to read. These folks have many elements to their communication strategies and they have an established cadence to their communications. Here are a few excerpts from their answers:

“a monthly newsletter detailing releases, roadmap, adoption and usage stats plus other general information that changes each month depending on what initiative is being run that month”

“quarterly events to showcase highlights from the previous quarter and a section in monthly business report”

“bi-weekly showcases, quarterly updates to leadership, quarterly planning with Product, Design, and Tech leaders”

“all-hands meetings, lunch and learns, monthly & quarterly email updates, slack champions channel (sponsor customers), general slack design systems channel (all customers)”

“monthly update, breaking changes, quarterly survey, participation in design reviews”

“one on ones with department heads every other week for 45 min…documenting feedback in detail is essential to continuous learning and avoiding repeat mistakes, it also creates collaborative learning not just for the product team but for everyone in the company”

“for new starters, we host 60 min remote, group on boarding sessions, which includes a set presentation, with a live demo and Q&A opportunity”

There were so many great examples of teams that are thinking strategically about how to communicate with their organizations. The kinds of common practices they identified included everything from the minimal list above with the addition of some other approaches:

usage statistics
on boarding processes
roadshows/showcases
educational workshops
review/observation sessions
surveys
advisory councils
town halls

These teams are genuinely trying all kinds of things to get their messages out.

The Discussion

After reviewing the data gathered, we had a lively conversation.

We agreed that we have to learn to speak the language of leadership—they can’t be left out of our communication strategy because a healthy system needs a balance of support from leaders and perceived value from ICs. One attendee shared how their past approach to setting OKR’s was very technical which made them hard for leaders to grasp. Now, they are establishing goals that are derived from the goals of their leadership so they can point back to this connection in their communication strategy. Another attendee called out that these goals should be prominent on the doc site.

There was a general agreement that in many corporate environments there have been previous failed attempts at a design system. For those of us working on systems in this context, we have to double down on earning trust with our subscribers in order to get past the baggage teams have from the history of systems. A solid communication strategy can be one part of building that trust back.

A good part of our conversation revolved around storytelling as a key part of a solid comm strategy for a design system. One attendee called it “an essential fourth part of the product trio” and shared that “it’s how we relate to the business.” Several folks agreed that storytelling was the best way to connect with our subscribers—especially if the stories we’re telling help folks understand why we’ve made the decisions we have. While that understanding of the past is powerful, another attendee shared how impactful storytelling can be in casting a vision of the future.

Hopes and Dreams

The second part of the second question asked people to share what they would change about their communication strategy if they had no constraints. Things got fun in this part of our conversation. Here are a few answers:

“an on boarding program aimed to tell about the past and history of the DS as well as the why it was built in the first place”

“I would host a regular conference like Apple’s WWDC to the organization to roll out all updates together with a concise and high quality message, providing a week of workshops to help teams update and onboard to the design system”

“a podcast interviewing a team using the Design System to help promote adoption”

“a design system bot would be awesome, who could answer any questions related to design system assets”

“I would make a very clear RACI chart for all DS work and decisions and use that RACI chart to inform the comms strategy within the working group and for those immediately affected”

“Listen less to executives and more to the product teams using the system”

“I would communicate through beautifully animated and funny/clever video reels”

“a microblog/social media feed with bite size animated content on hints and tips, interactive guides to demo the use of more complex components (like Figma presentations which demonstrate how to use their features), longer form video content to serve audiences who don’t like reading lots of text based documentation”

This is just a sampling. Suffice it to say, with no restraint, there would be some really fun communication strategies out there.

In Conclusion

It was hard for me to read answers that were so dramatically different. On one hand, knowing there are folks really struggling to get some basic communications to happen. While, on the other hand, teams are succeeding in very creative and consistent communication around their system.

If you’re struggling to put a basic design system communication strategy in place, start by defining the desired outcomes you have for your system. From there, you can consider what you’ll need to communicate to accomplish that. Then you can think about who needs to receive that information, in what form they expect communications, and how frequent that message should be shared. The FigJam file has an example of this, so feel free to hop in there and check it out.