Contribution

Understand how to contribute to the design system, from proposal to announcement.

Intro

Our Design System grows thanks to contributions from designers and engineers across the organization. Whether it’s adding a new component or improving an existing one, everyone plays an important role in shaping and continuously improving our core library and team workspaces.

This guide explains when something is a contribution, the validation criteria, and the process from idea to publication.


When to contribute

A contribution is any improvement to the system itself.

This is a contribution

  • Creating a new component
  • Adding new variants, properties, or states
  • Updating or refining an existing component
  • Replacing or deprecating components
  • Fixing bugs in Design System components

This is not a contribution

  • Usage questions (e.g., “Which component should I use?”)
  • Support or troubleshooting (e.g., “This seems broken — is it?”)
  • Feedback on your work (e.g., “Am I using this correctly?”)
  • Creating or updating product-specific patterns

 

Quick decision check

Use this quick check before creating a proposal:

Decision and complexity

 


Contribution Types

New

Creating an entirely new component.

  • No existing component solves the problem
  • Reused across projects/teams

Small Update

Enhancing an existing component or its properties without affecting current functionality.

  • Adding a variant
  • Adding a property
  • Visual/design tweaks

Major Update

Updating, redesigning, or replacing an existing component in a way that changes current functionality or requires teams to update usage.

  • Redesigning a component
  • Changing the behavior of existing properties or variants
  • Replacing an existing component

Bug

Fixing an issue in an existing component.

 


Validation Criteria

After submission, the committee will respond with an approval, rejection, or a request for more information. The following criteria are considered, with the first three being mandatory:

  • Clear business justification.
  • No existing component can be used or adapted.
  • Fits 3 or more use cases (product-specific) or both B2B and GX.
  • Adding it as a variant would be too complex.
  • Clear validation (e.g., user tests, feedback, metrics).
  • Completion of any necessary experimentation phases.
  • No negative impact on existing component functionality.

 

Approved Proposals

When a proposal is approved:

  • The committee replies to the requestor via the Slack list.
  • The contributor can start:
    • Creating a Figma branch in the relevant library, or
    • Going straight to code for engineering-only contributions.

Rejected Proposals

If the proposal doesn't meet the criteria, the committee will mark it as "Won't Do" and contact the requestor with an explanation.

  • If a suitable existing component is available, they’ll suggest it as an alternative.
  • If nothing fits, the requestor can keep their solution in a local file.

 


Roles

Contributor’s Role

As a contributor, you:

  • Check if your idea is a good match using the decision check and criteria
  • Submit a proposal to Design System Community
  • Design and/or implement the solution
  • Request the required reviews (team leads, committee)
  • Update or create documentation
  • Announce the change so others can adopt it

Committee’s Role

The committee is responsible for:

  • Reviewing incoming proposals and clarifying scope when needed
  • Reviewing Figma branches and PRs for higher-impact contributions
  • Handling risk, security, and overall coherence

 


Process

  1. Kickoff: Submit your proposal via the Slack form and wait for approval.
  2. Design: Create a Figma branch, design your solution, and request a branch review.
  3. Engineering: Implement the component and request a review.
  4. Final touches: Merge, document, and announce your contribution.
Contribution Process Overview

Contribution Process Overview