How Should People Contribute to Your Design System?

Who is allowed to add a component to your design system?

Whoever you decide, as long as it is written down and one named person can say no. Most design systems fail not because the components are bad but because nobody defined how a new one gets in, so either everything gets in or nothing does.

This is the question that separates a design system from a component folder. A folder accumulates. A system decides.

What follows is the contribution model we set up with product teams, in four stages, with the standards we hold new components against.

Why does contribution need a model at all?

Because the alternative is two failure modes and both are common. In the first, the system team is the only one allowed to build, they become a bottleneck, and product teams quietly build their own versions to ship on time. You now have two systems and one of them is undocumented.

In the second, anyone can add anything. Six months later there are four button variants, three modal implementations and a date picker nobody can explain. The system exists and provides no consistency, which is the only thing it was for.

A contribution model is the thing that avoids both. It is mostly not a technical document. It is a set of decisions about who decides.

What are the three team patterns?

The design systems community has settled on three names for how the work gets distributed, and they are a useful starting vocabulary. Solitary, where one team builds the system mainly for its own needs and others use it as they find it. Centralized, where a dedicated team owns the system and serves the whole organisation. Federated, where several product teams contribute and maintain it together.

Each buys something different. Solitary is cheap and fast and drifts from other teams' needs. Centralized gives consistency and creates a queue. Federated gives you people who actually use the components making the decisions, at the cost of much heavier coordination.

Our observation is that teams choose federated because it sounds inclusive and then run it without the coordination it requires, which produces the worst of both. Federated is the most expensive model to run properly, not the cheapest.

Which pattern fits your team?

Count the product surfaces and the people. One product and fewer than about ten designers and engineers: centralized in practice, even if nobody calls it that, because the same few people build everything anyway.

Two to four surfaces with separate teams: centralized ownership with a documented contribution path. That is the configuration most B2B SaaS companies are in, and it is where a written model pays for itself immediately.

Many surfaces across business units: federated, with a small core team whose job is arbitration and release rather than building. If you go federated without that core team, you have not chosen federated, you have chosen nothing. The fundamentals of the system itself are in our guide to building a design system.

Stage one: define what counts as a component

Write the test before the debate. Our rule is that something enters the system when it is needed in two places by two teams and has a defined behaviour. One team needing it once is a product component, not a system component.

For interactive components, there is an external standard you can lean on rather than inventing your own list. The W3C ARIA Authoring Practices Guide documents patterns with precise definitions: a disclosure is "a widget that enables content to be either collapsed (hidden) or expanded (visible)", a combobox is "an input widget that has an associated popup", a switch is "an input widget allowing users to choose one of two values: on or off".

That precision resolves arguments. When someone proposes a component, the first question is which documented pattern it is. If it is a tabs pattern, it is "a set of layered sections of content that display one panel of content at a time", and it should behave like every other tabs implementation in the world. If it matches no pattern, that is worth knowing before anyone builds it.

Stage two: write the contribution path

Four steps, on one page, findable. Propose, review, build, release. The value is not in the sophistication, it is in the existence.

Propose means an entry somewhere with the use case, the two places it is needed, and which documented pattern it matches. Review means a named person or pair responds within a stated time, which we set at one week because anything longer sends people back to building their own.

Build means whoever proposed it can do the work, with support, rather than handing it to a queue. Release means a version, a changelog entry and documentation before it counts as available. A component that exists in code and not in documentation has not been contributed, it has been hidden.

Stage three: set the acceptance bar

Publish it as a checklist so nobody is surprised at review. Ours has five lines: it matches a documented pattern or explains why not, it uses only system tokens for colour, spacing and type, it meets the keyboard and screen reader behaviour its pattern requires, it has documentation with at least one real usage example, and it names an owner.

The ARIA guide is the reference for the third line, because it specifies expected keyboard behaviour per pattern. Accepting a component that looks right and cannot be operated from a keyboard is how a design system ends up spreading an accessibility bug across twelve products instead of one. The product-side thinking on that is in focus and keyboard behaviour in product UI.

The token line is the one people negotiate hardest, and it is the one to hold. A component with a hardcoded hex value is a component that will not survive a rebrand, and it will be the one that breaks visibly.

Stage four: decide who says no

One person, named, with an explicit remit. Not a committee, because committees do not refuse things, they request changes until the proposer gives up. That is a worse outcome than a clean no, because it wastes the proposer's time first.

Give them a stated basis for refusal: duplicates an existing component, serves one team only, does not match a pattern, or fails the checklist. Anything outside that list is a discussion rather than a veto.

And publish the refusals. A short log of what was proposed and why it did not enter the system is the most useful document a design system produces, because it teaches the next proposer the standard without another review cycle. It fits naturally with the rest of the review practice we described in how we run design review.

What about tokens and naming?

Settle the naming before the contributions start, because renaming tokens later touches every component at once. There is now a specification effort to point at: the Design Tokens Format Module, which defines a token as "information associated with a human readable name, at minimum a name/value pair".

Its rules are worth adopting even if you do not adopt the format. Token names must not begin with the reserved dollar character, and cannot contain curly brackets or periods because those are reserved for the reference syntax. Values carry a type, either set on the token or inherited from its group. Composite tokens bundle sub-values for things like shadows, borders and typography.

One honest caveat. The specification is a draft community group report, and the version we read is explicitly labelled a preview that states "do not attempt to implement this version of the specification". Treat it as a strong convention rather than a standard to build tooling against, which is also the reasoning in making design tokens survive a rebrand.

What does a healthy contribution model look like after a year?

Fewer components than you expected, more documentation than you expected, and a refusal log that people actually read. Proposals arrive already matching a pattern because the checklist trained everyone. The named owner says no perhaps once a quarter and nobody is offended, because the basis was published in advance.

The clearest signal of health is that product teams stop building their own versions. That only happens when the contribution path is faster than going around it, which is why the one week review commitment matters more than any part of the checklist.

If you are standing up a system or trying to rescue one that has sprawled, we do this work alongside product and marketing site builds. Tell us where it stands at phoenix.studio.