Changing the system: when you need an approval process
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 the language and framework. Nathan Curtis proposed that design systems learn from this approach: preliminary discussions first, then a formal proposal with description, rationale, and scope, and finally, the implementation and approval of the complete version.
In the context of the design system, 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 decision-maker finalizes acceptance, adjustments, or rejection, with reasons documented.
How heavy each step should be depends on the scale of the change 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:
- Scope of change: adding a completely different icon changes the entire color scale of a chart or adjusts the API of a shared component. Each type requires a different level 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 breaking: does the change cause errors in places currently 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.
Nathan Curtis defines contributions as a way to help establish a clear framework for acceptance:
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: Who proposes and who approves when you want to change a design system. Sinh Vũ handbook, sinhvu.com
Tick each item that applies or that you can already answer, 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 should include: a description of the change, the rationale for the proposal, the scope of impact, and the decision-maker. For significant changes, a draft should be added for discussion before the official proposal. There is no need to directly replicate the framework of a large corporation into a small team.
Who has the authority to approve the RFC?
Typically, the core team of the design system should have one person designated to make the final decision, preventing any re-decisions in each meeting. The most important criterion is: does this change truly fall within the scope of the system, or is it just a specific need of a product? If there is not a strong enough core team to approve, do not open contributions widely, as proposals will pile up without anyone finalizing them.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.