December 17, 2023

Fixing Design System Contribution

The Question: Episode 6 Wrap-up

On Thursday, December 14 of 2023 we held the Episode 6 design system deep dive conversation as part of a series called The Question. Thanks for being part of it.

Review the FigJam file, the raw data, and the opening tune (“Time” by Hans Zimmer) from the Episode 6 deep dive. Major thanks to my friend and design system leader, Ness Grixti, for co hosting this deep dive!

For the week’s question, I provided this context:

This week, we’re talking about contribution. One of our regulars (Hi, Ness!) has written a great piece explaining how the existing contribution models just don’t sit well with her. In her article, she explains that “a contribution to a design system is a way for those not directly responsible for the system to give back and evolve the system.” She goes on to explain that “this can include any number of things, including but not limited to—components, patterns and guidelines.”

With this as our shared understanding of what contribution is, Ness calls out that contributions exist on a spectrum. On one end there are minor contributions which don’t require a lot of work to integrate. On the other end, there are major contributions which often “require a lot more work, including cross-disciplinary changes with multiple touchpoints.”

With all of this as context, here is the week’s question:

How many MAJOR contributions do you get each month?

How might we encourage major contributions in a lean way that doesn’t interfere with the existing product development process? (Be creative—anything goes!)

The Question was shared via email (to 197 people), on LinkedIn, and X and I received 34 responses this week.

The Answers

In answer to the first question, over 60% of respondents reported receiving two or less major contributions each month:

In response to the question, “How many MAJOR contributions do you get each month?”: over 60% of respondents reported receiving two or less major contributions each month.

I genuinely wasn’t sure what to expect here. Some of the teams I’ve worked with rely heavily on contribution as a way to understand what is important to their subscribers while some have no desire to include the work of their subscribing teams.

In the second question I asked respondents to be creative in imagining how we might encourage a leaner contribution process that doesn’t get in the way of a subscribing team’s other goals. I’ll share some highlights from those answers below, but first, here’s an AI generated summary of the open text responses:

1. Collaborative Contribution Models: Strategies involve embedding designers into development teams and educating them about the design system to enable autonomous contributions. Regular reviews and integration of user feedback are advocated for.

2. Communication and Support: Encouraging contributions through celebration, integrating design system reviews into the product delivery process, and creating a conducive environment for contributors are highlighted.

3. Challenges and Barriers: Challenges such as differing recognition for contributions among engineering and design teams, as well as concerns about contribution efficacy, are acknowledged.

4. Structured Contribution Approaches: Suggestions include simplifying the submission process, setting minimum standards for contributions, and creating tracks for short and long-term contributions aligned with both product and system goals.

5. Diverse Contribution Methods: Exploring options like hackathons, design workshops, ambassador programs, and component registries to engage contributors and simplify the contribution process.

6. Balancing Expertise and Contribution: Balancing the expertise of the design system team while lowering barriers for others to contribute is considered crucial.

7. Iterative Contribution Process: Emphasizing an iterative process involving multiple phases - unblocking product design, abstracting for system-level integration, collaboration between system and product designers, and reintegration into the product.

8. Organizational Adaptation: Recognizing the need for adaptation within different organizational structures and maturity levels concerning design systems and their contribution models.

While this is pretty buzz-wordy, it does capture a lot of what we discussed. Good job, ChatGPT. :)

Selected Quotes

Here are a few quotes shared by folks striving to support a healthy contribution process with their design system:

“Part of getting contributions efficiently is not getting in the way of the work. Provide the contributors with the space to do what’s needed and allow them to reach out when they need it.”

“Let people do what they need to do. And figure out what impact a contribution will have before picking it up.”

By integrating user feedback to validate it before committing significant resources. Break it into smaller manageable chunks that can be gradually integrated into the existing system.”

“We’re thinking of creating a light weight development experience to contribute to a separate codebase for a”community” version of our components. This way our customers can share with each other in an unofficial (read, not supported) library and we can take the most used from this community edition into our official library.”

“Our organization is small, but built on being open source. Teams coming in and wanting to contribute is a normal part of how we work. We have intake processes that involve bug reports and places where they can prototype components and features just for their product areas. This allows them space to work and then space for us to catch them where they’re at when they’re ready for feedback.”

“Train design advocates that are responsible for external teams contributions so we can just do a final review and add to our lib”

“Work on turning product development stakeholders into primary users or consumers of the system. Find ways to position the system as a solution for their upcoming business objectives.”

“A full DS Sprint dedicated to a DS hackathon - where people can help solve their development problems instead of only outwardly focused business problems.”

“Three tiers:

• Top tier that is the full blown global design system.
• Middle tier that that is a product or team level system. These systems leverage components from the global system to build out other components and patterns that are specific to that team and product but not widely used outside of that team or product.
• Bottom tier would just be like a dump all shared library. A library where any design can put anything. It’s like a shared playground. No guidelines in this tier.”

