Over the past few weeks, I’ve been thinking and talking a lot about supporting contribution to design systems.
I’ve started reflecting on some of the ways that my thinking has changed over the past year or so.
While I still believe that allowing a design system’s users to contribute to it is critical, my beliefs about why that’s the case, and how to do it effectively, have evolved.
Here are 5 important lessons I’ve learned about enabling contribution.
1. Get comfortable with some multiplication of effort
We often talk about teams solving the same problems in silos as one of the problems a design system will fix.
As soon as there’s a centralised pattern, multiplication of effort can cease, and we’ll reach that desired state of optimum efficiency.
But if we’re not careful, contribution can become a kind of race to the finish line, and there’s a danger in trying to reach that end point too early.
Firstly, there is some value in multiplication. If 3 teams arrive at the same solution, independently of each other, that’s useful information. Likewise, if one team’s design is demonstrably more effective than another, that’s worth knowing.
In The Problem with Patterns, Cathy Dutton warns that “patterns should never sacrifice user context for efficiency and consistency”.
If we don’t make space and time for contextual design to happen, we won’t be able to create a sufficiently flexible pattern.
Trying to unify design within a pattern, before we’ve really understood the contextual variation it needs is risky, as illustrated by this slightly crude but fitting example I recently spotted on Twitter, in which the same design is used on both a bottle of cooking spray and a bottle of insect killer.
At some point, we have to make these findings open so that we can consolidate them into a single pattern, but we shouldn’t rush this step.
We have to diverge before we can converge, or we risk creating a solution that’s too constraining to be useful.
2. Don’t compromise on quality to make contribution easier
When thinking about how to help people contribute to a design system, it’s easy to start thinking exclusively about what contributors need.
Focusing on making it easy to contribute might point us to things like relaxing our standards and lowering the bar on quality—allowing things to be published before they’re really ready, to reduce the burden on contributors.
But we have to balance our contributors’ needs with the needs of our system’s users. For users of a design system, we need to provide clear, reliable and evidence-based patterns.
Publishing patterns when they’re not ready enough makes it more likely they’ll need to be changed in the short to medium term future. This creates instability.
If we’re constantly imposing updates on our users, we’ll start to lose trust, which is likely to impact adoption. And if people don’t use the system, it’s unlikely anyone will want to contribute to it anyway.
So, although we have to support contributors, we mustn’t do it at the expense of holding patterns to the standards our users need.
Making our standards open and clear, having a solid quality assurance framework, and providing hands-on support, is a more responsible way to support contributors, whilst still prioritising users’ needs.
3. Be inclusive and help the unlikely contributors
To be able to contribute to an open source project like a design system, people need time, confidence, motivation and permission.
If we wait passively for contributors to approach us, it’s likely that only the people with all of these things will do so—and that will influence our decisions.
Early contributors will be the people we’ll learn from, who’ll tell us which bits of our process are working, and what needs to change.
So if our early contributors are already well-equipped to contribute, and we optimise our contribution model for those people, then we’re only making it work for a privileged few. This is problematic.
If the community of people helping to grow the design system isn’t representative, the design system isn’t going to be representative either.
In her brilliant talk on fostering participation in design systems, Inayaili De León stresses the importance of “listening to the quiet ones”, and making safe spaces for everyone to share their ideas.
We have to do active work to lower barriers and build capability, with particular focus on those who might find it harder to contribute.
Because ultimately, we can’t create a design system that works for our whole community of users, unless the whole community helps to build it.
4. Accept that no one cares that much about contributing to your design system
I often talk to teams who are struggling to get contribution off the ground.
They’ve documented their conventions and processes, they’ve created shiny new guides on how to contribute, they’ve given people their email, invited them to design crits and even told them where they sit.
But despite their best efforts, hardly anyone is contributing, and when they do, there are big gaps to fill: Patterns arrive missing documentation, or haven’t been tested in user research, even though the contribution guidelines clearly stipulate these things.
As far as I can tell, this is a universal problem in design system land, and I think it comes down to one hard truth: No one cares that much about contributing to our design systems.
And that’s OK.
Those of us working on design systems are paid—or at least permitted within our paid roles—to work on our design systems. Our contributors are not.
Working on a design system is complicated and requires presence and sustained involvement to get it right.
It’s unrealistic to expect those working in other teams to hold contributing to our design system at the forefront of their minds, or to submit a textbook pattern when they do.
We can and should work to empower contributors with hands-on support and transparency around our conventions but in the end, it’s our responsibility to provide patterns—it’s not theirs.
Repeatedly reminding teams to contribute, going out and pattern hunting, and doing a significant amount of hand-holding is part of the job, and it probably always will be.
This might seem disheartening, but there’s another way to look at it: if working in silos is a default behaviour for teams within our organisation, then any contribution can and should be considered a big success.
If people are trying to contribute at all, you’ve done something seriously right.
5. Contribution doesn’t make things faster—it makes things representative
When making the case for supporting contribution, we often talk about about how it’ll help us to scale a design system faster. But in my experience, that’s not really true, and I’m yet to meet a team who’ve found it to be the case. (Though if you have, please drop me an email and tell me your secrets!)
Creating patterns is hard. It takes time. And that time has to come from somewhere, whether it’s from the central design system team or contributors.
There’s inherent complexity in making reusable patterns that work as part of a system.
It’s only through working on a design system over a period of time that we start to get good at navigating that complexity, so it’s unrealistic to expect external contributors to have that same capability.
As I said earlier, we can’t relax our standards just to make contributing easier, so time spent helping contributors meet those standards needs to be part of the equation.
In my experience, it usually takes longer to help an external contributor to produce a pattern than it does for the core design system team to do it themselves.
It’s unlikely then, that supporting contribution is going to lead to faster growth. So we have to look for the value elsewhere. And in my view, the value to be had from supporting contribution to a design system, is making it representative.
Opening up a design system for contribution gives more people a seat at the table, and a chance to have a say.
Government design principle number 10, Make things open, it makes things better says:
“The more eyes there are on a service the better it gets - howlers are spotted, better alternatives are pointed out, the bar is raised.”
The same goes for patterns.
Teams who are using the system to build products are perfectly placed to ensure that patterns are going to work in those products.
Enabling contribution means patterns are valuable and representative, both for the design system’s users, and the users of the products it’s there to help build.
In conclusion
Supporting contribution is one of the most challenging aspects of managing a design system.
Progress can feel slow to non-existent, and the rewards we first envisioned may turn out to be fantasy.
Getting people to contribute and then supporting them through the process requires significant effort, and that effort has to be sustained over time.
But it’s an effort worth making. With input from a community of users, a system’s patterns become infinitely richer and more representative than they would otherwise be.
And I believe that prioritising contribution and representation—even at the expensive of short-term efficiency—is the key to a design system’s success.
Acknowledgements
Thank you to Ignacia Orellana for providing invaluable feedback on this article, and for her general expertise and wisdom on this subject, which have heavily influenced the lessons it contains.
And thank you to Adam Silver for insisting I wrote this down in the first place, and for taking the time to review it and make it better.