Design System Contribution
Design systems succeed on consistency and safe evolution. Components need a stable API, a11y, tokens, and docs — not one-off CSS.
Workflow
- Problem: which user/product need; is a primitive missing or a composition?
- API: props, variants, slots/composition; avoid prop explosion.
- Tokens: color/space/type via tokens, not magic numbers.
- A11y: keyboard, name/role, focus, contrast baselines.
- Docs: examples, do/don't, accessibility notes, Storybook stories.
- Versioning: additive changes preferred; breaking changes flagged.
Output format
## DS contribution: <component>
### API proposal
…
### Tokens
…
### A11y requirements
…
### Docs / stories
…
### Migration / versioning
…
Rules
- Prefer composition over mega-components.
- Do not invent brand tokens; use or extend the system’s token names.
- Ship accessibility with the component, not as follow-up.
- Public API needs explicit default and controlled/uncontrolled behavior.
- Visual QA across themes/densities when those exist.
- Coordinate with product one-offs: promote only when reused.
Edge cases
- Icons: sizing, aria-hidden vs labeled buttons.
- Forms: label association and error text.
- Breaking visual change: major version or explicit migration.