If you have a component request process, you're doing it wrong
The moment you add something along the lines of "request", you're creating a bottleneck. We should be sharing and then refining, not refining before we share.
I’ll dive straight into this. Vitaly Friedman posted on LinkedIn recently and shared a number of component contribution process flowcharts. All of them had some variation of “request”, “rfc”, “discuss need” as one of the first couple of steps. That’s when the product team with the component requirement has to engage with the design system team before the component is built. That’s just setting everyone up for failure from the start.
As part of the evolution of design systems, they reach a stage of maturity where people are using them. There’s clear demand, and cultural acceptance of the design system. And because people are using the design system, they’re going to come back to the core team with requests. And those requests usually fall along these kind of lines;
Hey, we need this component for our product. We’re shipping in two weeks, so can you build it for us by then?
But there’s also enough interest in the design system that some people are making contributions, submitting components and patterns as design proposals or pull requests to the core codebase. Which can often lead to a design system team response of;
That’s great design and code. But unfortunately we don’t think it’s a common use case. So we’re going to say “no” to adding this to the design system.
These both stem in some part from the same problem.
A design system team can’t possibly scale enough to be able to cater to all the incoming requests from product teams.
A component request process makes that problem worse
Things a product team can’t or won’t do
A component request process requires a product team to do at least one of two things, one which they can’t do, and one which they won’t do.
It requires the product team to adhere to the design system team’s timeline for delivering a particular component. The product team can’t do that.
Or it requires the product team to add extra work to their component build in order to make their component “good enough” to be shared through the design system. The product team won’t do that.
Things a design system team doesn’t know
These component design processes often include a mitigation to at least the second of those problems above. They add a step where the product team and the design system team meet and discuss whether the component in question is universal enough for inclusion, or if it’s a “snowflake”. If it’s a snowflake, then the product team can go ahead and build it independently of the design system team.
You know who’s terrible at answering the question about whether a new component is universal or broadly shareable? Design system teams and product teams. Until you share a component, you don’t know how shareable it is. Some of the most surprising components might advance other teams’ work, or something seemingly universal in usage might end up being not needed outside of certain limited scopes.
Build a publication process, not a request process
A mature design system, with cultural integration into your organization, needs to be a communal pursuit. If there is a request process, then you’re instead making the design system team an arbiter of what is good or what is necessary. Design system teams already have to be aware of the danger of becoming an ivory tower, this kind of process reinforces that unhealthy separation.
At the stage of evolution when a design system is thinking about a formalized request process is one where it already has a solid collection of “core” components, patterns, and guidance.
Replace this process:
request → approve → refine → publish
And use this process:
build → use → publish → refine
A design system is there to serve product teams
The moment that the design system team starts slowing down product teams, you’re already on a losing path. Empower those product teams to build what they need - trusting that they’ll use the existing guidance and governance the design system provides. Their priority is, and should remain, shipping their product. The only step we want to add to that is facilitating the sharing of the work that’s done. We need to make that as low friction as possible, but also embed the idea that we always share our work.
The refinement comes after the product team has shipped. That might be refinement by the community as a whole (another product team taking that component and extending it), or by the design system team itself (maybe updating the component to pass design system’s linting). Maybe, depending on the structure of the design system within the overall operational model, components might be “promoted” to the core system.
The communal approach reduces pressure on everyone
The best design systems, I believe, are communal efforts where the central design system team is a part of a broader ecosystem. Creation can come from anywhere. By sharing everything by default, we’re not pre-judging things based on where within that ecosystem they come from.
We think and refine by doing. We take a foundational design system and grow its library of assets. We trust that if something is ready to be shipped by one product team, then it’s ready to be shared internally and iterated upon. And we actively push back against processes that create a greater bottleneck on design system delivery and usage.