Skip to content
UX Atlas
Plate SYS·007 · Design systemGrid C4 · Rev. 2026-09-14

Contribution Models

How work gets from a product team into the shared system without either blocking the team or degrading the system.

Design systemCraft conventionAdvanced

Definition

A contribution model defines the route by which product teams add to or change the shared system. Without one, teams either wait indefinitely or fork, and both outcomes damage the system.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2A workable path
  3. 3What contributors need
  4. 4Route by type of contribution
  5. 5Making contribution repeatable
  6. 6Commonly confused with
  7. 7Local chart
  8. 8Continue from here

Reach for this when

  • The core team is a bottleneck.
  • Teams are forking components.
  • Setting up a new system's process.

Common mistakes

  • Blocking product work pending a system decision.
  • Accepting contributions with no accessibility or documentation standard.
  • Promoting from a single use case.

A workable path

  1. 1

    Build locally first

    The team solves their problem in their own codebase. Nothing is blocked.

  2. 2

    Signal the need

    Register it against the system, so the core team can see repeat demand.

  3. 3

    Wait for the third instance

    When three teams need it, the shape of the general case is visible.

  4. 4

    Design the general API

    The core team and contributors agree the interface, informed by all three implementations.

  5. 5

    Promote and migrate

    Move it into the system, migrate the original implementations, and delete the local copies.

What contributors need

  • A written definition of done, including accessibility and documentation requirements.
  • A review turnaround commitment that is actually met.
  • A pairing option, since most product designers and engineers contribute rarely.
  • Credit, which is the main non-monetary incentive that sustains contribution.

Route by type of contribution

One path for everything is what makes a contribution model unusable. A documentation fix should not cost what a new component costs.

ContributionRouteTurnaround to state
Documentation fixDirect change, no proposalSame week.
Defect in an existing componentChange with a failing test attachedSame week.
New variant of an existing componentShort written proposal naming the three use casesTwo weeks to a decision.
New shared componentProposal, then paired build with the core teamOne planning cycle.
New or changed tokenCore team by request, never directTwo weeks, because everything downstream inherits it.
Something the system should not ownKeep it local, record the decisionImmediate, and say so plainly.

Making contribution repeatable

Do

  • Publish a definition of done covering states, accessibility, documentation and tests, so finished is not a judgement call.
  • Pair on each team's first contribution. It costs a day and produces a repeat contributor.
  • Name contributors in the release notes.
  • Let the contributing team keep shipping their local version while the shared one is in review.

Do not

  • Do not accept a component without its documentation. It does not arrive later.
  • Do not silently rewrite a contribution. Review it, or you lose the contributor and the next one.
  • Do not make the proposal longer than the component.
  • Do not promote from a single use case because the team is senior or the deadline is close.

Commonly confused with

Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.

vs.

Design System Governance

Design system

Ownership, review and decision-making for the system as a whole.

Key difference

Governance is who decides and how coherence is kept. A contribution model is the route a product team takes to get work into the system. Governance without a contribution route produces a queue; contribution without governance produces a pile.

Use Contribution Models when

  • Teams are forking because waiting costs more than duplicating.
  • Someone has built something worth promoting into the system.
  • The question is process, entry criteria and who does the work.

Use Design System Governance when

  • Nobody can say who owns a decision, or everything needs one person.
  • The system is fragmenting, or ossifying because nothing gets approved.
  • The question is authority and standards.

Learn about Design System Governance

Local chart

SYS·007 · Region VI · Grid C4

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Design CritiqueTPL·012 · OFTEN USED WITHDesign System GovernanceSYS·004 · COMMONLY CONFUSED WITHMigrating Product Teams onto a Design SystemCASE·003 · PRACTICAL EXAMPLEDefinition of DoneTERM·096 · SHORT DEFINITIONComponent API DesignSYS·002 · RELATED CONCEPTDesign System AdoptionSYS·005 · RELATED CONCEPTDesign System DocumentationSYS·003 · RELATED CONCEPTDesign CritiqueFLOW·001 · RELATED CONCEPT

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Often used with

These usually appear in the same screen or the same decision.

Practical example

A worked decision where this was the deciding factor.

Short definition

The one-paragraph version, for when that is all you need.

Related concept

Connected closely enough to change how you apply this.