Maintain consistency as the product grows.
It's not about a lack of standards, but rather that no one maintains those standards, causing the product to gradually fade.
As the product grows, the biggest risk is not a lack of design assets but allowing them to drift away from the original intent through small accumulated details. The most sustainable way to maintain consistency is to manage the design system as a living product: with an owner, criteria for approving changes, and a shared reuse space instead of each team creating their own. Sinh Vũ builds the system along with operational guidelines so that your 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. This is not due to a lack of care from the team, but because each small decision slips through the cracks, accumulating across many teams and months, until one day we look back and see the product has deviated quite far from the original identity. Sinh Vũ calls this design drift, and it is a management issue, not just a technical one.
Why does consistency gradually break down?
Consistency does not break in a day. It breaks into small pieces: a slightly incorrect color because no one checked the standard, a letter spacing adjusted arbitrarily because an old file couldn’t be opened, a custom interface element because it was unknown that it already existed in the system. Each individual issue seems insignificant. But multiplied across three groups, six months, and two platforms, the result is a real product in use, and the standards on paper no longer point to the same thing.
The root error is usually one of three: no one is assigned ownership of the system, the system is treated as a completed document rather than a product that needs updating, or everyone contributes new components without any criteria for filtering.
Manage the system like a living product.
Hike One summarizes: a design system needs a backlog, a roadmap, and regular feedback loops, not just a packaged file left aside. Without these three elements, 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 for multiple teams to operate. At that point, the most consistent factor is no longer the quality of the design files, but who is maintaining the system and according to what principles. For projects at this scale, management needs to be discussed in detail according to each client's specific realities; there is no one-size-fits-all formula.
Decision checklist
Topic: Maintaining consistency as the product grows. Sinh Vũ guide, 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
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.