How to Build a Design System Contribution Model Without Turning the Core into a Request Dump

Open contribution does not mean putting every business request into the component library. A strong Contribution Model brings product teams into the process with real problems and evidence while using tiers, reviews, quality gates, and maintenance accountability to protect the core system over time.

Once a design system reaches a certain scale, the core team almost inevitably faces the same conflict. If it builds every component, the request queue grows indefinitely. If contribution is completely open, the system quickly fills with special components serving only one business. A Contribution Model creates a workable collaboration mechanism between centralized control and a complete free-for-all.

01 1. Contribution Starts with a Problem, Not a Figma File

Carbon's contribution process first asks contributors to select or clarify an issue, then refine the scope and gather feedback. The order matters. Many failed contributions begin with "I already designed a new component; please merge it." The core team can reject it only at the end, after both sides have wasted time.

A better proposal first answers: which user encounters what problem during which task? Why can existing components and compositions not solve it? In which products does the problem occur? Is there evidence from real use? If it is a one-off need for one business, why should the entire company maintain it indefinitely?

02 2. Divide Contributions into Three Types Instead of Sending Everything Through an RFC

• Fixes: code bugs, Figma errors, documentation problems, and accessibility defects. The scope is clear and deserves a fast track.
• Small enhancements: a new icon, additional example, or compatibility property that does not change core behavior. It needs review by design and engineering, but not a major review meeting.
• System-level contributions: a new component or pattern, breaking API change, or token architecture change. It requires a complete proposal, validation, and migration plan.

Atlassian's current public contribution guidance follows a similar principle: fixes and small enhancements are easier to accept, while new components and broad behavior changes affect several products and require system-level coordination.

03 3. Design a Genuinely Useful Contribution Proposal Template

The template should be more than three rows for component name, owner, and deadline. Include at least: problem statement, target users, real scenarios, analysis of existing solutions, evidence of cross-product reuse, design exploration, accessibility risks, internationalization impact, draft API, token needs, compatibility, test plan, documentation plan, and owner.

The template is not paperwork for its own sake. It reveals early whether the proposal belongs in the system. If contributors cannot explain who will reuse it, how it will be maintained, and what happens after a breaking change, it is better treated as a product-specific component.

04 4. Run a System Fit Review Before Design Begins

The core team's most valuable intervention happens before the solution hardens, not during final acceptance. A 30-minute System Fit Review can focus on three questions: does a reusable capability already exist; should the team compose or extend it; and, if it enters the system, what is the smallest public API?

This prevents a contributor from spending two weeks completing an unsuitable system proposal before rejection. Carbon likewise recommends ongoing feedback throughout design and development instead of waiting for the final submission.

05 5. Review Long-Term Maintenance Cost

A product team usually asks whether the contribution solves today's problem. The design system team must also look ahead: will states proliferate quickly? Will it work across densities, themes, and languages? Can the API remain stable? Does it depend on business data? How costly is testing? Who fixes bugs if the contributing team reorganizes next year?

Contribution review therefore cannot be a single visual review. It needs at least design, engineering, and accessibility perspectives. Complex patterns may also require content design, internationalization, or security specialists.

06 6. The Definition of Done Is the Quality Floor

A contribution needs explicit completion criteria before becoming Stable. At minimum, include the Figma component and properties, code implementation, every key state, keyboard and focus behavior, tests, responsive rules, content rules, token use, documentation, Storybook or another example environment, and a version change record.

If code is merged with a promise to "write the documentation later," the documentation will almost certainly remain incomplete. The quality gate must be bound to the merge itself.

07 7. Who Owns a Successful Contribution?

"Contribute it, then hand it to the core team" quickly transfers all maintenance debt to the core. Establish joint ownership: the core team maintains system consistency and release infrastructure, while domain contributors or the product team remain responsible for domain issues for an agreed period. Highly specialized capabilities such as data visualization and AI interaction can have a permanent guild rather than requiring the core team to master every field.

08 8. A Contribution Does Not Have to Enter Core Forever

Use several tiers: Core, Community / Labs, and Product-specific. A new capability without enough reuse evidence can begin in Labs for validation in real products, then move to Core after stable use across several teams. This is more flexible than choosing between outright rejection and permanent maintenance.

09 9. How Do You Keep the Process from Becoming Bureaucratic?

Use risk tiers. A documentation typo should not require a ten-page RFC, while a new component should not be merged because someone wrote "LGTM" in a chat. Let the contribution type determine review depth and publish its status, owner, and expected response time. The more transparent the process, the more willing product teams are to participate.

10 10. Measure Whether the Contribution Model Works

Track time from submission to first feedback, time to merge, the share of contributions from outside the core team, major rejection reasons, adoption six months after contribution, and defects and support cost created by contributed components. Most importantly, observe whether product teams involve the system team early in a problem instead of asking to "add it to the library" only after completion.

A good contribution model does not make the design system looser. It turns collaboration once hidden in private messages and temporary arrangements into a visible, reusable, traceable organizational capability.

Frequently Asked Questions

Does every design system contribution need an RFC?

No. A complete RFC is worthwhile only for high-impact work such as new components and breaking changes. Documentation fixes and small enhancements need a fast track.

How do you distinguish a product component from a system component?

Look at reuse and long-term stability. A capability tied to one workflow, heavily dependent on business data, and changing frequently usually belongs at the product layer.

Can the core team reject a contribution?

Yes, and it should explain the reason transparently—for example, an existing alternative, insufficient reuse evidence, excessive maintenance cost, or conflict with system principles.

Must a contributor be able to design and code?

No. A designer, developer, or content designer can initiate a contribution, but system-level work ultimately needs cross-functional collaboration for a complete delivery.

How can more people be encouraged to contribute?

Lower the barrier for small contributions, provide clear templates, offer office hours, respond quickly at first contact, and recognize contributors. These work better than simply asking everyone to "build the system together."