Back in November 2023, I wrote a few words on contribution in design systems, and it sent me into a full-blown rabbit hole 🐇🕳️.

What started as a slightly frustrated reflection turned into a deeper exploration. I ended up co-hosting The Question, a systems-focused deep dive with the brilliant Ben Callahan, and it sparked some of the most thoughtful conversations I’ve ever had about systems work.

What surprised me most? How much it resonated with others. Clearly, I wasn’t the only one feeling the tension between how contribution is meant to work and how it actually plays out in reality.

Where it started

When I first wrote that piece, I was honestly annoyed. I’d worked on multiple design systems by then, and contribution was always painted as a core principle, something we wanted to encourage.

But in reality? The overhead of managing those contributions often outweighed the value they brought. They required so much hand-holding that by the end, the systems team might as well have done the work themselves. It made me question: What’s the point of documenting all this process if we still end up doing the heavy lifting?

So I proposed a new approach: one rooted in proposals and collaboration. An approach that balanced the systems team’s expertise with the domain knowledge of product teams. It was a step forward, but it still didn’t quite sit right.

A realisation that shifted everything

Since then, I’ve stepped back even further. And here’s what I’ve landed on:

You can’t define contribution until you truly understand what problem it’s solving in your organisation.

Contribution means different things depending on your business. Without identifying the underlying problem, whether it’s visibility, scalability, or something cultural, you risk designing a beautiful process that solves absolutely nothing.

So let’s dig into what that actually looks like.

Business needs first

Let’s say you’re working in a huge organisation with 80+ product teams. If you treat contribution like a catch-all and expect everyone to follow the same process, you’re setting yourself up for failure.

At that scale, it’s not just about getting people to contribute. It’s about creating visibility. Most systems teams don’t even know what half the org is working on, and it’s unreasonable to expect them to.

So maybe the goal isn’t contribution, but rather creating ways to surface upcoming needs. A lightweight feature request process can help you identify what teams are exploring, what’s worth standardising, and where your efforts will have the most impact.

In smaller orgs, it’s different. You might be better off skilling up your product designers and engineers to take on more systems work themselves, especially if your design systems team is tiny or part-time. But that shift requires cultural buy-in and clear support structures. Otherwise, you’ll end up with chaos disguised as collaboration.

Before defining your process, take a moment to pause. Look at the environment you’re in. Ask what contribution needs to achieve, and design around that.

Designing for inclusion starts with your system culture

I’ve come to really dislike space and science-themed names for design systems.

Before you come for me, I’ve worked on three of them and even named a couple of them myself: Sputnik, Orion Nebula, and Neptune. I was totally taken in by how cool these names were at the time, both as a sci-fi nerd and because I loved the idea of making them feel big and important, as we were selling them to the org as such.

But now? I see how those metaphors behind our naming conventions could have contributed to creating an unnecessary distance. They sound sleek and impressive, but also a bit elitist. Like you need a PhD in astrophysics to contribute or be part of the team. They reinforce this subtle idea that systems work is for the chosen few.

And it doesn’t stop at names. We do it with our language, our diagrams, our documentation, even our tokens. We say we want collaboration, but we make it intimidating, lengthy and exclusive, sometimes without realising it.

So how do we fix that?

Start by rethinking the way you frame your system by making it approachable and human. You don’t need to water it down, but you do need to meet people where they are. That includes writing shorter documentation, iteratively improving the UX of your components and tokens, opening up conversation channels, and being open to hard feedback that comes with it. We need to be inviting people in rather than pointing them to a wiki and hoping for the best.

Contribution is a behaviour. It grows when people feel comfortable, supported, and trusted.

Leadership buy-in (or the lack thereof)

Let’s talk incentives. Because one of the biggest blockers to contribution isn’t process, it’s priorities.

Most teams are judged by their impact on product delivery, not on how much they improve the design system. And if that’s how performance is measured, you can’t expect people to spend time contributing, especially when deadlines are tight.

If you’re trying to shift from a centralised model to a more cyclical one, your leadership needs to care. That starts by recognising systems work as real work and making space for it in people’s goals and roadmaps.

If full structural change isn’t possible yet, start small. Can you partner with a few interested teams? Give them credit for their contributions? Build the case with real impact stories?

System change starts with mindset change. You don’t always need a big reorg to get going.

Make it easy to share work

A systems team should never be a bottleneck. We’re not gatekeepers. We’re enablers. And that means making it easy for others to share what they’re doing, even if it’s messy or half-baked.

Not everything needs to be a polished component proposal. Some of the most valuable contributions come from simply observing what patterns are emerging in the wild.

So set up ways for people to show you their work:- Run open office hours- Host co-creation sessions- Accept screenshots or Loom walkthroughs as a starting point

The goal is to reduce friction, not introduce more forms to fill out.

Work with teams, not around them

When you collaborate directly with product teams, magic happens.

You learn their context and see what actually matters to them. In the process, you train them to view the system differently.

This doesn’t have to be time-consuming. It can be as simple as embedding someone for a sprint or doing a quick review and pairing session.

Over time, you’ll build trust. And they’ll start to see the system as theirs, not just yours.

Teach the why, not just the how

Design systems work isn’t just pushing pixels or refactoring code. It’s strategic, cross-cutting and nuanced.

And because of that, contributing to a system requires a different mindset.

So train for that. Run short workshops, share your principles, and explain why decisions were made the way they were. When people understand why the system works the way it does, they’re much more likely to make thoughtful contributions.

One last, slightly unrelated note

I nearly didn’t publish that original article.

I worried it was too opinionated. Too niche. Too… against the grain. I thought: What if I’m completely off-base? What if I get dragged for this?

But I hit publish anyway.

And I’m so glad I did, because what came back was alignment, curiosity, and collaboration. People reached out with their own ideas. Shared their struggles. Built on the thinking.

So here’s my reminder to you (and to myself):

Don’t let fear of being wrong stop you from sharing what you’re learning.

It’s how we grow and connect. Who knows, your thoughts, no matter how chaotic, might be the exact thing someone else needed to hear.