Brand design system: why it is needed by a digital team
Further — to the point, without general words about "consistency" and "unified visual language," which are already present in every other article on this topic.
Design system and UI-kit: where the boundary lies
These are not synonyms, although they are constantly confused, and this confusion is expensive — the team buys a UI-kit, but awaits the effect of a design system. A UI-kit is a set of ready-made visual elements: buttons, fields, icons, colors. A design system is a UI-kit plus rules for its use, component code, documentation, and a support process. A UI-kit can be downloaded in an evening. A design system cannot be bought ready-made — it is grown for a specific product and team.
| Parameter | UI-kit | Design system |
|---|---|---|
| What's inside | Library of visual components | Components + code + rules + documentation + change process |
| Who uses it | Designers | Designers, developers, PM, sometimes marketing |
| Does it live independently | Yes, as a file in Figma | No, it requires an owner and regular updates |
| When it's enough | 1 product, team up to 3 people, MVP | 2+ product, 3+ developer/designer, regular release of new screens |
A practical criterion is simple: if a company has one website and one designer — a design system is not needed, a well-done UI-kit will suffice. If there is a mobile app, a web version, a personal cabinet, and landing pages made by different people — without a design system, each new product begins to live its own visual life, and in a year the brand looks as if it were made by three different agencies.
How much does it cost: three scenarios instead of one number
Here competitors usually name the range head-on — "from 500 thousand to several million" — without explaining what it depends on. The difference is in the scale of the task, not in the contractor's greed.
| Scenario | Team | Duration | Budget |
|---|---|---|---|
| Start-up system | 1 designer + 1 frontend developer | 4–8 weeks | from 500 000 ₽ |
| Functional DS for a medium product | designer, developer, product manager | 6–12 months | 1–1,5 million ₽ |
| Corporate Design System for several products | designers, frontend, PM, UX researcher | from 12 months, with continuous support | 2,5 million ₽ and above |
They spent half a year creating the first version of their design system and another one and a half years to translate the entire site onto it — this is a normal proportion: creating the core is faster than migrating the entire product onto the new rules. Migration must be built into the timelines, otherwise management will expect results within a month after the system launch, but will receive them in one and a half years.
How the work of each role changes — not in theory, but by the hour
That's where most articles stop at the abstract 'speeds up processes.' In reality, the mechanics are as follows: the designer in Forpes/Hexa UI used to spend 50–60% of the task time on the task itself, 20–25% on drawing the component from scratch, and 15–20% on searching for a suitable example in old layouts. After implementing the design system, the ratio flipped: 80% of the time — on the task's core, up to 10% — on the component (it's already ready, just needs to be inserted and configured), 10–15% — on reference search, because all examples are in one place.
- Designer stops being a button artist and starts solving user tasks — reusing ready components in Finam and VTB reaches up to 60% when launching new products.
- Developer does not receive a picture, but a specification with ready-made component code — the number of clarifying questions to the designer, according to Compare, decreases by 3 times.
- Product manager It aligns not aesthetics but logic: at Rostelecom, the implementation of co-design — joint work in Figma via Zoom — together with the design system enabled alignment of a ready prototype in one meeting instead of several weeks of correspondence and revisions.
Sravni ultimately assembled layouts 2–3 times faster — not because designers worked faster with their hands, but because they stopped solving problems that had already been solved.
Where to start if you've never had experience
The most common mistake is to start with a UI-kit 'just in case' without a real request from the team. A design system should grow from pain, not from fashion.
- Conduct an audit of existing screens: gather all buttons, fields, cards from the live product into one file. Usually, at this stage, 5–7 versions of the same button become visible — this is the argument for management.
- Identify atoms: colors, typography, grid, spacing. This is the foundation without which any component is assembled by eye.
- Collect the first 10–15 components that are used most often — forms, buttons, cards, modal windows. Don't try to cover everything at once.
- Translate components into code in parallel with design — if the frontend component appears a month after the design mockup, developers will continue to code by the old way.
- Assign a system owner — a person who resolves disputes and approves changes. Without an owner, the system turns into a dump of versions from half a year.
- Launch a pilot on one real product, not on a demo page — only then can you see where the rules don't work in practice.
Tools: how to connect Figma, code, and documentation
A separate mistake is to build a beautiful library in Figma and leave it isolated from the code. Then the developer re-codes what the designer has already drawn, and all time savings disappear at the interface of roles.
| Tool | Role in the system | What it synchronizes with |
|---|---|---|
| Figma | Component library, style tokens, mockups | Exporting tokens into code via plugins (Tokens Studio and similar) |
| Storybook | Live component showcase in code with their states | Direct link to a component from Figma documentation |
| Code repository (React/Vue components) | Single source of truth for production | Versioned, updates are published as npm packages |
| Confluence/Notion | Usage rules, guidelines, change history | References specific versions of Figma and Storybook |
The working chain looks like this: the designer changes the color token in Figma → the change gets into the code via token synchronization → the component in Storybook updates automatically → the developer pulls the new package version into the product. If even one link is done manually and 'sometime,' the system starts to diverge from the real product within a couple of months — and this is the most common reason why design systems die within a year of launch.
Why design systems sometimes fail to work
This is that practical conversation that usually doesn't exist in articles about design systems. The failure rarely happens because of poor component design — it happens because of the process organization.
- The system is built without an owner. After six months, nobody can tell if the component version in production is current, and the team reverts to old habits.
- Design and code develop separately. The designer updated the component in Figma, but the developer didn't know about it — the system becomes a beautiful image that doesn't reflect the real product.
- The system is built 'for the future' without a real product. Abstract components without ties to specific screens are almost always redone from scratch when they reach the real task.
- There is no process for requesting new components. If the designer doesn't know where to turn for a non-standard element, they draw it themselves — and the system begins to fragment into exceptions.
- The team was not trained to use the system. Ready components exist, but they are not used by habit — then the invested money simply doesn't pay off.
A design system pays for itself not at the moment of launch, but after 3–4 months of regular use, when the team stops arguing over trivialities and starts arguing over the product. If this doesn't happen — the problem is almost always not with the system itself, but with the fact that it was implemented and then forgotten, instead of being built into the daily process.
Further — to the point, without general words about "consistency" and "unified visual language," which are already present in every other article on this topic.
Design system and UI-kit: where the boundary lies
These are not synonyms, although they are constantly confused, and this confusion is expensive — the team buys a UI-kit, but awaits the effect of a design system. A UI-kit is a set of ready-made visual elements: buttons, fields, icons, colors. A design system is a UI-kit plus rules for its use, component code, documentation, and a support process. A UI-kit can be downloaded in an evening. A design system cannot be bought ready-made — it is grown for a specific product and team.
| Parameter | UI-kit | Design system |
|---|---|---|
| What's inside | Library of visual components | Components + code + rules + documentation + change process |
| Who uses it | Designers | Designers, developers, PM, sometimes marketing |
| Does it live independently | Yes, as a file in Figma | No, it requires an owner and regular updates |
| When it's enough | 1 product, team up to 3 people, MVP | 2+ product, 3+ developer/designer, regular release of new screens |
A practical criterion is simple: if a company has one website and one designer — a design system is not needed, a well-done UI-kit will suffice. If there is a mobile app, a web version, a personal cabinet, and landing pages made by different people — without a design system, each new product begins to live its own visual life, and in a year the brand looks as if it were made by three different agencies.
How much does it cost: three scenarios instead of one number
Here competitors usually name the range head-on — "from 500 thousand to several million" — without explaining what it depends on. The difference is in the scale of the task, not in the contractor's greed.
| Scenario | Team | Duration | Budget |
|---|---|---|---|
| Start-up system | 1 designer + 1 frontend developer | 4–8 weeks | from 500 000 ₽ |
| Functional DS for a medium product | designer, developer, product manager | 6–12 months | 1–1,5 million ₽ |
| Corporate Design System for several products | designers, frontend, PM, UX researcher | from 12 months, with continuous support | 2,5 million ₽ and above |
They spent half a year creating the first version of their design system and another one and a half years to translate the entire site onto it — this is a normal proportion: creating the core is faster than migrating the entire product onto the new rules. Migration must be built into the timelines, otherwise management will expect results within a month after the system launch, but will receive them in one and a half years.
How the work of each role changes — not in theory, but by the hour
That's where most articles stop at the abstract 'speeds up processes.' In reality, the mechanics are as follows: the designer in Forpes/Hexa UI used to spend 50–60% of the task time on the task itself, 20–25% on drawing the component from scratch, and 15–20% on searching for a suitable example in old layouts. After implementing the design system, the ratio flipped: 80% of the time — on the task's core, up to 10% — on the component (it's already ready, just needs to be inserted and configured), 10–15% — on reference search, because all examples are in one place.
- Designer stops being a button artist and starts solving user tasks — reusing ready components in Finam and VTB reaches up to 60% when launching new products.
- Developer does not receive a picture, but a specification with ready-made component code — the number of clarifying questions to the designer, according to Compare, decreases by 3 times.
- Product manager It aligns not aesthetics but logic: at Rostelecom, the implementation of co-design — joint work in Figma via Zoom — together with the design system enabled alignment of a ready prototype in one meeting instead of several weeks of correspondence and revisions.
Sravni ultimately assembled layouts 2–3 times faster — not because designers worked faster with their hands, but because they stopped solving problems that had already been solved.
Where to start if you've never had experience
The most common mistake is to start with a UI-kit 'just in case' without a real request from the team. A design system should grow from pain, not from fashion.
- Conduct an audit of existing screens: gather all buttons, fields, cards from the live product into one file. Usually, at this stage, 5–7 versions of the same button become visible — this is the argument for management.
- Identify atoms: colors, typography, grid, spacing. This is the foundation without which any component is assembled by eye.
- Collect the first 10–15 components that are used most often — forms, buttons, cards, modal windows. Don't try to cover everything at once.
- Translate components into code in parallel with design — if the frontend component appears a month after the design mockup, developers will continue to code by the old way.
- Assign a system owner — a person who resolves disputes and approves changes. Without an owner, the system turns into a dump of versions from half a year.
- Launch a pilot on one real product, not on a demo page — only then can you see where the rules don't work in practice.
Tools: how to connect Figma, code, and documentation
A separate mistake is to build a beautiful library in Figma and leave it isolated from the code. Then the developer re-codes what the designer has already drawn, and all time savings disappear at the interface of roles.
| Tool | Role in the system | What it synchronizes with |
|---|---|---|
| Figma | Component library, style tokens, mockups | Exporting tokens into code via plugins (Tokens Studio and similar) |
| Storybook | Live component showcase in code with their states | Direct link to a component from Figma documentation |
| Code repository (React/Vue components) | Single source of truth for production | Versioned, updates are published as npm packages |
| Confluence/Notion | Usage rules, guidelines, change history | References specific versions of Figma and Storybook |
The working chain looks like this: the designer changes the color token in Figma → the change gets into the code via token synchronization → the component in Storybook updates automatically → the developer pulls the new package version into the product. If even one link is done manually and 'sometime,' the system starts to diverge from the real product within a couple of months — and this is the most common reason why design systems die within a year of launch.
Why design systems sometimes fail to work
This is that practical conversation that usually doesn't exist in articles about design systems. The failure rarely happens because of poor component design — it happens because of the process organization.
- The system is built without an owner. After six months, nobody can tell if the component version in production is current, and the team reverts to old habits.
- Design and code develop separately. The designer updated the component in Figma, but the developer didn't know about it — the system becomes a beautiful image that doesn't reflect the real product.
- The system is built 'for the future' without a real product. Abstract components without ties to specific screens are almost always redone from scratch when they reach the real task.
- There is no process for requesting new components. If the designer doesn't know where to turn for a non-standard element, they draw it themselves — and the system begins to fragment into exceptions.
- The team was not trained to use the system. Ready components exist, but they are not used by habit — then the invested money simply doesn't pay off.
A design system pays for itself not at the moment of launch, but after 3–4 months of regular use, when the team stops arguing over trivialities and starts arguing over the product. If this doesn't happen — the problem is almost always not with the system itself, but with the fact that it was implemented and then forgotten, instead of being built into the daily process.
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
