Supporting external contributions to our design system
A few thoughts on how we approach contributions to design systems – what works for us at Productboard, with a few ideas about the design system platform team in general.
A design system is shared ownership and responsibility – it doesn't belong to one person or team. Designers and engineers who are using the system should not just have a say in the design system's direction, but they should be actively building its parts. In other words – they should be active contributors.
To be clear here – I still think that every organization should have a dedicated design system platform team that governs a design system. The design system platform team should be empowered to make changes – so it needs designers, engineers, and a product manager. Other roles like writers or QA engineers should be there too, when it's essential or when an organization is large enough. There is a lot of foundational work that needs to be done, and without proper governance, a design system will eventually die. We all know how it usually works with side projects. 🤷♂️
So, what is the role of this design system platform team? One part is building key UI components, of course. But we believe that at least 50% of this team’s focus should be on scaling the platform around the design system. How? By supporting and nurturing the internal community, providing foundations, tooling, and domain knowledge.
But the question remains – how might we enable larger external contributions to the design system? To clarify, by “external contributions,” I mean contributions to a design system outside of the design systems platform team.
Let me share what works for us at Productboard quite well.
What’s our process then?
We closely monitor other teams’ roadmaps – to understand better what they will work on in the next quarter or two. When we have a list of upcoming projects, we use a slightly adjusted pilots scorecard by Superfriendly. This helps us to focus on projects that may have the most significant impact on the whole design system.
Starting with design – we set up regular pair-designing sessions with designers, and we attend their team design critiques. While we work together, we talk a lot about the system and how components from their designs fit the whole. Usually, one of the outputs of our closer collaboration is a new or adjusted component in our Figma UI kit, matching all the requirements we have for it – it has variants, it’s connected to tokens, it’s included in the sticker sheet. But what’s more important is that we also educate designers about how the system works, what should be there, how tokens work, etc.
When designs are ready, we create an RFC1 document for component API and behavior. We have a great company-wide approach to RFCs, so it was super easy to include design system components in this library too. We try to keep our component RFCs as lean as possible. Every RFC has design specs, API proposal (props + code example of use), and specific functionality or behavior description.
After the first quick iteration on RFC, we have a rough idea of how API should look like. Then, we surface this RFC also on our design system ambassadors2 sync, and we try to find someone there who would like to build this component. And because we know each team's roadmaps (remember the first bullet point?), we can even ask a specific team if the component fits well with their ongoing initiative. One of the biggest benefits of transparent discussion about component API is that it makes the contribution tangible – teams can take it and refine it during their refinement sessions and start working on it.
Everyone in the company has access to the RFC library, so everyone can comment if they feel they have something to add. Having all the discussions written in a single RFC document also documents our decisions. So, when we need to change the component API, we can back to this RFC and check why we decided on the API like this.
An important thing to mention – to remove as many barriers as we can, our frontend platform team created a script that automatically generates the correct file structure3. Besides that, we also have a document describing our code standards for design systems components (React part + how to write CSS styles).
When an engineer finishes the component implementation, the design systems platform team is pinged to review the PR. Our design systems engineers perform a code review here, trying to explain why behind their comments too. This is where design and API documentation review happens here as well.
Finally, when the component is released in code, we just go back to Figma and add the “⚛️ Available in React.” label to the component there, together with a link to the documentation. So it’s all connected.
This process may feel too complex and like a lot of additional work, but it helps us to scale our design system better. Yes, the work of the design systems platform team is heavily needed here (and our contribution process wouldn’t work without it), our product teams are a great partner to us when it comes to building or iterating on existing components. And slowly, person by person, we’re teaching product teams to think on a system level and onboard them into more regular contributions. And that’s what matters the most to us.
RFC = Request for Comments
Regular weekly meeting with dev representatives from each product team where we share the latest updates and answer design systems questions.
We use nx schematics for generating file structure for our components. Read more