Before we begin

Depending on your design systems governance model, you’ll have a different relationship with contribution processes. The ones I will focus on in this article are around centralised and hybrid teams and, more specifically, major contributions.

What is a contribution?

Much in the same way the term contribution refers to giving back. A contribution to a design system is a way for those not directly responsible for the system to give back and evolve the system. This can include any number of things, including but not limited to — components, patterns and guidelines.

Why do we need them?

Contributions are an incredible way to get better insight into our product experiences, fill gaps and improve our product overall. This is because our product teams are the ones directly solving customer problems and improving experiences.

So, if something in our system doesn’t suit a team’s needs, a design system should never be a blocker, and it should become an opportunity for a product team to get their hands dirty and do what they do best: build, measure and learn. And why wouldn’t a design system team want all of that delicious learning contributed back?

Contribution sizes

Minor contributions

Minor contributions include updates to your guidance or small component or foundational changes. They’re usually one-dimensional and don’t have many touchpoints for updating.

Depending on your processes, these contributions usually start with a message on your #design-system channel or a contribution form request.

Once agreed upon, the contribution might come as a PR request for dev updates, a branch review in Figma for design or even an update to your guidance site. These are simple, easy to manage, and fairly lean.

Major contributions

Major contributions include large changes to existing components, new components, patterns or much bigger structural changes.

They’re a bit more complex as they require a lot more work, including cross-disciplinary changes with multiple touchpoints. They will likely also require additional research and exploration to get them to work in your system at scale.

Depending on your business, you may have an existing contribution process that you’ve mapped out that aligns your process with a contribution model for different contribution types.

But I need to ask — do you get many of them? And I might be putting my neck out with this one 🪓, but I’m going to guess the answer is —kind of, maybe, no?

So, why are major contributions so difficult?

Major contributions are difficult for a reason, and that’s because our design system processes are detailed and intricate for a reason.

We create the standards that trickle through the entire product. Everything we create must be easy to use, accessible, and documented — and that’s just the tip of the iceberg.

Therein lies the problem

We’re going about it in all the wrong ways. In all of my experiences, I’ve found that the one common denominator is that design system teams hold themselves to a much higher standard regarding their components and their system processes than anyone else (I even wrote a guide on it).

The second common thread is that we then encourage (lol, force) others to follow this same process and get frustrated when we get nothing (or very little) in return.

But what benefit is it to a product team to go through a lengthy process to get a component system ready? They’ve just done the work to get it into their part of the product. Adding it to a design system isn’t going to shift their metrics or aid their conversion rates. Unless, of course, you work in a federated model, and it’s part of your job.

So what reason does a product team have to contribute back, outside of maybe ‘aiding to the greater good of the company’, which, yes, is important, and some will do it. But let’s be honest, it isn’t their job, and the amount of hoops we ask them to jump through for us ultimately takes them away from what they do best — product development. Amy Hupe has an incredible article on why your contribution process is doomed to fail, which goes into more detail on this topic.

How can we do better?

There are many different ways in which we can go about contribution, and they will all be unique to your business.

But let’s consider the primary objective of contribution as our foundation. To gain knowledge from product teams in a way that allows us to evolve our systems.

Better integration into existing processes

I was recently inspired to go back to my UX for design systems thinking, and I thought to myself, why aren’t we meeting teams where they work with contributions? How can we integrate smoothly into their workflow whilst leveraging their findings and honouring our processes?

The problem with presenting a convoluted process upfront is that we hinder teams from even bothering. So, how might we encourage contributions in a lean way that doesn’t interfere with the existing product development process? I should probably lead with it will require give and take.

Centralised and hybrid teams, I’m looking at you. We have dedicated teams for a reason, and I know we can’t pick up every proposal, but that’s what prioritisation is for. We should be gathering insights and doing the design system dirty work from there, with or without them.

How do we then leverage existing workflows to seamlessly integrate into these processes and get some of this sweet, sweet knowledge back into the system for everyone else to use?

Lowering the barrier for major contributions

My thoughts on the contribution processes from the start have always been — review the system, if nothing really works, build it yourself, measure success, contribute back, and finally update the product implementation.

If we agree this model works, then we can start to unpack the problem child in this process — contributing back.

Lean contribution

I would like us to play with an idea — let’s throw away our lengthy contribution processes and tree diagrams entirely and start simple. With a contribution proposal template.And yes, I know that a lot of systems start their contribution with a proposal, but let’s continue on this thread.

The proposal template should include what it is, what problem it’s trying to solve, any research, what it looks like, how it functions, any usage rules, and how it measures up in product.

From here, your systems team assess the proposal’s impact, as well as defines prioritisation and next steps (you could also democratise this process by making proposals available for other teams to see and vote on).

Defining your next steps is where your experience becomes tailored to the proposal. This is where the design systems team takes the lead instead of your lengthy process being enforced. Your next steps should include terms of engagement and the team or person proposing either opting to become a stakeholder in the process or a partner to help implement the change.

This allows you to use your existing systems processes to implement changes without solely relying on another team to do the work — which is where problems start to occur.

While this doesn’t eliminate a process, it lowers that barrier for contributions, opens up more opportunities to learn more about what teams across your business are doing and allows you to gain all of the benefits from a contribution without creating a lengthy ‘why the fuck should I bother’ process.

A note to federated and lean hybrid teams

If you’re reliant on contributions, but product teams just aren’t giving back. Why not consider the lean contribution proposal coupled with democratised voting and prioritisation? This will allow everyone to come together and have a shared understanding of new ideas, as well as share their own opinions.

By building engagement around contributions and ideas, you increase the chances of work getting done. You‘ll likely also get some volunteers along the way.

I would love to hear from you! What contribution methods have worked for you? And what haven’t?