Design System Governance: A Process for Evolution
Design system governance is a process for when components don't meet a team's needs. It guides teams on whether to create a one-off "snowflake" or contribute a new component back to the system. The footgun is letting teams "find a way," leading to chaos.
Why it exists
Product teams are driven to ship features. If a design system doesn't meet their immediate needs, they won't stop working; they will find a way around it. This often means hacking styles, creating one-off components, or abandoning the system entirely. Governance exists to prevent this divergence, which leads to system obsolescence and accrued debt. It provides a structured, collaborative process for evolving the system to meet real-world product needs.
The mental model
Think of governance as a city's zoning and permit process. Without it, anyone can build anything, leading to chaos. With it, there's a clear procedure to propose new construction. The proposal is reviewed to see if it's a unique, one-off structure (a "snowflake") or a common need that should be standardized for everyone (a new, official building type). This process channels development pressure into sustainable growth for the entire system, rather than letting it fracture.
How it works
The process begins when a product team finds a gap in the design system. First, they contact the design system team via a clear support channel like Slack or Jira. Second, the teams discuss the problem to see if an existing solution was missed or if new work is truly needed. Third, if new work is required, they classify it. Is it a "snowflake"—a component unique to one product—or a core system addition? Fourth, snowflakes are built and managed by the product team, following guidelines to track them. Core additions are added to the design system's backlog. Finally, the work is prioritized and prototyped, with ownership depending on urgency and resources.
When to use it
Implement a governance process as soon as a design system serves multiple teams. It is critical in large organizations where communication is complex. The process should be triggered whenever a team can't find a component they need, an existing component is insufficient for their use case, or they simply have questions about how to proceed. It turns potential friction into a moment of productive collaboration.
When not to use it
A highly formal process is overkill for a solo developer's project or a small, single-team product where informal communication is fast and effective. If your "system" is just a style guide for one app, you don't need a multi-step governance model. The goal is to manage complexity across teams, not to add bureaucracy where none is needed.
One canonical example
A product team building a new feature needs a card component that users can dismiss. The design system has a card, but no dismissible variant. Following the governance process, the team contacts the system owners. They agree that dismissible cards are a common, reusable pattern. The work is classified as a core system enhancement, not a snowflake. A task to add a dismissible variant to the card component is added to the design system backlog, prioritized, and eventually shipped for all teams to use.
Interview question
What is the primary problem design system governance aims to prevent in an organization?
- a.The design system failing to adapt quickly enough to new technological advancements.
- b.Product teams independently creating custom, inconsistent components, leading to system divergence and technical debt.Correct
- c.Product development slowing down due to the formal process of requesting new components.
- d.Design system teams becoming overwhelmed by a high volume of feature requests.
Why? this is the answer
The card states that governance exists to prevent product teams from 'hacking styles, creating one-off components, or abandoning the system entirely,' which leads to 'divergence, system obsolescence and accrued debt.' Option C is incorrect because while processes can add overhead, governance's primary aim is to manage complexity and prevent chaos, not to inherently slow down development.
Just read this? Test yourself on what you have been reading.
Read the original → bradfrost.com
- #design system
- #governance
- #frontend
- #ui engineering
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles