Multi-brand group: how to organize a common design system
Using a shared codebase does not mean using a shared design. The question is how you separate the unique parts without creating multiple parallel systems.
Organizations follow a three-tier token architecture (variable design units): a core shared across the group, with each brand only overriding its own theme layer. Regarding personnel, start with a centralized team and gradually shift to a federated model as each brand builds a strong enough team to contribute back. This is the level that truly requires formal governance, not just a component library on a shared server.
- multiple brands using shared code, need for three-tier tokens and management
- each brand has its own strong team to contribute back (federation)
- has unfortunately created many disparate systems, needs to unify them first
- Branch out each brand into its own system, leading to multiple unsynchronized systems after a few quarters.
- do not set the name region in the token, cannot separate common and private parts
When a corporation has multiple brands using the same source code, the question is not whether they can share it, but how to separate the parts so that two years later the system remains consistent. Without clear architecture and governance from the outset, the result is almost certain to be each team handling things their own way, and the shared system becomes a fiction on paper.
Three-tier token architecture
The foundation of every design system serving multiple brands is tokens (design variable units such as colors, spacing, font sizes) divided into three clear tiers:
- Primitive level: All raw values of the corporation, for example, all colors in the main color palette, all distance tiers. This level is not used directly by anyone.
- Semantic level: Assigns meaning to raw values, for example, "primary button color", "warning background color". This is the core layer used consistently across all brands.
- Theme level: Each brand has its own directory, only overriding the semantic values that need differentiation. Brand A has a primary button color of blue, while Brand B chooses deep red; the core remains unchanged.
The principle of naming tokens also requires a namespace layer to differentiate: which system, which brand, which domain. Failing to do this means that after a few months, the token of one brand may be overwritten by another brand without anyone noticing.
Team model: centralized or federal
In practice, most corporations should start with a centralized model and gradually shift to a federal model once each brand understands the system and has individuals who can contribute responsibly.
Management: an indispensable part
At a scale with multiple brands, the design system is no longer purely a technical issue. Two minimum requirements are needed:
- RFC process (Request for Comment): Any changes to the core must go through this step. Who proposes, who approves, and the timeframe for brands to respond. Without this step, a team modifying the core for their needs may inadvertently disrupt the experience of other brands.
- Measuring adoption: Knowing which teams are actually using the system and which teams have quietly reverted to manual processes. Without measurement, you won't know, and without knowledge, you can't make corrections.
A design system without governance is just a component library waiting to fall apart.
Nathan Curtis, EightShapes
Common errors in corporations
- Each brand has its own version of a fork: initially it seems flexible, but after a few quarters, each version goes in a different direction, requiring multiple updates and fixes.
- There is a component library but no governance: arbitrary changes, this brand alters another brand without any warning mechanism.
- Do not place the namespace in the token: mixing the common and private parts makes it impossible to separate them cleanly later.
- When multiple parallel systems exist for too long without a consolidation plan: maintenance costs multiply, and consistency gradually decreases.
The viewpoint of Sinh Vũ
This is the highest level a design system can achieve. Sinh Vũ's approach is to create tokens according to DTCG standards (Design Token Community Group, an open token format developed by the design community) with a shared core and a separate theme layer for each brand, along with an RFC process so that every change has a clear proposer and approver.
Regarding implementation, Sinh Vũ typically selects a sample product to transition to the system first, verifying the architecture in practice before scaling to other brands. This approach helps identify issues early rather than rolling out broadly and then discovering shortcomings.
A practical note: a system can be built very well, but without a manager to maintain and evolve it over time, the system will gradually be neglected. At the corporate scale, this is an internal coordination challenge that is just as important as the technical challenge. You should carefully consider the team structure and maintenance budget before finalizing the project scope.
Decision checklist
Topic: How to organize a multi-brand group using a shared codebase. 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, The Many Faces of Themeable Design Systems. Nathan Curtis, Team Models for Scaling a Design System and Consolidating Design Systems (EightShapes). Practical experience from Sinh Vũ Studio.
Frequently asked questions
Why not allow each brand to fork (create a separate branch) its own version of the system for convenience?
A fork may seem quick, but after a few quarters, each branch goes in a different direction, requiring multiple fixes for security or platform updates. More importantly, brand identity begins to drift without anyone noticing until customers recognize the inconsistencies. The three-tier token architecture was created specifically to address this issue: the common part is only updated once, while the unique parts for each brand are kept separate.
What does governance look like in practice?
At a minimum, you need two things: an RFC (Request for Comment) process to ensure no one modifies the core without notification, and a set of adoption metrics to know which teams are quietly deviating from the system. Sinh Vũ often recommends adding a regular maintenance package after implementation to sustain these two aspects, as without a manager, even the best systems will gradually decay.
When should old systems be consolidated instead of starting from scratch?
If the current systems are overlapping, meaning components with the same function appear in many places with different names and behaviors, then consolidating is usually cheaper than building new ones. The strategy is to inventory all existing components, consolidate the stable parts into the core, and gradually eliminate parallel versions. Building new ones only makes sense when the old system has too much technical debt that consolidating would cost more than rebuilding.