Scaling Design System Contributions
How can we move from a centralized to federated design system contribution model?
Context
My team (myself, a tech lead, and four engineers) had recently completed a visual overhaul of Indigo’s design system. We had been filling in gaps in our atom and molecule-level components and fielding requests for new components or features.
Requests from teams were added to our backlog in two ways:
- In design reviews or consulting sessions, I would flag cases where a designer was using something that didn’t exist in the design system.
- Engineering would notice component issues as they were trying to build a feature and bring those issues to our office hours or set up consulting time.
In both cases, my team and I would work with the designer and engineers to understand if an existing component was an appropriate alternative or if the feature was unique and necessary to add to the design system.
Problem
Our backlog was growing too quickly. Our single team couldn’t keep up with the volume, and it prevented us from getting to bigger, more challenging components on our roadmap.
Investigation
What types of requests were we getting that were clogging up our backlog?
We looked into the details of the requests and organized them into two categories.
12–15 requests per week
64%
Simple Requests
Such as: bug fixes, modifying existing components, adding new tokens, or building smaller atom-level components.
36%
Complex Requests
Needed my team’s accessibility and design system expertise: new higher-level components or new concepts where there wasn’t a framework or system in place yet.
That data raised some questions. How could we:
- Empower teams to tackle simple requests on their own?
- Maintain quality standards in their contributions?
- Upskill teams to be able to handle some complex requests on their own?
Empowering teams to contribute
I partnered with my tech lead to design a new contribution process that would shift our model from centralized to federated. I reviewed this process with the design team, iterated on their feedback, and presented the final process to the full UX team. My tech lead and I presented the same process at an Engineering All-Hands meeting to communicate our new operating model.
We encouraged designers to proactively audit their designs for design system consistency and work with their teams to plan for that work. We opened up the design system GitHub repo and encouraged teams to open pull requests directly, which would automatically tag my team for review.
Maintaining quality
I wrote contribution guidelines for designers, which we published to our documentation site and inside our Figma component libraries. Even with our shift from a “done for you” to a “done with you” model, I provided feedback and flagged issues in design review, and would consult 1:1 with designers as they explored new problem spaces or dug into hard interface design problems.
I partnered with my tech lead to rewrite our engineering contribution guidelines, which we published on our documentation site and inside GitHub.
Upskilling our teammates
To help designers better understand design system concepts, I gave presentations on designing for accessibility, responsive and mobile-first design, and helped share Figma and visual design tips related to designing components. I partnered with my tech lead to give an overview of accessibility to the entire company. We recorded these sessions and published them to an internal wiki for teams to refer back to.
Results
A month after rolling out our new process, we’d already seen a shift in the type of requests coming in.
75%
Reduction in total requests
71%
Reduction in simple requests
Our team had more bandwidth to focus on higher-level and more challenging patterns like table and table filters, a new page layout system, and a revamp of all of our form elements.