Designers Who RFC

Request for comments (RFC) is a process some engineering teams follow that ensure change proposals are in the open and are considered. We follow this process with Arc Design System, and use it as a method to ensure system changes are thought through. In general, we seek to know these areas:

• Summary: An overall description of the proposed changes.
• Motivation: Why do we seek to change this?
• Detailed Design: What is the design? What are the variants, components, etc. that are needed?
• Documentation: What formal documentation, if any, is available and/or affected by this change?
• Drawbacks: Why shouldn't we do this?
• Backwards Compatibility Analysis: What can happen i
• Alternatives: Were there other avenues explored?
• Open Questions: What do we still don't know?
• Help Needed: Where do we need more assistance to finish or understand this RFC?
• Frequently Asked Questions: A list of FAQs

Key benefits of RFC process:

• Alignment between product, design, and engineering teams.
• Create an artifact that documents key decisions, approaches, and impacts. Encourage collaboration through direct editing and comments.
• Help teams understand how complex a change is, so effective planning can be had.

Workflow:

In our process, RFCs can have two audiences:

1. A Product engineer who uses the design system and are building or updating a component.
2. An Engineer from the design system team, is making updates or creating a new component.

In general, RFCs are encouraged to be as detailed as possible to help all parties involved understand the change.

The process:

1. Contributor creates a branch in the style of rfcs/rfc_name.
2. Contributor creates rfc_name.md and uses a template we provide with the structure outlined above.
3. The team works to add and refine to the RFC.
4. RFC is reviewed.
5. Branch is kept as-is, and will be the end branch the change will occur in, ensuring the RFC is contextually available when in the RFC branch.

Designer's perspective

When working with design systems, it's usually a group effort that goes into building and iterating components and patterns. This is typically a blend of design, engineering, and product, making it the perfect opportunity to create alignment and catch surprises earlier.

Here's a few things for the designer to think about:

General

• It's recommended to create as much design documentation and prototypes to help illustrate complex concepts.
• Designers who are on teams with RFC processes, should spend the time to get acclimated to GitHub's web interface. When just dealing with Markdown files, it's not that scary to collaborate with engineers and provide details within the repo directly.

Variants

• How many variants are there of a component?
• How are these variants named?
• Why are these variants necessary? What function do they serve?

States

• How many states are there?
• How are these states named?
• Why are these states necessary?
• How do these states change?

Modes

• Is this available in light mode?
• Is this available in dark mode?
• Is this a user preference?

Tokens

• What existing tokens can be used?
• What new tokens must be introduced?
• Do new tokens introduce a new naming convention that affects other tokens?

API

• Does the designer have any opinions on how the React component should look and function?
• What properties/variants are built into Figma components?
• Does this component introduce a new naming convention? Are there other components that use similar conventions?

Closing thoughts

If you find that your engineering team is having a hard time maintaining documentation for upcoming work, RFCs may be a good solution for your team. I hope this post inspires you to consider this tool in your toolkit!