Design-system collaboration fails when ownership is implicit. A designer may own visual intent, a product manager may own content, and an engineer may own implementation, but nobody knows who decides whether a token change is local or system-wide.
Removing a ticket does not resolve that ambiguity. It only makes a faster path to an unclear decision.
Quick answer: define who may propose each change, who is accountable for its outcome, who must be consulted, and who approves the source diff. Use one review process for ticket-originated, engineer-authored, and tool-assisted changes.
Classify the Change Before Assigning It
Design-system work falls into different risk classes:
| Change class | Example | Default owner |
|---|---|---|
| Content instance | Label on one page | Product owner |
| Component instance | Existing size or variant prop |
Product team |
| Token usage correction | Replace arbitrary spacing with approved token | Design-system owner |
| Shared component behavior | Change default padding for every card | Component code owner |
| New token or variant | Add a new semantic color or button state | Design-system governance group |
| Application logic | Change state, data, permissions, or routing | Engineering owner |
The key distinction is blast radius. A local instance correction and a shared default change may look identical in one browser view but require different reviewers.
A Lightweight RACI
RACI means Responsible, Accountable, Consulted, and Informed. Use it to prevent review from becoming a group decision with no clear owner.
| Activity | Designer / system owner | Product manager | Product engineer | Code owner |
|---|---|---|---|---|
| Define visual standard | A/R | C | C | I |
| Define page-specific content | C | A/R | I | I |
| Propose local visual correction | R | C | C | A |
| Assess shared-component impact | C | I | R | A |
| Run implementation checks | I | I | R | A |
| Approve source change | C | C | R | A |
| Approve release | I | I | R | A |
This table is a starting point. A team with dedicated accessibility, content-design, security, or release roles should add them where their approval is required.
Two rules keep the model useful:
- Give each activity one accountable owner.
- Do not make the change author its only approver.
Govern the Design-System Decision
This article governs classification, ownership, and escalation for design-system work. It does not define a second approval process. Once a change has an owner and scope, use How Teams Review UI Changes From Non-Engineers as the canonical branch, evidence, CI, and approval workflow regardless of who authored it.
Before implementation, the accountable owner determines blast radius:
- Is selected element an instance or shared component?
- Does existing token or variant already express intended design?
- Which usages may change?
- Does request touch logic, accessibility behavior, or data?
Shared defaults, new variants, and uncertain impact move to engineer-led work. A visual editing tool does not remove that escalation path.
Design-system governance contributes decisions that general review cannot infer: whether existing standard already covers request, whether change belongs at instance or shared layer, and which consumers form blast radius. Record those decisions with proposal so reviewers can evaluate implementation against intended system rule.
Example Decision Path
This example is illustrative.
A reviewer sees 24px padding on one card where system guidance specifies spacing-4.
- Designer identifies mismatch and links rule.
- Author determines whether value lives on page instance or shared card component.
- If local, author proposes token replacement and captures relevant viewports.
- If shared, code owner checks all usages before deciding whether default should change.
- CI validates code; design reviews rendered result; code owner approves or requests revision.
No elapsed-time promise is implied. Shared impact can make a visually small request technically substantial.
Use Tickets for Coordination, Not Translation
“Without tickets” should mean that a ticket is not mandatory when author can produce a complete, reviewable change. Tickets remain useful for prioritization, cross-team dependencies, risky migrations, and work that cannot proceed immediately.
Avoid two extremes:
- Requiring engineering to translate every visual observation into code
- Letting tool-assisted changes bypass ownership and review
Pull requests can become intake artifact for narrow changes because they combine intent, implementation, evidence, and approval in one place. Larger changes still benefit from an issue or design proposal before code exists.
Operating Rules
Adopt concise rules:
- Classify local versus shared impact before editing.
- Keep one accountable owner per decision.
- Require code-owner approval for shared components and tokens.
- Require visual evidence for visual changes.
- Keep auth, data, billing, permissions, and infrastructure engineer-owned.
- Use same CI and branch protection regardless of author.
- Escalate uncertain scope instead of guessing.
This model makes collaboration explicit. Designers own standards. Product managers own product intent. Engineers own technical integrity. Code owners control shared-system changes. Tools can reduce translation work, but responsibility stays with people.
For PM self-service eligibility and rollout, read How PMs Can Edit a Website Without Developers. For approval, use the canonical review workflow for UI changes from non-engineers.
Try Frontman for browser-to-source editing inside this review model, and read the security boundaries before team rollout.