Contribution keeps the lights on đź’ˇ
Healthy design systems are built on contribution, which can take many forms. Building a governance process enables an organization to link arms in creating and tuning a toolkit that has deep impacts on culture and speed.
Design systems exist to document decisions
Design tokens are visual styling decisions reduced to their simplest form: a key (or name) and a value (like a hex code or pixel number). And in a similar approach, design systems are an effort to simplify organizational decisions and connect them together in one place so they can be applied at scale, consistently.
Many times, the output of a design system is a component library for designers and developers to build with. But design systems go further to document all types of best practices for assembling digital experiences. Each design system should look a little different because they document the set of decisions most important to a specific organization.
“Design systems are any set of decisions governed across the organization.”
(Hayley Hughes, Trust Between Teams, Config 2022)
All of the documentation, libraries, coding tools and template files serve as a how-to book for building. They also serve as a how-not-to book. If an organization decides their buttons should never wiggle on hover, that should be built in to the system. From then on, product teams don’t need to question that type of motion on hover, and their one decision-cost closer to dedicating their focus on the user.
Design system teams exist to make decisions?
But where do those decisions come from? Do design system teams get to make the rules and enforce them too? Do we get a sheriff’s badge to wear while we tell people how to use a badge component? Are we the only people in world who genuinely enjoy component jargon cringy puns?
Some teams might operate like that. Some organizations might need a force for consistency to get their products on a level playing field. But for my own team, this is not the reality. It also sounds like a very pressurized way to operate.
From my perspective, the decisions documented in a design system should come from the product teams using the system. It’s a cycle of adoption, daily use, and contribution. Those contributions get applied to the design system’s standards, and the contributing product team is back to adoption which could look like updating a component version number or applying a new theme.
Contribution defined
The definition of contribution varies depending on who you ask. Some (like Nathan Curtis) define contribution as only the things that are tangible (bugs squashed, code enhanced, features introduced). Others (like the Carbon Design System) define contribution more broadly to include feedback, all forms of engagement, and new tools. I find myself agreeing with the latter, but with a caveat — big contributions deserve big thanks.
In our onboarding materials, we define contributions as Tangible and Supportive. Tangible contributions include new components, documentation, code and tools. Supportive contributions include what Nathan Curtis would define as participation. I agree that this is participation, but the value we gain from that participation directly impacts our system, so I see it as a contribution. A small one, but still a behavior that we need to encourage.
Tangible contributions directly build up the resources our consuming product teams need to do their jobs. But supportive contributions shape many of the organizational decisions crucial to shaping an effective design system in an organization.
Supportive contribution also helps our centralized team structure scale. By encouraging designers outside our team to ask and even answer questions, we grow systems thinking across the org and gain back time spent on support tasks. By empowering more folks to teach others about our system, adoption can grow faster. We want to teach the village to fish. Eventually they’ll show us how to make better nets.
The scale of contribution recognition
If a broader definition of contribution makes sense in your org, please note that it’s important to recognize big contributions in big ways. If asking a question gets the same reward as delivering a full functional component, motivation at the higher side of effort decreases. Small contribution should get a high five. Large contribution should be celebrated.
One way to think about the scale of recognition can be thinking about a user journey from a designer or developer’s perspective. Each time someone goes through the cycle of adoption (adoption > daily use > contribution), the quality of the contribution should grow. First time through, the teammate applies the system and asks clarifying questions to apply it in the right way. Second time around, they might catch a bug and report it. Third time, they might branch a Figma component and fix an auto layout issue. Fourth, they’ve created a new variant of a component and they’d like to propose an addition. And on and on. As they go around the cycle, they get closer and closer to adding directly to the system in bigger ways. They learn the methods and logic of the system over time. This is the dream of community models.
Governance — it’s not a dirty word
When I first joined, I wanted to keep this term at arm’s length. Then I realized governance is the key to enabling teams outside the design system team to impact the tools they’ll end up using on a daily basis.
The governance model we’ve been working to define within my team creates guidance and tools for teams to contribute in all the ways. Similar to policies within local governments, governance exists to establish and maintain a healthy community. We work to formalize our shared mindset so teams know when to create new things and when not to. It’s all about saving time and focusing on the right problems. Sharp focus is extra important in this time of constraint. Teams are shrinking and being asked to move faster, so we need to set teams up for success with less run around for approvals and feedback. Governance clarifies the process and reduces the guesswork in creating on top of a system.
Governance is the way to formalize system growth and give credit where it’s due. Lack of definition can lead to frustration for consuming teams, appearance of sluggishness on the design system team’s side, and decreased adoption and ownership across the org. Clear definition leads to momentum, community focus, and increased adoption and ownership (a.k.a. supercharging your design system).
Clear process and shared strategy makes it possible for consuming teams across an org to help maintain the shared libraries inside and around the design system. It’s all about breaking down the silos and increasing collaboration across the whole team so we can change a culture from apathy to engaged conversation.
“Anyone can be on your team as long as they get a blessing from their manager to spend some time helping.”
(Mikaila Weaver, Design Systems: Suriving Turbulent Times)
We’re all in this together 🎶
Sorry, couldn’t resist that one. Regardless of all factors (team structure, design system size or maturity, org size, designer/developer ratio, org culture), creating reusable things is a team sport. We need a community to adjust the nobs and help us create better and better tools. One team might be in charge of maintaining a core system, but that system is nothing without direct input from the community at large. Whether it looks like idea sharing or delivery of production-ready components, a system is only as good as the engagement around it. Like all products, systems need to solve true problems and connect with intended audience to be successful.
