Maintain consistency as the product grows.
If no one maintains the standard, the product will gradually drift away from that standard.
As the product grows, the biggest risk is allowing the design assets to drift away from the original intent, accumulating through small details. The way to maintain lasting consistency is to manage the design system as a living product: with an owner, criteria for approving changes, and a shared repository instead of each team creating their own. Sinh Vũ builds the system along with operational guidelines so that the client’s team can maintain consistency without relying on a specific individual.
- many teams build multiple product lines or platforms
- federal model when multiple product groups need to contribute to a common core
- No one owns the system, allowing it to drift with each group creating their own components.
- Tightening everything equally slows down the team.
The larger the product, the easier it is for the design system to drift. Not because the team lacks care. Each small decision slips through the cracks, accumulating over many teams and months. Then one day, looking back, the live product has strayed quite far from the original identity system. Sinh Vũ calls this design drift. This is a management issue, not simply a technical one.
Why does consistency gradually break down?
Consistency does not break in a day. It shatters into small pieces: a slightly off color because no one checked the standard, a letter spacing adjusted arbitrarily because an old file wouldn’t open, a custom interface component because it was unknown that it already existed in the system. Each individual issue seems insignificant. But multiplied across three teams, six months, and two platforms, the result is a live product that no longer aligns with the standard on paper.
The root causes are often one of three: no one is assigned ownership of the system. Or the system is treated as a completed document rather than a product that needs updating. Or people contribute new components without any criteria for filtering.
Manage the system like a living product.
Hike One summarizes succinctly: the design system needs a backlog, a roadmap, and regular feedback loops; it is not just a packaged file left aside. When these three elements are lacking, the system will age while the product continues to run.
Manage the design system like managing a product: it needs ownership, a roadmap, and regular feedback loops.
Hike One, Making a Design System Work at Scale
In practice, this means:
- There is a person or a small group assigned clear responsibilities: who approves new components into the common core, who marks inconsistencies that need fixing.
- There are criteria to decide what is included in the common core and what remains as individual samples for each group.
- There should be regular reviews, not waiting until issues arise to address them.
Choose a scale-appropriate model.
Solitary ownership model: suitable for small teams, startups, or products with few people involved in the system. Quick and concise, but can easily become a bottleneck as the team grows.
Federated model: suitable when there are many product groups. Each group appoints a representative to contribute, but all contributions align with a common core. Speed is maintained, and consistency is overseen.
There is no model that is absolutely correct. The point to decide is: where is your team in that journey, and is the current model still suitable for the current scale?
Layering: what needs tightening, what can breathe.
A common mistake is either tightening everything uniformly or loosening everything completely. Both approaches are harmful: tightening uniformly can prevent the team from engaging with the system, while loosening can cause the brand to break down from the foundation.
Sinh Vũ categorizes by level of influence:
- Brand level (primary color, typography, logo, tone of voice): the strictest approval, changes must go through clearly authorized personnel.
- Common interface component level (buttons, tables, forms): there are criteria for the core, contributions need approval but do not require escalation to the brand level.
- Specific sample level for each group: more flexible, the group decides as long as they use the correct underlying platform.
Clearly define who can propose new components and the criteria for those components to be included in the core versus remaining in the team's library.
Figma, Design System Scaling
Sinh Vũ's viewpoint
Sinh Vũ develops a design system based on an established brand identity and delivers it with specific operational guidelines for the client's team to update independently. The goal is for the team not to rely on a single person or Sinh Vũ to maintain consistency.
This is especially important when the product scales beyond a single website and becomes a platform operated by multiple teams. At that point, what determines consistency is no longer the quality of the design files, but who is managing that system and according to what principles. For projects at this scale, management needs to be discussed in detail based on each client's specific circumstances; there is no one-size-fits-all formula.
Decision checklist
Topic: Maintaining consistency as the product grows. Sinh Vũ guide, 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
Figma Resource Library, Design System Scaling; Hike One, Making a Design System Work at Scale; Nielsen Norman Group, Your Design System Needs an Enforcer. Practical experience from Sinh Vũ Studio.
Frequently asked questions
When to start worrying about managing the design system?
The clearest sign is when there are two or more teams interacting with the system, or when the product expands to a new platform, such as from web to mobile app. At that point, if there is no owner and approval process, each team will create their own components and consistency will gradually break down over time.
Can one person design and maintain the system?
Yes, if your team is still small and few people are involved. But as the team grows, one person managing the system while also doing the work will become a bottleneck, as every change will wait for their approval. At that point, it is necessary to shift to a model with clear criteria so that multiple people can contribute in a controlled manner.
Do you need to tighten the entire system or just part of it?
It doesn't need to be uniformly strict. Elements like primary colors, typography, logo, and tone of voice need the most stringent approval because mistakes here affect the entire system. Specific interface templates for each product group can be more flexible, as long as they adhere to the common foundation.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.