Brand design system: how to connect identity with product
Design system from scratch or a patch on an existing brand — the difference in outcome
Most companies follow the same path: first they draw a logo, color palette, and guidelines, then they hand everything over to developers who have already programmed something. The design system in this model appears as a rescue tool — an attempt to bring order to the chaos of inconsistent components. This works, but it is expensive and slow because every mismatch between the brandbook and the code has to be manually cleaned up.
The second approach is to build the design system simultaneously with identity development, even at the stage when the brand designer chooses the accent color. In this case, the decision 'our main blue is #0070BB' immediately becomes a token that goes into both the brandbook and the code in one move. There is no need to later 'translate' visual identity into the language of interfaces — it is initially described in a language understandable to both sides.
| Criterion | Postfactum design system | Design system from scratch |
|---|---|---|
| Moment of implementation | After the product launch, when discrepancies have accumulated | In parallel with identity development |
| Source of truth | Brandbook and code exist separately | Unified token system for both |
| Speed of scaling | Each brand change requires manual synchronization | Token change is automatically propagated everywhere |
| Support cost | Grows with each new product or direction | Remains stable due to architecture |
A design system becomes a critical necessity not 'when the team has grown', but at a specific moment: when a product gets a second platform or a second brand under the same legal entity. While it's just one site and a team of three people, a brandbook in PDF format is quite sufficient. As soon as the discussion turns to the web, a mobile app, and partner widgets all at once — without a single source of tokens, divergence is guaranteed within the first two months.
Three levels of tokens: how to connect a brand designer's solution with a button in the code
The key mistake is to treat design tokens as simply 'variables for color'. In reality, this is a mechanism for translating brand strategy into code, and it works through three levels of hierarchy.
- Primitive tokens — raw values without meaning, just data:
#0070BB,16px,Inter. - Semantic tokens — the same value but with a role in the system:
action-color,text-primary. Here, the brand designer's solution ('the main color should be associated with action') first gets a name that is understandable to a developer. - Component tokens — binding to a specific interface element:
c6ButtonPrimary. It is at this level that abstract identity becomes a pixel on the user's screen.
Without a middle layer, the system collapses: changing the corporate color means finding and rewriting the value in hundreds of places. With a well-structured hierarchy, rebranding the color is simply editing one primitive token, which cascades to update all components.
Synchronizing the brandbook and code: two tools against one gap
A living brandbook differs from a static PDF in that changes in one place automatically appear in another. Technically, this is solved through a combination of Figma → Git → Code, with plugins Tokens Studio or Specify serving as intermediaries.
- The brand designer sets token values in Figma Variables — this is the only place where the 'source of truth' for visual solutions is stored.
- Tokens Studio exports tokens to JSON and synchronizes them with a Git repository.
- Project build pulls in these files and generates CSS variables or objects for native development.
- Changing a token in Figma triggers a pull request — the development team sees the diff and confirms the update.
The difference from a manual approach is fundamental: a designer changes a button color in Figma, and in one pull request this value appears in all interfaces where this token is used — without calls and writing tickets for 'fixing the shade'.
Scaling across multiple brands: why one system is better than five brandbooks
The problem of multiple brandbooks is especially acute for companies with a brand portfolio. X5 (Pyaterochka, Perekrestok) solved it through tokens in Figma Variables: one personal account service adapts to different brandbooks by switching the mode with one button — variables are swapped, components remain the same.
MegaFon built a three-tier architecture differently — not through mode switching, but through inheritance:
- Core library — basic components, the brand's 'DNA', unchanged across all directions.
- Base library — components for main interfaces, inheriting from Core.
- Directional libraries — B2C, B2X, TV and others, each with its own communication style, but on a common foundation.
The difference between the two models is not in technology, but in the task: X5 needs switching between fully independent brands, while MegaFon requires controlled variability within one brand with different audiences. The choice of architecture should be based on the portfolio structure, not on what 'other companies did'.
Economy: what the lack of integration really costs
The argument 'it's expensive to do it all at once' is broken by the numbers. Yandex, thanks to a unified UI kit and CSS library, reduced task completion time by three times and saved 2,3 million rubles. For a company of medium size — 5 designers and 10 developers — with an investment of 30% of time in developing the system, the return is +170% ROI for designers, +120% for developers, and +135% overall, that is 2,70 dollars for every dollar invested over five years.
| Indicator | Without a single token system | With a three-tier system |
|---|---|---|
| Time to approve color/font changes | Days, manual verification of each screen | Hours, automatic cascade |
| Brand inconsistency across platforms | Accumulates with each release | Excluded by architecture |
| ROI over 5 years (example 5 designers / 10 developers) | Not measured, losses hidden in reworks | +135%, 2,70$ on 1$ |
This is not theoretical benefit. Every hour spent by a designer manually 'tuning to the brand' is an hour that the token system could have given for free, through automatic inheritance of values. Companies that postpone implementation until 'when there is time' usually arrive at this decision only after a painful rebranding, where recalculating all unsynchronized components takes months.
Design system from scratch or a patch on an existing brand — the difference in outcome
Most companies follow the same path: first they draw a logo, color palette, and guidelines, then they hand everything over to developers who have already programmed something. The design system in this model appears as a rescue tool — an attempt to bring order to the chaos of inconsistent components. This works, but it is expensive and slow because every mismatch between the brandbook and the code has to be manually cleaned up.
The second approach is to build the design system simultaneously with identity development, even at the stage when the brand designer chooses the accent color. In this case, the decision 'our main blue is #0070BB' immediately becomes a token that goes into both the brandbook and the code in one move. There is no need to later 'translate' visual identity into the language of interfaces — it is initially described in a language understandable to both sides.
| Criterion | Postfactum design system | Design system from scratch |
|---|---|---|
| Moment of implementation | After the product launch, when discrepancies have accumulated | In parallel with identity development |
| Source of truth | Brandbook and code exist separately | Unified token system for both |
| Speed of scaling | Each brand change requires manual synchronization | Token change is automatically propagated everywhere |
| Support cost | Grows with each new product or direction | Remains stable due to architecture |
A design system becomes a critical necessity not 'when the team has grown', but at a specific moment: when a product gets a second platform or a second brand under the same legal entity. While it's just one site and a team of three people, a brandbook in PDF format is quite sufficient. As soon as the discussion turns to the web, a mobile app, and partner widgets all at once — without a single source of tokens, divergence is guaranteed within the first two months.
Three levels of tokens: how to connect a brand designer's solution with a button in the code
The key mistake is to treat design tokens as simply 'variables for color'. In reality, this is a mechanism for translating brand strategy into code, and it works through three levels of hierarchy.
- Primitive tokens — raw values without meaning, just data:
#0070BB,16px,Inter. - Semantic tokens — the same value but with a role in the system:
action-color,text-primary. Here, the brand designer's solution ('the main color should be associated with action') first gets a name that is understandable to a developer. - Component tokens — binding to a specific interface element:
c6ButtonPrimary. It is at this level that abstract identity becomes a pixel on the user's screen.
Without a middle layer, the system collapses: changing the corporate color means finding and rewriting the value in hundreds of places. With a well-structured hierarchy, rebranding the color is simply editing one primitive token, which cascades to update all components.
Synchronizing the brandbook and code: two tools against one gap
A living brandbook differs from a static PDF in that changes in one place automatically appear in another. Technically, this is solved through a combination of Figma → Git → Code, with plugins Tokens Studio or Specify serving as intermediaries.
- The brand designer sets token values in Figma Variables — this is the only place where the 'source of truth' for visual solutions is stored.
- Tokens Studio exports tokens to JSON and synchronizes them with a Git repository.
- Project build pulls in these files and generates CSS variables or objects for native development.
- Changing a token in Figma triggers a pull request — the development team sees the diff and confirms the update.
The difference from a manual approach is fundamental: a designer changes a button color in Figma, and in one pull request this value appears in all interfaces where this token is used — without calls and writing tickets for 'fixing the shade'.
Scaling across multiple brands: why one system is better than five brandbooks
The problem of multiple brandbooks is especially acute for companies with a brand portfolio. X5 (Pyaterochka, Perekrestok) solved it through tokens in Figma Variables: one personal account service adapts to different brandbooks by switching the mode with one button — variables are swapped, components remain the same.
MegaFon built a three-tier architecture differently — not through mode switching, but through inheritance:
- Core library — basic components, the brand's 'DNA', unchanged across all directions.
- Base library — components for main interfaces, inheriting from Core.
- Directional libraries — B2C, B2X, TV and others, each with its own communication style, but on a common foundation.
The difference between the two models is not in technology, but in the task: X5 needs switching between fully independent brands, while MegaFon requires controlled variability within one brand with different audiences. The choice of architecture should be based on the portfolio structure, not on what 'other companies did'.
Economy: what the lack of integration really costs
The argument 'it's expensive to do it all at once' is broken by the numbers. Yandex, thanks to a unified UI kit and CSS library, reduced task completion time by three times and saved 2,3 million rubles. For a company of medium size — 5 designers and 10 developers — with an investment of 30% of time in developing the system, the return is +170% ROI for designers, +120% for developers, and +135% overall, that is 2,70 dollars for every dollar invested over five years.
| Indicator | Without a single token system | With a three-tier system |
|---|---|---|
| Time to approve color/font changes | Days, manual verification of each screen | Hours, automatic cascade |
| Brand inconsistency across platforms | Accumulates with each release | Excluded by architecture |
| ROI over 5 years (example 5 designers / 10 developers) | Not measured, losses hidden in reworks | +135%, 2,70$ on 1$ |
This is not theoretical benefit. Every hour spent by a designer manually 'tuning to the brand' is an hour that the token system could have given for free, through automatic inheritance of values. Companies that postpone implementation until 'when there is time' usually arrive at this decision only after a painful rebranding, where recalculating all unsynchronized components takes months.
Recent articles
MegaFon, BMW, VTB and more 240+ companies. See how it looks in the showcase reel:
Our branding agency is approached to order:
Branding agency services
