Everyone Is A Contributor

Everyone is a contributor. This includes the design system team. All work done on the design system should follow the same processes and mechanisms, regardless of who does it. Treating everyone equally, as a contributor, forces your design system to have very clear and stable contribution mechanisms and documentation. Anyone on any team should be able to contribute to the system by following same published mechanisms that the design system team follows.

Part of this is defining what those mechanisms and processes are for your team. Take creating a new component for example. What is the bar for adding a new component to the system? Is it decided by a group of people with no transparent criteria? Or is there an objective set of criteria that anyone could follow to decide if a component meets the bar or not. The criteria could be based on things like how many different features can use the component, if it exists in other systems, and does it solve a problem no other current components do. Granted, a truly objective set of criteria is practically impossible, but we can make the process more objective so that personal preference and subjectivity are minimized.

Once a component has been objectively approved to be built in the system, how do you create that component? Do you write the documentation for it first? Do you write a technical spec? How does it get approved and merged into the system? Having clear steps with approval mechanisms make it so that anyone on any team could build a component. Also, how do you prioritize the work? Do production bugs take precedence over new features? All of these decisions should be defined in a public area so that everyone can understand why things are the way the are. Defining the process for how decisions are made and work is done, even if they are not optimal, gives everyone the ability to discuss, critique and change them. You can’t discuss what isn’t defined. I’m using adding a new component just as an example, but these processes should be defined for any work on the system: new features, bug fixes, layouts, tokens, documentation, etc.

Just having the mechanisms in place is not enough, it really needs to be evangelized and marketed to the organization. People should feel comfortable and empowered to contribute. This might mean doing a “road show” where the design system team gives a presentation and Q&A to teams in the organization, or reaching out to people individually.

Transparency

Treating everyone like a contributor enables transparency and collective ownership in the system. A design system should not be a magical black box that only a cabal of designers and engineers work on. A design system should not be owned by the design system team, but rather managed by it. The entire organization owns the design system.

Without transparency and shared ownership an “us versus them” mentality can emerge. The design system team becomes the high court that makes all the decisions, and everyone else obeys them. Rather than ruling over the rest of the organization, turn it around. Be bottom up, not top down. Isha Kasliwal on the Twitch design system team put it like this:

We’re the janitors [of the design system], and we’re here to clean things up when they break. — Isha Kasliwal

A design system should work like a co-op: owned by everyone. Everyone helps steer the ship and make decisions. Not treating everyone like an equal owner, either implicitly or explicitly, breaks trust in the organization. Hiding decisions that have an effect on the entire organization, like what components are built or how they look, is not healthy.

Sustainability

In addition to building trust and transparency, taking a cooperative mindset creates a more sustainable system. It lowers the bus factor, which is a thought experiment meant to uncover the amount of risk in an organization due to capabilities and information not being shared across team members. If the design system team disappeared tomorrow, would there be an insurmountable burden left behind or are there mechanisms and documentation so that others can carry on. Or in a less permanent situation, if some design system team members were on vacation or sick, would everything grind to a halt? Would decisions get made differently while they are away? Both of these situations point to a lack of shared information and repeatable mechanisms.

design systems should be like the ship of Theseus — as their components change and are replaced, they should fundamentally remain the same vessel with the same purpose — Victoria Leontieva

This concept can be applied to the design system team as well. As people come and go, the team and the system should fundamentally remain the same.

Scale

The best way to scale, without throwing more people at a problem, is to empower others with the tools needed to not rely on a minority of people who can do the work. Design systems help organizations scale by giving teams tools to build interfaces efficiently, so it makes sense to bring that thinking of scale and efficiency back into the system.

Provide the tools and information to empower everyone to do the work. You could spend all your time helping people one-on-one, or create mechanisms and artifacts that help everyone. A design system team can either be a bottleneck where all decisions and work are done by a select few, or a catalyst spurring innovation and scale by empowering everyone.

Rebuttals

“But we are the experts! Other people don’t know how to build a great design system.”

If that really is the case, you have a great opportunity to educate your organization about your design system. If a design system doesn’t have published documentation on how and why it is created, you are telling everyone, “just trust us, we know what we are doing.” If this information is documented somewhere private, why not make it public? Not everyone will want to contribute, but we should be empowering everyone rather than creating walled gardens and silos.

“But that is too much work right now, it will be quicker if we just do everything.”

I will be honest, this is hard work, but in the end it will pay off tenfold. The same can be said for cultivating a thriving open source community. Maintaining an open source project is a lot of work, and without clear contribution guidelines you are stuck being the only one doing the work. But if you take the time to build a clear mission and guidelines, you will get some amazing work in return.

You don’t have to have all contribution guidelines and mechanisms in place right now, but you can work on them as the design system grows. If a contribution is requested that does not meet some expectation, take that as an opportunity to make explicit those guidelines or criteria. If someone has a question, make sure the answer is in a place that is easily accessible.

Success

One measure of success for a design system I don’t think is talked about enough is the quantity and quality of external contributions. Most measures of success are around coverage, adoption, and efficiency, which are all very useful. If you haven’t read Cristiano Rastelli’s article, Measuring the Impact of a Design System, do yourself a favor and read it now. The amount of contributions is also important because it shows maturity in the mechanisms of the system and ownership across the org. The more contributions from other teams means that more teams are bought in and working towards the same collective goal. If only the design system team contributes, it shows a lack of collective ownership and transparency.