A contribution model people actually use

Every design systems talk has a slide with the perfect contribution model. Arrows, swim lanes, a little rocket at the end. I have bad news: there is no secret recipe. There’s iteration.

Steal the rituals, not the process

We tried a lot. Rhythms, models, scenarios, routines. We looked at the big, famous design systems, copied their rituals and processes, and checked how much of it actually worked for our scope.

Some of it did. Most of it needed bending. In the end, a contribution model has to be built for the company it lives in. What works for a public library used by thousands of strangers doesn’t automatically work for twenty feature teams who share a Slack.

Steal the rituals. Build the process yourself.

The one hard rule

What we did agree on, depending on complexity, was one non-negotiable: every component gets built with the same construction. Core component, community component or one-off snowflake, doesn’t matter. Token adoption, Storybook, the same standards for everyone.

That rule made everything else possible. A component could start its life inside a feature, owned by the team that needed it. And if it turned out to be useful, a design system review could promote it, quickly, into a community component or a proper core component.

Community components

Community components are owned by the feature team, not by the design system. They’re still released through the design system, so they show up in the same library, with the same quality bar. But when something breaks, the people who built it fix it.

We didn’t invent that. We got inspired by the design system at Nord Health, which works the same way. Credit where it’s due.

Try the path yourself:

“Can we have variant X?”

The classic conflict. A team wants variant X, the system says no. It happened a lot, and how it went depended entirely on the team.

Some teams simply built it themselves, without talking to us. That’s a shame, but it happens. Teams that were willing to collaborate got the opposite: we went deep into their feature request and argued it out properly.

Our strongest argument was always platform consistency, especially for navigation and for how actions open: dialog, panel, drawer. We had seen inconsistency there show up again and again as a negative in user tests. That’s hard to argue with.

Overall, we were very willing to compromise. And yes, some components still flew under the radar and made it into production anyway. Every design system has a few of those. Pretending otherwise is how you lose credibility.

Figma admin, a love story

I was also the Figma org admin. If you’ve ever seen the Figma admin panel, you know. It’s not the coolest place on the internet, and the payment models are clearly not made for big organisations.

The most annoying part was the seat hygiene. Who is still active? Who actually needs a full seat? People requested full seats because they joined one single workshop, which a 24-hour open session would have solved for free. Multiply that by a few hundred people and you understand why I have fucking opinions about seat billing.

The rituals that worked

Communication is the whole job. Office hours, where the design system openly shares what’s new and where product designers can push things into the system themselves. Changelogs right in the Figma files, where designers actually look.

The best format, though, was what we called Harmony Sessions. Once a month, 30 minutes 1:1 with each designer. Not a group session. Not just design system updates. A real check-in: where are you in your work, what’s bugging you, where could we enable you better, in the system and in the process around it.

Not everyone wants to speak up in the big round. That’s just human. Some people love it, some don’t, and the quiet ones often have the best feedback. Individual beats scalable, more often than design systems people like to admit.

What went wrong

The biggest problem wasn’t a process. It was a mindset: designers separating themselves from engineering. Not understanding how complex it is to change or bend an existing component, once it’s in code and used in fifty places.

That’s not a design system problem, it’s a product design problem. But the design system is where it hurts first.

Did it work?

We ran the classic surveys, of course. But the most convincing method was a comparison. We set up lighthouse projects that followed the DesignOps process as closely as possible, and put them next to another project of the same size that didn’t.

The result: the team that invested in the ops part worked more efficiently. Faster to market, fewer iteration rounds. No vanity metric, just two projects side by side.

At Unblu

Right now my focus is transparency. A clear roadmap, a clear issue structure, and making UX issues visible inside product design and the feature process. Not just the feature work, but the DesignOps and design system work too, so it becomes measurable.

So yes: contribution and operations again. Different company, same lesson. The components are the easy part.