Everyone – designer, developer, leader, anyone else – contends that contributions are essential to legitimize a design system. This sentiment is instinctual, a yearning for the transparency, empowerment, and fluid effectiveness of a seemingly open source venture.
Many will go so far as to say contributions are the primary reason a design system exists. To me, that takes things too far. You can build, support, and evolve a toolkit of visual style and UI components for a massive community without taking a single contribution. Not that you should, but you could.
Nevertheless, contributions are essential. But why are they essential? Turns out, there’s many reasons. This post explores eight themes from interviews and discussions over the years. Skill development, adaptation, inclusiveness, and alignment begin as honorable mentions. Deeper topics follow as ownership, representation and productivity. Ultimately, the article finishes in an unexpected yet encouraging place: advocacy.
Designing and coding systematically is a learned skill. Practitioners, grinding away feature after feature, concede convention to productivity in their own unrelenting iteration. Contributions offer exposure to building in a usually well-defined architecture. Individuals – promoted by their leads – can delight in an opportunity to build better in a new setting.
Design and tech leads pitch contribution as a learning opportunity, even for things as simple as a quick fix. When contributing to a system, a contributor must decompose details and organize optimally, noting how they name things while cogitating over coding conventions. Shortcuts don’t suffice. The activity spans into the soft art of collaboration too. Previously solitary habits are exposed to public critique, combing reviews, and quality standards usually exceeding their own team’s threshold of “good enough.”
For most, contribution opportunities are rare. Yet, tiny takeaways can ripple widely through an individual’s, team’s and community’s improved skills and shared practice.
Design systems earned the moniker “living style guide” early on for a reason. They aren’t a static, final solution but instead a toolkit evolving with the growing, shifting needs of an organization.
Contributions force a system to adapt over time. From the outside, teams creating different experiences need different things. As they change, a system must change with them.
Individuals matter. Many developer communities, and nearly every design community, aim to foster inclusive participation. “Feeling a part of a greater whole” and a “shared mission” are core values of how organizations get work done. Opinions matter, not just a core team’s but of everyone in a community. The design system plays a part, and contributing is a means to forge that feeling.
Note, too, that a contribution can spans many emotionally charged moments. Individuals take risks in pondering, preparing and proposing something everyone will see and share. Contributions expose individuals to critique, feedback, and hot takes not everyone is prepared for. As a result, design system must be a safe space giving voice to anyone and protecting everyone.
Siloes. Hierarchy. Lines of business. Developing digital experiences at scale separates us out of necessity. These verticals create focus yet localize coordination and collaboration. Designers and developers must be forgiven for working in small groups of only their most adjacent coworkers. A design systems cuts across those operations.
A design system is part of many rituals and connections required to have a healthy, functioning community. Critique, working groups, communities of practice; all are regular events convening collaborators to see, discuss, review and decide on items.
Without contributions, these activities feel quite one-way: a system core team broadcasting outputs to a community. Contributions redirect collaborative flow, both from contributor back to a core and across from one contributor to another. Quick wins on small, incremental enhancements blossom into larger alignment as more see, participate, and contribute over time.
Ever since I diagrammed models of central and federated participation, I’ve inquired in grouped discussions “Which group should make the system?” More respond with the open source-based mentality of the federated group. The sentiment is clear: “It must be by the people! It must come from everyone!”
People aren’t calling for a frenzied spray of contributions from everyone everywhere. Moreso, this sentiment arises out a sense of legitimacy, authority, and control. In interview after interview, respondents evoke this with the word ownership.
Everyone must have a stake in how a system changes. Teams won’t stick with a system that isn’t addressing their needs. If the system’s doing something wrong or not doing something that it should, and the door for changing it is closed, then the system is portrayed as illegitimate.
What I find compelling is that control doesn’t extend to doing the work themselves. The reality is that, for most systems, most or nearly all work is done by a central group. “Is it important that you contribute it?” yields a response “Actually, it’s just important that it is turned around quickly. I don’t care if I do it or they do it.” Adopters will happily focus on other, harder problems if the “easy stuff” of a system is done for them. Ownership, as it were, isn’t really about contribution. Instead, the context of contribution is a proxy for the power to affect change.
From the outside looking in, it can be difficult to see just how complex building a system actually is. Making features for a system takes time, and system programs must balance that pipeline of new features with fixing defects and building an architecture that endures. Things slow down with efforts in technical infrastructure, the higher quality, the widely stoked participation.
Even the largest system teams are making decisions on priorities that leave some features off the list, without the capacity to complete. Surely, contributions can fill those gaps and propel the system forward. Contributions are seen as the way to speed things up.
This is most evident in the smallest things. Small fixes and narrow enhancements are focused, have low impact on the codebase, and are easy to define, agree on and test.
Fixes, in particular, are where adopters are feeling pain. If the defect is glaring, it’s the productivity of their own mission that’s hampered. It’s not about unblocking the system per se, it’s about unblocking the productivity of the team adopting the system.
Adopting teams also need bigger things, too. The system team’s focus may be elsewhere, so the aspiring contributor sees their own effort as plugging the hole.
Adopters see that system team members are stretched thin. They value the work that the system team provides. Yet, they still need the work to get done in a timely manner.
Spreading the burden feels healthy, presuming to improve the output of an otherwise constrained program.
It’s difficult, then, for contributors to reconcile their additional work with still being a burden for system team members. In most setups, contributions of new features can be a distraction for a system team member focused on other things.
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
Truth is... new feature contributions do not reduce our workload and do not make our system produce more.
</div>
<div class="escom-pull-quote__attribution">
Many, many interviewed system leads
</div>
</div>
Contribution isn’t just designing, coding or documenting. It’s also testing and quality checks. It also planning, scoping and prioritizing, skills that may not be as refined for contributors not acclimated to a system context. It’s also coordinating critiques and reviews to ensure the new features are being made for everyone.
Coordinating always end up involving the system team. It takes time. That coordination drags time away from other tasks the system team had prioritized in the first place. If a design system wants to increase productivity through new feature and enhancement contributions, then coordinating contributions must be prioritized as a track of work to ensure those contributions flow well.
System team members have some of the best visibility into the work happening across the enterprise. Yet, it’s foolish to think a central group sees everything, let alone understands all the subtle forces at play across an experience. It’s product designers and developers on the front lines, working to solve customer problems on a daily basis, that bring that seasoned perspective.
The practice of contributions injects a much wider representation into the features and tools the system offers. Contributions bring new ideas, extending what a system team hasn’t seen or considered. Different patterns come into play, test and expand the work.
Fostering visibility and alignment contributes to a unified vision of an experience and how it’s architected technically. Contributions – with their openness, critique, reviews, and participation more generally – create an activity through which you can achieve that.
I’ll be honest: contributions are hard. Coordinating outside participation takes time. Ensuring everyone’s voice is heard involves opinions, and thus, feelings. Convincing skeptics they have a stake, are empowered and are listened to, takes effort.
A conversation with Amy Hupe, formerly with GOV.UK, gives me hope. Like so many of us, she aspired to a payoff of scaling system outputs. “We don’t have time to build everything! All these contributors will make it with us!” But her experience took her to a different place: scaled advocacy.
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
I strongly believe in the advocacy: once they contribute it, they sell it for you. We get #superadvocates.
</div>
<div class="escom-pull-quote__attribution">
Amy Hupe, GOV.UK Design System
</div>
</div>
By someone contributing something, they know the system better. They’ve touched how the system works, even if in some small, self-contained corner.
The focus on how a contributor changed warped how I’d always looked at contributions. That someone is now able to find things, pull a repository, run a test, write a guideline, or even write better CSS in their own project. Those are all positive outcomes for them. Someone feeling they have a stake is an outcome. Someone having made something valuable to many is an outcome. All these outcomes increase a contributor’s willingness and ability to advocate for system’s value when central team members aren’t present.
All of these reasons we do contributions – skill development, adaptability, representation, productivity, ownership, inclusiveness – impact people. Cumulatively, contributions change people in a manner beyond some isolated fix or even new component. Contributions change not just the system, but also the people that use it.
EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.