Communication plan for design system teams
One thing I’ve found very valuable for platform-level teams, including design system teams, is having a communication plan. One that describes topics, preferable level of detail, frequency of push/pull updates, and people/roles involved. Such a simple document can save a lot of frustration for the people involved in building a design system, be it core team, practitioners embedded in product teams, or managers.
When you see that the design systems work is not pacing with the rest of the org, one of the reasons might be that the communication is lossy.
Especially when you’re just starting out, and the whole thing is novel, and brute-forcing your way into access to the information to make the design system a success would mean sitting in meetings all day, and you’re looking for a better way. It’s tough!
Try debugging the situation down to the core, try to think about how communication happens.
Yeah, but why?
Communication — in general, throughput of information in the org, — is at the core of many errors that occur at the seams, between the teams. Design systems work requires a lot of coordination and communication happening between the core team and the rest of the organization.
The problem though?
You can’t just let it happen.
Especially in an org that hasn’t trained the platform work muscle enough, you might see that a lot of individuals and teams default to what has been working before. Defaults are fine, until they stop working. An organization that went from having 2 teams to 4 teams is gonna struggle a little with keeping everyone informed and high fan-in; make it anywhere more than 6 teams, and it’s gonna suffer hard. And unless either majority of the people in the org have enough mental resources to recognize that there’s a novel problem that needs a novel solution, or there’s a handful of apt leaders who can turn a change like that around, people will just push harder on defaults.
My favorite example is March 2020: people just replaced office interactions with video meetings, and these meetings began to flood people’s calendars. Communication remained important, but doing more of the same was a naïve — and pretty poor — answer to the problem of people suddenly not sitting next to each other in a room. The inertia was strong. It took a lot of effort for a lot of people to change things at least in their first circle of coworkers.
Defaults are good, but not all of them remain adequate to the situation.
You need a plan.
Sure, but how?
How do you come up with a communication plan? Same way as with any other plan!
- Evaluate existing communication channels and topics
- Use existing channels to pass relevant information
- Create missing channels to pass otherwise lost information
- Document the plan and start using it
Evaluate existing communication channels
Start with documenting all the communication channels that exist in the org.
There’s a lot of communication going on in the org. Even now, with lots of people in tech working remotely, the amount of communication is still huge. Where is it all happening?
There’s information which everyone is happy to tell you about. Then there’s information that you have to hustle for. Either might be relevant and important for the design systems work.
There’s structured and mostly automatically generated information: think reports in the task management tool the teams use. And there’s unstructured, “do you know whom I can talk to about this?” kind of information that people exchange in (virtual) hallways and ad-hoc chats.
Perhaps you already have an intuition, a sense of where to say what in the meetings you have on your calendar and your team members have on their calendars. And I bet you use Slack or something similar, and there’s a concept of channels, too, each of which is used by people to post some sort of information. Each channel has its implicit agenda, which puts boundaries on what types of information is relevant or not.
Remember to always be listening, but especially now: take some time, listen carefully, do the research.
Make time, together with the team, to write down all the channels that are there.
Then write down all the topics of communication that happens.
Finally, link the two sets together.
Add categories of people that follow specific topics and hang out close to specific channels.
This will help paint a clear picture of what kind of information is already being passed around easily.
Use existing channels to pass relevant information
Some of the channels you’ve written down are already being used to pass information around that is crucial for the success of the design system.
It might be a live meeting where all the designers are invited.
Might also be a newsletter that goes to all the engineers involved in UI development.
If the design system core team is active in those, too, — awesome! If not, you’ve got a gap to bridge.
If some information is not being published and discussed in one or more existing channels, and this information is relevant for those channels, the solution is to start posting. Some people will appreciate it, tell their colleagues, and you’ll be getting gradually more and more discussion going on in the channel.
Ideally, the range of topics and the level of detail should match the purpose of the channel. If it’s a live demo meeting scheduled for 30 minutes each week, it’s probably not the best idea to go into finest details. Although there should be a way for the participants to follow up, to go deeper into details if they need to.
Create missing channels to pass otherwise lost information
A design system team can’t be successful without continuously staying informed about what’s happening in the org, what’s happening to the product development.
Inbound requests is one of the ways to get a bit of time advantage for the core team and at least know things, if not do things, sooner. People might push back, and you’ll need to balance the amount of process with the convenience for the teams, and that’s gonna test your management skills. Still worth it.
Design system office hours is another one. This should best be used to pull information (people get asked questions) and reconcile it, and only occasionally push it.
All that said, in a mature organization, there’s usually a lot of communication channels for people to keep up with. Adding more will certainly create some pushback from most of the folks, because we all have only so much time in a day. A few things that worked for me were
- making it easy for people to join on a regular basis: picking convenient time and never generating follow-up work for participants (okay to use a different, existing channel for that though)
- making it fun and emotionally rewarding: praising people where appropriate (works best in live meetings and unprocessed recordings)
Document the plan and start using it
Most valuable part is the planning, not the plan.
That said, having an artifact might be useful, if the effort to keep it up to date is adequate. That said, you can either turn the effort down to the bare minimum, or you can turn the usefulness of the artifact up a bit. For example, whenever a new person joins the core team, this document can be used as an anchor in one of the onboarding steps, where you talk about communication. Or, whenever someone joins the broader org, and you run an onboarding session about the design system, use that doc to explain why communication is hard and how they can help. A good document is one that is used by lots of people, edited often, and stays up to date at all times. That’s what you want for the communication plan as well.
A good document reflects the agreement that people have in the most minimal form possible. If it’s a table of communication channels × topics × groups of people, and this table fits onto one iPad screen, this doesn’t tell us anything. But if it looks like that and helps the team ace the communication at all times, then it’s a win! If it’s turning into a lengthy, comprehensive cook book, you should consider putting more time into in-team training, alignment and (re-) staffing soon.
In the end, remember that having a communication plan is the first step, not the final step, but it’s easy to get overwhelmed, so you and the team need to start somewhere. Start small by giving the team the task of figuring out how to use existing communication channels (meetings, Slack channels, newsletters, demos, etc.) to address different groups of people, so that the team can minimize loss of context. Then gradually turn it up from there: add automation, set up metrics, adjust incentives, and continue fine-tuning.