Brand design system: from logo to digital interfaces

A design system, brand book, and UI kit are different layers, and confusing them is expensive

At the start, almost all companies make the same mistake: they order a brand book and think that the design system is ready. It's not. A brand book is responsible for the brand's meanings and emotions — mission, communication tone, logo, and its protective field. A UI kit is a set of ready-made visual elements: buttons, input fields, cards. A design system is an overlay over both: it adds rules, tokens, documentation, and a decision-making process that outlives any redesign.

What to do first? If a company has one product — start with a UI kit based on an existing brand book; a full design system here is excessive. If there are three or more products, or the ecosystem is growing — build the design system right away, otherwise the products' UI kits will diverge within six months of parallel development.

Design tokens: how one variable synchronizes design and code

Tokens are named variables that store values for color, font, margin, and corner radius. Not "#FFCC00", but "color-brand-primary". Salesforce was the first to systematically apply this approach, and it literally revolutionized the industry: designers and developers stopped manually synchronizing values, copying hex codes from mockups to code.

Technically, this has been greatly simplified with the introduction of Local Variables in Figma — now tokens are stored in one place and automatically synchronize into the code, without manually exporting JSON files as was done before.

Dark theme is the best test to see if your token system is set up correctly. If you have hardcoded text color, switching themes breaks everything manually, component by component. If the color is tied to a token like 'text-primary', which changes value depending on the theme — the switch happens automatically. A telling example is the Mediascope design system, where the brand's lemon-yellow text color on a light background is automatically replaced with a mustard color, because pure lemon on white is hard to read. The color here works according to a contrast algorithm, not as a static value — and this is the correct principle for any system that cares about accessibility (WCAG).

Case: how a design system evolves into a platform — on the example of a banking ecosystem

While the company has only one digital product, the design system remains a dictionary of components: button, input, card. The problem begins when there are five, ten, or fifteen products — as happened with Gazprombank and Banka UI or with X5 and 'Pyaterochka'. Each product team wants to customize the product card to fit their logic, and if the system is not architecturally prepared for this, dispersion begins: the same entity looks different in the app, on the website, and in the personal account.

The solution is a second level of abstraction. The system stops being just a set of components and becomes a platform with ready idioms: for example, a product card is not described as one rigid template, but as a construction with clearly defined customization points — what can be changed (text, image, badges), and what cannot be changed (margins, element hierarchy, minimum touch area). A similar principle is implemented at MEGAFON: their system is divided into a Core level — basic styles and components shared across the entire company — and Product libraries, where organisms and templates are adapted for specific business verticals. This allows maintaining the overall brand DNA while giving product teams freedom where it is truly needed.

When to add a component and when to allow customization

This solution is almost never described specifically, yet it determines whether the system will turn into chaos within a year of active growth. The working algorithm looks like this:

1. A request comes from a product team — it is recorded in the general backlog of the design system, not resolved in correspondence between two designers.
2. Frequency is checked: if a similar pattern is requested by two or more teams — it is a candidate for a system component, not a one-time customization.
3. Compatibility with tokens and current architecture is checked: can it be implemented through existing variables without creating a new visual language.
4. If the pattern is unique to one product and does not contradict the system's principles — local customization is provided within the framework of the fixed 'points of freedom', without changing the core.
5. If the pattern is widespread and changes the interaction logic itself — the component is refined at the Core level, and the change goes through the design council review.

Without this process, the design system quickly turns into a warehouse of dead components that nobody supports, because each team made their own version 'on the fly'.

Development cost and timelines

The price depends significantly on the scale, and it makes no sense to rely on abstract 'from A to B' without numbers. A design system with 40 basic components costs 250–500 thousand rubles, which is 200–400 hours of work by designers and developers together. A large system — from 80 components, with full tokenization, documentation, and dark theme support — costs $300–600 thousand, and the timeline extends to 4–6 months. It's not possible to do it faster and properly: time is spent not on drawing components, but on aligning rules between teams, which is the slowest part of the process.

How to achieve real implementation, not a system 'just for show'

A ready-made component library in Figma is not equal to a working design system — it becomes a working tool only when it is actually used in development. Implementation usually goes through several stages:

• audit of current interfaces and identification of existing patterns — the system is not built from scratch, but based on what actually works;
• tokenization — transferring colors, fonts, and spacing into variables before component assembly begins;
• pilot product — the system is implemented on one product, not across the entire ecosystem, to test the process without risking the entire portfolio;
• documentation with usage examples and explicit prohibitions — what not to do, not just what is allowed;
• assigning a system owner — a team or person who makes decisions on the backlog of changes;
• adoption metrics — without them, implementation easily turns into a one-time project that gets forgotten in six months.

Success indicators are measurable: a reduction in time spent on interface design by 30–40%, acceleration of onboarding for new designers and developers by 40%, and a noticeable decrease in mismatches between mockups and implementation — these are the results companies observe when a design system is properly implemented and adopted. If these figures don't move six months after the system launch — the problem is not with the components, but with the decision-making process, which is either not established or ignored by teams.