Design a Component Contribution Model
Design Systems & Tokens · design systems, process, components
Updated 2026-07-28
- Assume the system will be incomplete forever. Product teams will always need something that does not exist yet, and the only question is whether that work comes back to the system or forks away from it.
- Publish the route in. If contributing is slower and less certain than building a private copy, everybody builds private copies.
- Define the stages plainly:
- Propose, with the real use case and the screens that need it.
- Prototype, in the product where it is needed.
- Promote, once a second team needs the same thing.
- Use the second use case as the trigger for promotion. One team's need is a feature, and two teams' need is a pattern.
- Say what a contribution must include before it is accepted, such as states, accessibility behaviour, responsive rules, tokens instead of hardcoded values, and documentation.
- Give contributors a real answer quickly, even when it is no. A queue with no response teaches people to stop asking.
- Credit the contributors and keep a maintainer for each component, so ownership does not evaporate the moment the original team moves on.
- Track how much of the product is built from system components. A falling number is the early warning that the contribution path is broken.
A design system that only its own team can change becomes a bottleneck, and bottlenecks get routed around.
Related guides
UX Handbook