How do you handle feedback, contributions, and review?
Keep shared rules reliable through clear issue reporting, ownership, and review.
A design system needs people who handle feedback and review changes. Governance agrees who is responsible, how decisions are made, and how users learn the results, so shared resources remain managed.
Keep these basics in mind
- Feedback reports a problem or suggests an improvement. A contribution proposes or completes a change to shared resources.
- Include the location, steps, and expected result so maintainers can assess and reproduce the problem.
- Review checks actual needs, existing rules, and effects on other pages.
- Teams of different sizes can use different processes, but need clear ownership, decision records, and responses.
See USWDS contribution guidance for reporting and contribution routes and its product values for shared decision criteria.
Bring a suggestion into the system
Illustrative feedback handling
These are hypothetical team records.
| Suggestion | With insufficient information | After adding context |
|---|---|---|
| Button is difficult to use | Problem location unknown | Long labels break layout; fix the shared part |
| Need a special colour | Context unknown | One event needs it; handle locally first |
| Focus is invisible | A statement only | Page and steps supplied; prioritise the operation barrier |
Walk through an example
A user reports an obscured Save button in a narrow window and supplies the page and steps. Maintainers reproduce it on several pages and identify a shared layout rule. Design and development fix and verify it, update guidance, and record the outcome on the original issue.
Limits and common misunderstandings
Open contributions do not mean accepting every suggestion directly. Review is not a maintainer’s personal preference. Use actual tasks, shared rules, and verification as criteria. Small teams need not copy a large company’s approval hierarchy.