Design system communication is a two-way street. Establishing a strong communication strategy to get information from teams using the design system as well as provide the core team with information is critical for its success.
With a design system, you often have lots of people working on lots of different things, and over time you get design sprawl. Now imagine this sprawl across multiple government agencies, multiple programs, and multiple contracting teams. Throughout the lifecycle of a product, teams need clear ways to communicate successes, troubles, and improvements. They also need to be able to ask for support. The core design system team needs to ensure a mutual understanding for teams using the design system.
In the previous post in this series, my colleague John French talked about making design systems as small and flexible as possible. Building on that principle, successful design systems spread ownership, establish a common vocabulary, create feedback loops, and make it easy to contribute.
Spread ownership
Increasing the ownership outside the core design system team is important for establishing a culture of communication. Teams using the design system should understand that they are all in this together, and that common components, designs, and guidelines help bring individual applications to life.
Open lines of communication create a sense of community and give folks space to get involved and help grow the design system. Deeper and more meaningful collaboration also helps spread the ownership of the design system. Give folks outside the core design system team visibility into things like sprint planning and demos, and allow time for questions. This allows contributors to follow the progression of the design system and feel part of the project.
Let contributors know you’re listening. You can build a community around your design system by being active where your users are. Everyone who uses a design system should feel like they can contribute back and knows how to get started. If they don’t, they should know that the maintainers are there to help them with better documentation, responding to questions, or scheduling one-on-one time to help them move forward.
Establish a common vocabulary
How you talk about pieces of the design system is important. Establishing a common vocabulary helps teams communicate better, work more efficiently, and collaborate more easily. With a common vocabulary, teams can refer to items in the design system by names that will be understood across disciplines and products. For example, “we need to fix a bug on the Accordion” or “we need to add a Month Picker there.” Spend some time coming up with terms and definitions for your design system that work for the teams using the system, and then make sure to document them clearly and publicly.
Create feedback loops
Create places to have conversations about the design system. This allows anyone using the design system a voice and a way to participate in moving the design system forward. If you create multiple ways for folks to interact with the design system you’ll draw in a bigger audience. Establish mechanisms to collect feedback and share knowledge.
- A code repository — Make it public and encourage participation by creating clear guidelines for how to contribute.
- A general contact form — Allow folks who have questions, but are not ready to interact at a code repository level, a path to talk with the team.
- A forum or chat — Encourage people to ask for support from other users to help build a community.
- An AMA with the design system team — An open forum for direct questions makes the process more transparent.
- A recurring user survey — If you check in every once and a while you can capture unspoken pain points.
Make it easy to contribute
Contributing to a design system can be tough with pressing priorities, confusion on how to contribute, or a feeling that the contribution won’t be helpful. Make it clear that it’s a team effort. Without contribution back into a design system, the growth of systems slows tremendously. Making time for teams to contribute back is imperative for the sustainability of the system.
A great way to help folks contribute is to have a clear path for how to do that. For example, categorizing issues as help-wanted or good-first-issue gives new users a place to dig in if they’re looking to get involved but feel unsure of where to start.
We’ve heard from users of design systems that they don’t have time or don’t feel they have permission to contribute to the system. To help with ownership and participation from outside teams, maintainers can make it explicit from the outset that teams using the design system have a right and are encouraged to contribute. The health of the system depends on it. You could also go as far as stating in a contract or agreement that teams using a design system should regularly (each sprint, or once a month, whatever works for the team) contribute back to the system.
An interesting idea to help facilitate contribution could be to schedule blocks of time where users of the design system can co-work with the maintainers to help gather feedback. This process could also help the contribution process and establish a stronger sense of ownership among users. Another option is to hold a state-of-the-union-type meeting to talk about what the design system has been working on and make space for teams to talk about success, difficulties, and proposed updates.
Better communication for better design systems
Communication is a critical piece of the design system puzzle. If you keep communication in the open and be as transparent as possible you’ll help those interested in your design system figure out where you are, where you’re going, and how they can help. Spreading ownership of the design system will help strengthen contribution and collaboration. As your design system grows you’ll also build allies who can continue to evangelize and help spread the knowledge of the design system. Having a clear plan and process for communication will help you build this community and ensure your design system has staying power.
Read the rest of the Design Systems in Government series: Less can be more, Improving documentation for better collaboration, and When to start.
