Who Can Change the Button? Design System Contribution Models
A contribution model defines who can change the design system, balancing consistency with evolution. It dictates whether you can fix a typo or must lobby for a new component.
Why it exists
A design system without a contribution model is a component library that will either stagnate from neglect or become chaotic from uncoordinated changes. A model provides a clear, predictable process for evolution, preventing one team's urgent need from breaking the system for everyone else.
The mental model
Think of a contribution model as the 'constitution' for your product's UI. It's the set of laws and processes governing how new UI 'legislation'—like components, tokens, and patterns—is proposed, debated, and passed. It defines the rights and responsibilities of the 'citizens' (product teams) and the 'government' (the core design system team).
How it works
Models exist on a spectrum. A 'Centralized' model means a core team builds everything. A 'Federated' model, which is more common, allows contributors from various teams to propose and build changes that the core team reviews and integrates. The process can range from a simple pull request for a bug fix to a formal design critique for a new pattern. The goal is to make small changes easy and large changes deliberate.
When to use it
Every design system needs a contribution model from day one, even if it's just a README file outlining the process. It sets expectations and creates pathways for collaboration. It becomes absolutely critical as an organization scales and more teams consume the system, increasing the risk of fragmentation.
When not to use it
The question is not if you need a model, but how formal it should be. The absence of a defined model is itself a model—usually a chaotic one where changes happen through DMs and ad-hoc meetings. A small team might only need an informal process, but a process must exist. A system with no defined path for contribution is a dead end.
One canonical example
Atlassian's design system uses a federated model where contribution is encouraged but gated by scope. They explicitly welcome small, low-risk contributions like bug fixes or documentation typos directly from product teams. However, for larger changes like adding a new feature to an existing component or creating a new pattern, they require teams to engage with the core systems team first. This ensures major changes are coordinated and benefit the entire ecosystem, not just one product's immediate needs.
Interview question
How does a federated contribution model typically balance flexibility and consistency?
- a.By allowing product teams to implement minor changes directly, while requiring core team engagement for significant updates.Correct
- b.By establishing a rigid set of rules that all changes must adhere to, ensuring uniformity across the system.
- c.By having product teams build all changes, which are then subject to a formal review and integration process by the core team.
- d.By centralizing all development within a core team, with other teams only providing requirements.
Why? this is the answer
A federated model balances flexibility by allowing product teams to handle small, low-risk changes directly, and consistency by requiring core team involvement for larger, more impactful updates. This aligns with the principle of making 'small changes easy and large changes deliberate,' as exemplified by Atlassian. Option C describes a general mechanism but doesn't fully capture the tiered approach to balancing flexibility and consistency for different scopes of change.
Just read this? Test yourself on what you have been reading.
Read the original → atlassian.design
- #design systems
- #governance
- #contribution
- #frontend
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles