Design system contribution models: who gets to add a component

A design system contribution model is the set of rules that decides who can change a shared component library, which kinds of change each person can send, and the path a proposal travels before it ships. Every system meets the question the week a second product adopts it: a designer or an engineer outside the core team has built a component for their own screen, and they want it in the library.

The model you choose sets three things at once: how fast the library grows, how consistent it stays, and how much of the core team's week goes to reviewing other people's work. Below are the three models compared, the evidence on how each one fails, the criteria that decide whether a component belongs, and the model we run on our own system.

The short answer

There are three models. In a centralized model only the core team builds, and everyone else files requests. In a federated model designers and engineers from several product teams build the system together, with no team dedicated to it. In a hybrid model a core team owns the library and takes contributions by size: fixes from anyone, new components only through a proposal that proves they're needed in more than one place.

Unless your organization is a single team, pick the hybrid. The federated model on its own has the weakest record. Nathan Curtis, who described the solitary, centralized and federated team models in 2015, wrote in 2024 that across more than 80 design systems he has consulted on, none thrived without people allocated centrally to make and support the system. His verdict on his own earlier advice: "Favoring federated was and is wrong."

How do the three models compare?

In practice nine teams in ten keep a central team. In zeroheight's Design Systems Report 2025, 50% of respondents ran a centralized model, 41% a hybrid and 9% a federated one. The same report names each model's main problem: resourcing and silos for centralized teams, managing and encouraging contribution for hybrid teams, and system work losing to shifting priorities for federated teams, who described themselves as "just keeping the lights on".

Where a centralized model wins

A centralized model keeps one voice in every API. The same people name every prop, choose every default and write every guideline, so a component added in year three reads like one added in year one. That consistency is the reason to have a system at all, and a central team protects it best.

Atlassian runs close to this model. Its contribution page accepts contributions only from Atlassians, and among those it takes fixes (a bug in the code, a wrong Figma library component, a confusing sentence in the docs) and small enhancements such as a new icon. Major enhancements and new components, with data visualization as its example, it says it may be unable to take, because they need coordination across the whole system: code, design and guidelines.

The cost is the queue. In the zeroheight report, 54% of respondents at companies over 500 employees said they didn't have enough people, and the reasons included demand outpacing supply, with requests "often met with 'no' or 'not yet'". A product team that hears "not yet" ships its own version, and that local copy is where component drift starts.

Where a federated model wins

A federated model wins when the people building the products are few, close and used to reviewing each other's work. The people who feel the problem make the decision, components arrive at the speed of the product, and nobody waits on another team.

It stops working once the group grows past the point where everyone knows what everyone else built. Curtis describes the pattern: an organization disbands its system team and names a federated group to carry the system, none of whom are relieved of their other work. Six months later the system has stalled, its assets are aging and trust is shaken. Product priorities decide what each person works on, and nobody has time set aside for the library.

Where a hybrid model wins

The hybrid keeps a core team that owns quality and opens a way in for everyone else. The GOV.UK Design System is the best documented example. Its team wrote in 2023 that most major additions to the system now come from outside the team, and it publishes the criteria a contribution has to meet:

1. Useful: evidence that many teams or services would use it, such as screenshots or links to versions already running in different services.
2. Unique: it doesn't replicate something already in the system, or it shows it's better than what it replaces.
3. Usable: tested in user research with a representative sample of users, including people with disabilities.
4. Consistent: it reuses existing styles and components, and its code follows the system's coding standards.
5. Versatile: it works across the range of services that may need it, and across browsers, assistive technologies and devices.

The first two are checked at proposal, the last three before publication. That split matters, because a contributor learns whether the idea belongs before spending weeks on it.

GOV.UK also changed who starts the work. In 2022 the team surveyed its community (302 responses, 131 of them complete) and scored the results, boosting items that already existed in several departments' pattern libraries, could be built from existing components, were unlikely to need complex JavaScript or reduced potential harm to users. In 2023 it stopped waiting for teams to bring proposals. It now publishes its next priorities and asks the community to join the work on them.

Which changes should anyone be able to send?

Sort contributions by the size of the change. Curtis's guide to contributions splits them into two kinds, and the kind decides the path:

• Small changes go straight to a pull request: a fix for a functional, visual or accessibility defect, an objective improvement such as a focus state, performance, browser support.
• Large changes go through a proposal: a new component, a change to the visual language that runs through tokens across many components, an enhancement that breaks markup or behavior, documentation for a concern the system doesn't cover yet.

For large changes he borrows the request-for-comment process of open source projects such as Rust and Ember: an informal discussion, a written proposal, triage, a period of community discussion, approval, then implementation. The order protects the contributor's time, because the expensive step comes after the cheap ones have said yes. A large change that breaks a consumer also needs a major release, which is what design system versioning decides.

How do you decide whether a component belongs?

A system holds what many products share and leaves out what only one needs. Curtis's contribution criteria give the questions to ask a contributor before anyone starts building:

1. Is it relevant to another product, and to how many? His scale: one product is not enough, two is worth a conversation, three is worth a community discussion, five probably belongs.
2. Is it consistent with the system's direction, or would it pull in a new framework, a new testing workflow, a new kind of dependency?
3. What will it cost to build and maintain? A pill in a few colors is cheap. A date picker that every product needs in a slightly different form is the classic trap: built for everyone, it fits no one.
4. Does it open a direction useful to everyone? A tooltip brings layering, events and positioning that popovers and menus reuse.
5. Can the contributor say when to use it, how to configure it and what to avoid? If nobody can write the guidance, the component isn't ready to share.
6. Is the timing right for both sides, the system's roadmap and the contributor's manager?

Expect work after the yes. Curtis writes that in more than ten years he has never seen a contribution complete enough to merge as it arrived. It has to grow to a minimal feature set, shed the parts only its own product needs, and be normalized to how the system names and builds things. That last step falls to the core team in every model, and it's why a contribution model without a core team doesn't last. The same reasoning sits behind keeping the component count low and behind prop rules that prevent misuse.

What we use and why

We run a hybrid with a hard gate on new components. On our own design system, a project that consumes it can't add a component. When a page needs something the system doesn't draw, the project ships the smallest local version that works, in one file, under its own prefix, with a line above it naming the task that moves it into the system. The system team builds it there and releases it, and the project upgrades and deletes its local copy. A check counts the local versions on every build, so the debt stays in sight.

Before a new component, we look for an existing one that draws the thing with one more prop. A row of logos under a set of cards became a smaller size of the logo component, and the card gained nothing. The trade-off is time: a page sometimes waits a release for its piece. In exchange the library keeps one voice across its APIs, and the local versions form a short list we can count.

A contribution model sits inside a wider set of rules. Governing a design system across ten or more consumer projects covers the rest of that set, and why design system adoption stalls covers what happens when product teams find the way into the system harder than building around it.

Sources

• Nathan Curtis: The Fallacy of Federated Design Systems (2024)
• Nathan Curtis: Team Models for Scaling a Design System
• Nathan Curtis: Contributions to Design Systems
• Nathan Curtis: Design System Contribution Criteria
• zeroheight: Design Systems Report 2025 (PDF)
• Atlassian Design System: Contribution
• GOV.UK Design System: Contribution criteria
• GOV.UK: Iterating the GOV.UK Design System contribution model (2023)
• GOV.UK: How we prioritise additions to the GOV.UK Design System (2022)