Back PJ Onori’s blog

Design system contributions work better when everyone knows your name

If you heard me talk about design system contributions, you know I haven’t been a fan. I’ve worked at some moderately large companies for the past decade. Not Weyland-Yutani big. But big enough to be a humble cog in a machine.

And in that setting, contributions have been more about feeling than function. They were a way to keep consumer teams engaged. It made it clear the design system team was something they could be a part of. But was it the most cost-effective way to run a system? Oh, hell no.

Big orgs, big problems

Big anything means complexity. Companies are no exception. Anything with a lot of people is going to make things complicated. Things that work fine for a few folks don’t with one hundred. And vice versa.

Contribution models are no exception. They’re hard for systems that support a lot of people. How can people effectively contribute to a system supporting thousands of use cases? Especially when their focus is on a handful–or one. It’s hard for anyone to have such a wide perspective–especially when it’s not their full-time job.

And that’s how we get complicated contribution models. Thousands of system consumers could mean a deluge of contributions. One bad addition could impact hundreds of people. Safeguards, checks, and process get put into place for a reason.

Either way, contribution model’s success is inversely related to how involved it is. The more process, the more pain. All those steps may be important. But they also introduce more failure points. There are tax codes simpler than some contribution models. One in particular made me question my mental acuity. I’ve seen some shit…

That’s why I’ve shied away from contributions at larger orgs. Now, that’s not to say that contributions at big companies can’t work. My experience says they’re very hard. You may got it all figured out. Kudos. I don’t. And I’d rather focus on design systems than cracking the code of contributions at mega-corp scale. That’s just me.

Contributions make sense for Cheers-sized teams

But small teams are simpler. There’s less moving pieces. Less complexity. The problems are still there–but they haven’t snowballed to the point where they’re an actual problem.

I have a super-scientific take. Contributions are most effective on teams small enough where everyone knows your name. A contribution is a mutual effort. Mutual efforts rely on established relationships and a heaping spoonful of trust. Right or wrong, the bigger the org, the more little fiefdoms begin to form. The “team” is actually nine or ten real teams. The “mutual” in mutual effort doesn’t feel so mutual.

That’s when process begins to kick into overdrive. I couldn’t tell you what the exact cliff when things stop working. But a sign to look out for is when contributions begin with introductions.

Not every process has to be a process

I like to say that you should be able to describe a component in a sentence. Anything more and it’s too complicated. Similarly, you should be able to describe a contribution model in couple paragraphs. Maybe three. The process shouldn’t be a process.

Folks are going to disagree with this. They’ll say two paragraphs is not even close enough detail. I agree! That’s where established relationships and trust come in to play. Sure, you could outline every hypothetical situation and edge case… Or you could create just enough structure so it gets done. And yes, that’s going to be a mess at a larger org. Which is my point.

So, what could a contribution process look like?

Step 1: Make a recipe

Add a recipe to the shared library. That’s it. People can as much or as little detail as they’d like. Stopping at step 1 is fine. No matter what happens, the creator has something everyone can use.

Step 2: Review a recipe

If the creator or the team wants it graduate to the system, they’d review the recipe with the design system team. Maybe it goes in. Maybe it doesn’t. Either way, the recipe is still usable.

Step 3: Contribute a recipe

If everyone agrees to bring a recipe into the system, they do the following:

That’s my one rule for contribution. There needs to be a payoff for putting in the time to contribute. There are few worse feelings than wasted time. Putting in work and getting nothing out of it? That’s shitty. This process makes sure that, at the very least, the designer or engineer gets a recipe.

But, like, what’s a recipe?

Recipes are low-key, air-quote contributions

Recipes are a distinct composition of existing (mainly) of design system components. An example of a recipe would be an onboarding stepper pattern. All the design system’s bits and bobs are used to make something new.

Using the system for a recipe is the secret sauce. A good design system is going to cover all important bases–like accessibility. Which means a lot of the recipe’s details are theoretically sorted out. Mind you, “theoretically” and reality aren’t the same thing. But, it creates a much higher chance for less overhead.

They’re the low-key, low-stakes way to (kinda) add to the system–in a good way. They provide a color-by-numbers interface for making something. This way means people don’t have to know all the gory details of the system to make something for it.

Can recipes be smaller than a pattern? Sure. Instead of using design system components, they’d use design system tokens. It’s the same idea, just taken down a rung in the hierarchy of design system elements.

The most important characteristic of recipes is that the design system doesn’t own it. No policing. No oversight. No nothing. It’s a place where designers can do what they think makes sense. Designers can choose to make recipes completely detatched from the design system. Which is fine. It also means it’ll only exist as a recipe. Which is also fine.

Now, this isn’t some magic bullet. A recipe library needs the same care and maintenance, like any other. And that means that one or more product designers will have to own it. Because–say it with me–the design system team doesn’t own recipes

Small and mighty

Yes, this is high level. Yes, there ten sub-steps for each outlined step. But, in my experience, a team with a strong partnership and trust fill in those gaps. Often differently each time.

Process and rules are important. But they also can get between people. I’ve seen loose process work really well among teams with a strong relationships and trust. Would this work in a large-org setting? Maybe, but I could see a hundred different ways it may not. I see this playing out much better in a healthy smaller team. Emphasis on healthy.

Some may see this as a cop-out. I prefer pragmatic. Some things scale like crap. My two cents is that contribution models fall in that category. But if you may want to try out my approach if you go to work where everyone knows your name.