Four things to keep the design system from becoming diluted
Most design systems do not fail because of incorrect design, but because no one is assigned to maintain them.
The design system gradually dilutes when treated as a project that ends upon delivery, rather than a living product that requires ownership and maintenance budget. To avoid dilution, four elements must work together: an owner, a change approval process, measurement of application levels, and making the standard path easier than the custom path. Missing any one of these four will cause the system to drift with the urgent tasks of product teams.
- consider the system as a living product with a roadmap and a queue of tasks
- has an owner, an RFC process, and measures application levels
- make the standard easier to navigate than the custom one
- consider deliverables as the end, with no budget for maintenance
- No one is assigned ownership, the system becomes communal.
Most design systems do not fail due to incorrect design. They fail because after approval, no one is given the responsibility to maintain them. Product teams start to create their own versions, documentation becomes increasingly misaligned with reality, and eventually, the entire organization understands that the system only exists in presentation slides. This is not a technical issue but an organizational one.
Why is the design system diluted?
According to Brad Frost in Atomic Design, a design system is not a project with an endpoint but a living product that serves other products. It needs to be continuously nurtured to truly thrive.
The dilution mechanism often occurs in a familiar sequence: a team is rushing to deliver, using standard components is more labor-intensive than coding from scratch, so they create a custom version. The next time another team sees that custom version in the codebase, they copy it. This continues to multiply. When the situational library no longer accurately reflects the actual product, it becomes obsolete, and maintenance falls into makeshift fixes, ruining the original construction.
Four things that must go together
- Clearly assigned owner. Not a vague dual role, not a shared responsibility. When no one takes responsibility, everyone avoids decisions, and the system has no one to uphold it.
- Change approval process. Whenever a component needs to be added, modified, or removed, it must go through a documented approval step. Sinh Vũ calls this an RFC (request for change with reference), meaning a proposed change with justification and an approver. Without this step, the system accumulates exceptions until it no longer resembles its original form.
- Measuring the level of application. Without measurement, you won't know where it is diluted. The metrics to monitor are the ratio of screens using standard components versus custom components, and the number of orphan components generated outside the system with each release.
- The standard path should be easier than a custom one. This is the most overlooked factor. If using standard components is harder than coding from scratch, the product team will abandon the system, not because they do not want to comply, but because they are under pressure to deliver.
When to prioritize tasks
If there are no applied metrics yet: set up measurement first. It doesn't have to be complicated; a manual tracking sheet every quarter is enough to start knowing where you stand.
If you cannot allocate internal ownership: the system will dilute over time; it is not a question of whether it will happen, but rather how quickly. At this point, an external support package is a more practical option than trying to manage it alone without personnel.
Common errors after completion
- Once approval is done, consider the work complete, do not allocate a maintenance budget for the next phase.
- Only keep the beautiful Figma version, while the code gradually drifts with each product. When Figma and code diverge, teams follow the actual code, not Figma.
- Add components en masse after each request but do not clean up the old ones, resulting in a bloated repository with decreasing reuse rates.
- No one is assigned ownership; the system is a shared one, so no one truly holds it.
When the case library no longer accurately reflects the real product, it becomes obsolete, and maintenance falls into makeshift repairs, undermining the original construction.
Brad Frost, Atomic Design, ch.5
The viewpoint of Sinh Vũ
Sinh Vũ establishes a dilution prevention mechanism right within the project, rather than addressing it later. Specifically, this includes a one-to-one connection between Figma and code through Figma Code Connect, an RFC process for all system changes, and a set of metrics applied to each team to identify dilution before it spreads.
The maintenance phase within Sinh Vũ's working framework exists to nurture the periodic system, avoiding teams quietly reverting to manual work. However, Sinh Vũ does not promise a self-sustaining system. The survival or failure depends on the owner and the review pace maintained by the client team, not on the quality of the initial draft.
If you are considering whether to invest in a design system, the right question to ask first is not "is this design system beautiful" but "do we have the people and budget to maintain it?" Only if you have an answer to that question should you proceed.
Decision checklist
Topic: How to ensure the system does not dilute over time. 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
Brad Frost, Maintaining Design Systems (Atomic Design, ch.5); Brad Frost, The Design System Ecosystem.
Frequently asked questions
How many people are needed to maintain a design system?
There is no fixed number suitable for all organizations, but the principle is to have at least one clearly assigned person, not a vaguely shared responsibility. If you cannot arrange an internal person, an external partnership package is a more practical option than leaving the system without ownership.
Figma is already beautiful and consistent; does that count as a stable system?
Not enough. Figma is the drawing, while the product runs on code. When the two diverge, teams will adapt based on the actual code rather than the beautiful Figma design. A good sign is when Figma and code reflect the same state, not when Figma looks one way and the product looks another.
How can you tell if the system is becoming diluted?
The clearest sign is when the number of custom components appearing outside the system increases after each rush of releases. If you haven't measured yet, start by manually reviewing: count how many screens are using standard components and how many screens are using custom versions.