“We are hoping to spin up a component registry-where folks can register and share the components/patterns/etc they have made themselves. These potential contributions would then be findable and viewable through a search function - a sort of market place. We can track the usage and determine if it should get elevated to the design system. We’re hoping this marketplace encourages more contribution in a variety of ways.”

“The design system team partners with a product team (or whoever is interested) for a sprint, and we create a component together.”

“If the org has the structure, or depending on the maturity of the design system, it could scale to a”component champion program” where small teams are spun up to contribute to the design system on a regular cadence. It’s lean in a way because it only allows the team two weeks to contribute to the system.”

There are some super-creative appraoches here. But the thing that most stuck out to me was the breadth of ideas. From almost no touch (“get out of the way of the work”) to high touch (“three tiers, component champion programs, etc.”). This hints at a topic we spent a LOT of time discussing: the acceptable approach for your system is going to depend heavilly on your culture. Contribution, perhaps more than a lot of other design system processes, is very dependent on culture. In other words, the contribution processes that emerge in each organization will be a reflection of the organization’s culture.

Oftentimes, the culture of an organization can be exposed simply by examining their priorities when it comes to balancing speed and quality. This recognition got us to the heart of the contribution challenge quickly.

Speed

We had a good laugh about the widespread misinformation that a contribution process can more rapidly help you to deliver on a design system. In my experience (and this resonated with a lot of attendees), a contribution process is a great empathy building exercise, but it is not the most efficient way to evolve the design system.

One respondent shared this:

“Leadership should be made aware that contributions are not a tool to speed up design systems, and without a properly established feature workflow practice in place, will actually contribute to the downfall of the system, in that the same sins of product will be recreated and redistributed from the system team.”

Quality

Many deep dive attendees represented their contributing teams by sharing feedback they had received. Noelle said, “my contributors feel they don’t have the expertise to approach the system.” This stems from a system designer’s desire to be an expert in their craft—the assets we offer should be high quality if we’re going to share them thoughout the organization. The challenge this presents is that subscriber teams may not feel qualified to contribute if the bar for quality is this high.

“Since our design system has been introduced as the ‘standards expert,’ I think people feel unable to contribute.”

Staton expressed a similar fear he’s heard expressed, “there is a fear of scrutiny” and also shared that contributors shy away from the process because they don’t want to be expected to own and maintain each contribution moving forward.

The Challenges

There were also a good number of respondents that shared some of the struggles they are having with contribution.

“We have never had a major contribution from an engineer outside of the dedicated design system team. These contributions are not recognized by their engineering managers, so taking the time to submit major contributions actually negatively impact their perf.”

“We have a contribution model that is perceived as too long and convoluted. We’ve conducted contribution retros with designers and engineers, and we’re planning a co-creation workshop with our users to create a process that works better within their own daily process. It’s important to us to create this with them, instead of at them, and also let them understand what goes on behind the scenes and have that context of why things need the time they need.”

“The biggest barrier to contribution is actually that we have autonomous teams.”

For some respondents, this pushed them to expand the definition of contribution:

“In my experience, the best contributions come less from sharing design/engineering cycles and more around helping the design system team understand customer/business needs, sharing the context for what purpose their request would serve and acting as a stakeholder who provides feedback on proposed solutions.”

Others found the solution by involving leadership:

“I think it’s important for leadership to make contributions a regular practice and create available time for it to happen. We have regular hackathons and migration efforts, and teams are encouraged to contribute back to the system during regular feature work.”

“Contribution can only work if it’s built into the incentive and capacity model.”

This brought up the necessity to balance an incentive-driven approach with the value we’re offering our subscribers. On their own, neither is enough. We need genuine support from leadership and we need to offer genuine value to our users.

Regardless of our current situations, we all acknowledged that there’s no easy approach.

In Conclusion

Ness left us with a series of questions to continue digging into.

Will building contribution into individual goals and performance outside of a DS team encourage contribution and adoption?

Does building a learning process people need to go through upfront before they’re allow to contribute encourage contributions? Does this work at a large scale, or is this only for small teams? And does this model continue to work when priorities start to build up in individual teams?

Have you got a library of ‘unofficial’ components created by other teams. How do you manage that?

How do you decide on what you need to work on outside of contributions?

Should a design system team be the sole owner of the system? If not, why?

Should we open ourselves up to allow people to freely contribute?

Design systems should never be blockers to product. So, when does a contribution become a contribution? When the idea is incepted, or when it’s been proven in product?

Clearly, we have more work to do. I’m encouraged by the openness with which everyone attending approached this conversation. As design system leaders, we have to be able to adapt to working with the teams throughout our organizations. This requires us to be students of their cultures and norms so that we can remove as many barriers as possible to working together. This likely isn’t what we signed up for, but it’s part of the job.

Additional resources

• The Orbit Model (by Orbit)
• Design System Contribution Criteria (by Nathan Curtis)
• Why you should prioritise quality over speed in design systems (by Amy Hupe)

Thank you

Many thanks to all who participated.

If you missed out this week, sign up for The Question and be ready to answer next time.

Writing Design Systems The Question