RFC in design systems: when is approval process needed?
Not every change requires a discussion, but not every change can be made unilaterally.
RFC (Request for Comments, proposal and feedback process) is a way for a change to be stated, discussed, and approved before being implemented in the system. You need an RFC when the system is open for multiple teams to contribute, or when there is a significant change that could disrupt the current standards. A small system with a single owner does not require a heavy process; a quick note and approval are sufficient.
- open system for multiple teams to contribute from outside the core team
- Changes that affect the original token or cause a breaking change.
- small system, one owner, minor and safe changes
- Apply a heavy process for every change, even hindering small adjustments.
RFC (Request for Comments, proposal and feedback process) is not an administrative procedure. It is a mechanism for clearly stating, discussing, and responsibly approving a significant change before it affects everyone using the system. The question is not "should we do an RFC?" but rather "how significant is this change and how many parties are affected?"
What is RFC in practice
The RFC model is popular in open-source programming, adopted by the Rust and Ember communities for adding major features to languages and frameworks. Nathan Curtis proposed a design system that follows this approach: preliminary discussions first, then an official proposal with descriptions, reasons, and scope, and finally, the execution and review of the complete version.
In the context of a design system, an RFC typically consists of three basic steps:
- Proposal: those who want to change should write a description, reasons, and scope of impact.
- Handover: the core team and stakeholders provide feedback, ask questions, and identify risks.
- Approval: the authorized person finalizes acceptance, adjustments, or rejection, with reasons recorded.
The weight of each step varies depending on the scale and the number of teams using the system.
Deciding factors for the process level
There is no one-size-fits-all solution. You need to balance according to four factors:
- Change scale: adding a different icon can change the entire color scale of a chart or adjust the API of a shared component. Each type requires different levels of control.
- Who proposes: someone in the core team is familiar with the system principles different from the external product team contributing for the first time.
- Risk of disruption: Will changes cause errors in places using that component, or is it completely safe?
- Necessary transparency: Do people need to see proposals, reasons, and decisions, or just the core team needs to know?
When a full RFC is needed, when is a quick review sufficient
Quick approval is sufficient when: the system is small, there is one owner, changes are minor, and there is no risk of chain reactions. Noting the reason, who approved, and the date of application is enough control without creating unnecessary procedures.
Brad Frost emphasizes the need for a public governance process to balance openness for contributions and maintaining common standards. Public here does not mean complex, but rather that everyone knows where the proposal stands, who decides, and why.
Common mistakes when designing processes
- Imposing a heavy process for every change: small tasks get stuck, and the team loses motivation to contribute.
- No processes at all: Anyone can change things, leading to a system that loses its standards over time without anyone noticing until it breaks down severely.
- Open contributions without a reviewer: proposals pile up, no one finalizes, the proposer gets discouraged and stops participating.
- Subjective approval: There are no clear criteria to determine if this change truly belongs to the system, leading to each approval being a debate from the beginning.
The viewpoint of Sinh Vũ
In the design and operational package with management, Sinh Vũ delivers an RFC process suitable for the client's team size: every change has a proposer and an approver, ensuring the system evolves in a controlled manner rather than drifting. The focus is to allow the client team to propose and add components while maintaining standards, without relying on a single person who knows the entire system.
The weight of the process is balanced according to team size and the number of parties involved. Sinh Vũ does not apply the exact framework of large corporations to a team of five. The main principle: multiple parallel levels, a fast track for small tasks, a comprehensive track for larger tasks with risks.
Contributions are any proposals, designs, source code, documents, or assets of a new feature made by someone outside the core team and released for others to use. Therefore, a clear acceptance framework is needed.
Nathan Curtis, Defining Design System Contributions, EightShapes
Decision checklist
Topic: The process of proposing and approving RFC changes in the design system. Sinh Vũ Handbook, sinhvu.com
Select each item you find appropriate, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Nathan Curtis, Defining Design System Contributions (EightShapes). Brad Frost, A Design System Governance Process.
Frequently asked questions
My system only has one team, do I need an RFC?
If only a core team uses and owns it, you do not need a full RFC. Noting the reasons for changes, who approves them, and when to apply is sufficient. A heavy RFC only generates value when multiple parties contribute or depend on the system.
What sections should an RFC include?
At a minimum, it includes: a description of the change, reasons for the proposal, scope of impact, and who approves it. For significant changes, it's advisable to include a draft for discussion before the official proposal. There's no need to replicate the exact framework of large corporations for small teams.
Who has the authority to approve the RFC?
The core team of the design system is the final approver. The most important criterion is: does this change truly belong to the system's scope, or is it just a specific need of one product? If the core team does not have enough authority to approve, do not open contributions widely, as proposals will pile up without anyone finalizing them.