Contributing to a Design System: The Process Step by Step
Contributing to a design system means proposing a change, backing it with a real case, and passing review. When a ticket is enough, when an RFC is needed.
What does contributing mean?
A design system is a common good. Every team that adds a component without consulting anyone creates another version of the button, and six months later there are four almost identical buttons. Contributing means bringing the need into that shared space, with an argument that serves more than one team.
Carbon, IBM’s design system, frames it openly: anyone can contribute code, design, and documentation (Carbon, “Contributing”).
When is a ticket enough and when is an RFC needed?
A practical split is to separate small changes from large ones:
- Small changes. A fix, a new state, or an improvement to documentation. They go through a ticket, with clear acceptance criteria and a quick review.
- Large changes. A new component, a new API, or a change that affects several teams. They go through an RFC: a document that is discussed before anything is built.
The Australian Government Design System organizes RFCs by stage: an RFC has draft status while the pull request discusses it, and it is merged when it receives an absolute majority of approvals from the maintainers (Australian Government Design System, “RFCs”). That formal process isn’t needed on every team, but the logic is worth borrowing.
What does a proposal include?
A useful proposal answers five questions:
- What problem does it solve? With a real case: the screen, the flow, and the team that needs it.
- Does something similar already exist? If a component covers 80% of the need, the proposal must explain why it isn’t enough.
- Who would use it? The more teams, the easier it is to justify.
- What does it look like and how is it used? With a sketch in Figma and a description of states, variants, and behavior.
- What are the acceptance criteria? When is it considered done?
Carbon adds a rule worth copying: every requirement category must be completed before a component is considered done, and every component or pattern needs usage, style, code, and accessibility guidance (Carbon, “Contribute design”). Those guides are part of the work, not an extra.
Which criteria usually decide?
The GOV.UK Design System publishes its contribution criteria. Before proposing, it requires evidence that the component or pattern would be useful to many teams or services (for example, screenshots or links to live uses) and that it doesn’t replicate something already in the system; if it replaces something, you must show it performs better. Before publication, it asks that it has been tested in user research with a representative sample of users, including people with disabilities, and that it reuses the system’s existing styles and components (GOV.UK Design System, “Contribution criteria”). To propose one, first check the GitHub discussions for someone who already suggested it and, if so, add your support instead of opening another thread (GOV.UK Design System, “Propose a component or pattern”).
As a team rule of thumb: if the component will be used in three or more places, it deserves a place in the system; if it will be used in one, it is probably a local component.
What happens after you propose?
The process doesn’t end with the proposal. In the Australian repository, anyone can ask to implement an approved RFC by adding their name to the Implementer section. GOV.UK prioritizes community proposals each year, and if yours isn’t chosen, you can develop it yourself or leave it for someone else. Carbon invites you to subscribe to its office hours, where the team helps you find a first contribution based on your skills. In any case, expect review to ask for adjustments.
Example
Illustrative example: a product team needs a date-range picker. The system already has a simple calendar. Before creating a new component, the person proposing checks the catalog and sees that the calendar doesn’t handle ranges or keyboard accessibility. They write an RFC with three real cases from other teams, a Figma sketch with the states, and a list of criteria: keyboard navigation, announcement of the selected range, and usage documentation. The RFC passes review with two changes requested by engineering. The component is built in two sprints, and afterward the team updates the design documentation with its use and limits.
When NOT to propose something to the system
- When the case belongs to one team. A very specific component is better kept in the product that uses it.
- When the system has no maintenance. Proposing to a system nobody reviews adds debt.
- When there is no real case. A hypothetical component doesn’t justify an RFC.
- When you are seeking approval for a product decision. The system defines how things are built, not what is sold.
Common mistakes
- Proposing without checking the catalog and duplicating an existing component.
- Sending an RFC without a real case or a sketch.
- Forgetting accessibility and usage documentation.
- Creating variants instead of extending a component that already exists.
- Leaving the proposal open without an owner or a review date.
How to start tomorrow
Open your design system’s catalog and find the component you have built by hand most often in the last quarter. If something similar exists, note what it lacks. If nothing does, write the proposal on one page: problem, real case, sketch, criteria, and who would use it. Send it to the person who maintains the system before asking for a formal RFC. And coordinate the build with the development team, because a proposal is only worth something if it can be built.