Brand UI kit: composition and principles of organization
How a UI kit differs from a design system
Confusion between these terms lives in 90% of briefs that our clients bring to us. A UI kit is a set of ready-made visual components: buttons, input fields, icons, cards. A design system is a UI kit plus rules, documentation, usage principles, design tokens, and synchronization processes with code. A UI kit is a part of a design system, its visible, «file» layer in Figma.
When is it enough? If you have one product and a team of two to three people — a UI kit is sufficient. If the product is growing across several platforms and different teams work on the interface — without a design system, chaos will begin: identical buttons will behave differently on iOS, Android, and on the web.
| Criterion | UI kit | Design system |
|---|---|---|
| What's inside | Components and styles | Components + rules + tokens + processes |
| When it's enough | One product, small team | Multiple platforms/products |
| Who supports | 1-2 designers | A separate team (product, designers, developers, QA) |
| Synchronization with code | Often absent | Required (design tokens, Storybook) |
What a working UI kit consists of
A basic UI-kit does not have to be huge. In practice, 15-20 components cover around 80% of interface tasks — the rest are edge cases that can be assembled from the same atoms. Extended systems like Banka UI grow to 100+ components with synchronization across iOS, Android and Web, but that is a story about scale, not necessity.
The mandatory minimum without which a UI-kit cannot be considered functional:
- Buttons — at least three types: Primary, Secondary, Ghost/Tertiary
- Inputs, checkboxes, radio buttons, toggles
- Dropdowns and modal windows
- Cards and navigation elements
- Loading indicators and alerts
- Icons — from 50 to 200+ pieces depending on the product
It is worth noting the modular grid separately. The industry standard is a module 8px with submodules 4px and 2px for small elements. All margins and sizes are multiples of 8: 8, 16, 24, 32, 48, 64, 80px. This is not an aesthetic whim, but a way to instantly understand where the number «14px» in the layout came from — if it is not a multiple of the module, it is an error, not a «designer's decision».
How to structure a UI kit in Figma so that it does not have to be decoded
The main problem of most UI kits is not the lack of components, but chaotic naming. After six months, even the author of the file cannot quickly find the required button variant among 40 similar ones.
The working schema is hierarchical naming through a slash: file/page/frame/category/nesting. For example: componentsAndroid/lists/elements/circle40×40/blue. Figma automatically groups components by this structure in the Assets panel, and the team gets dropdown submenus instead of endless scrolling.
- Divide the file into pages: Foundations (color, typography, grid), Components, Patterns, Documentation
- Inside Components, group by function, not by visual similarity
- Name component variants by property, not by number («blue», not «variant 3»)
- Use Variants and Auto Layout, not duplicate frames
What states must be included in every component
Here, people often economize, and this is an error that emerges during development. Every interactive component must have at least seven states: Default, Hover, Active, Disabled, Loading, Error, Focus. Focus is not an optional bonus, but an accessibility requirement: without it, users with keyboard navigation do not understand where the cursor is.
The scale of the task is well illustrated by the Banka UI example: a single list component there had 30+ variations — combinations of icon, avatar, badge, loading state, and action type. If you try to anticipate states 'by eye' during development, the component becomes a zoo of specific cases that are impossible to maintain.
Versioning and synchronization with the code — that's what is usually overlooked
UI kit that exists only in Figma and has no update process becomes outdated within one sprint. Here semantic versioning MAJOR.MINOR.PATCH is applied: MAJOR — breaking changes, MINOR — new components without loss of backward compatibility, PATCH — fixes and patches.
A good example is the practice of a team working with a large system: old design token names are not deleted immediately, but continue to work as aliases until a specific removalVersion, with an explicit warning through deprecations.json. The developer sees that the token is deprecated and has time to migrate, rather than an emergency fix in production.
Design and code synchronization is built on three pillars:
- Design tokens — a single source of color, spacing, typography values, which are read by both Figma and code
- Storybook — a live component showcase in real code, checked against mockups
- CI/CD — automatic verification that a token change has not broken components in production
Without this linkage, the UI kit in Figma and components in code diverge already after two or three releases, and nobody can say which version is 'correct'.
Who is responsible for the UI kit as the product scales
A team of seven people can maintain a design system of three platforms and more than twelve web projects — this is how the Banka UI team is organized: product manager, one developer per platform, two designers, one tester. This is not the smallest configuration, but it works due to clear division of responsibility.
The principle is simple: basic components are the responsibility of the design system team, while custom components belong to product teams. To avoid arguments each time, a checklist of three questions is applied: is it a basic component? is it needed for other projects? does it comply with the system's principles? If the answer is yes to all three questions, the component is refined and passed to the general UI kit, rather than remaining unique to a single product.
It is worth separately documenting not only the type of component, but also the rule for its selection: when to use a Primary button and when a Ghost button, why a modal window is preferable to an inline form in a specific scenario. Without such documentation, the UI kit becomes a set of details without instructions — and each team assembles something of their own from them.
How a UI kit differs from a design system
Confusion between these terms lives in 90% of briefs that our clients bring to us. A UI kit is a set of ready-made visual components: buttons, input fields, icons, cards. A design system is a UI kit plus rules, documentation, usage principles, design tokens, and synchronization processes with code. A UI kit is a part of a design system, its visible, «file» layer in Figma.
When is it enough? If you have one product and a team of two to three people — a UI kit is sufficient. If the product is growing across several platforms and different teams work on the interface — without a design system, chaos will begin: identical buttons will behave differently on iOS, Android, and on the web.
| Criterion | UI kit | Design system |
|---|---|---|
| What's inside | Components and styles | Components + rules + tokens + processes |
| When it's enough | One product, small team | Multiple platforms/products |
| Who supports | 1-2 designers | A separate team (product, designers, developers, QA) |
| Synchronization with code | Often absent | Required (design tokens, Storybook) |
What a working UI kit consists of
A basic UI-kit does not have to be huge. In practice, 15-20 components cover around 80% of interface tasks — the rest are edge cases that can be assembled from the same atoms. Extended systems like Banka UI grow to 100+ components with synchronization across iOS, Android and Web, but that is a story about scale, not necessity.
The mandatory minimum without which a UI-kit cannot be considered functional:
- Buttons — at least three types: Primary, Secondary, Ghost/Tertiary
- Inputs, checkboxes, radio buttons, toggles
- Dropdowns and modal windows
- Cards and navigation elements
- Loading indicators and alerts
- Icons — from 50 to 200+ pieces depending on the product
It is worth noting the modular grid separately. The industry standard is a module 8px with submodules 4px and 2px for small elements. All margins and sizes are multiples of 8: 8, 16, 24, 32, 48, 64, 80px. This is not an aesthetic whim, but a way to instantly understand where the number «14px» in the layout came from — if it is not a multiple of the module, it is an error, not a «designer's decision».
How to structure a UI kit in Figma so that it does not have to be decoded
The main problem of most UI kits is not the lack of components, but chaotic naming. After six months, even the author of the file cannot quickly find the required button variant among 40 similar ones.
The working schema is hierarchical naming through a slash: file/page/frame/category/nesting. For example: componentsAndroid/lists/elements/circle40×40/blue. Figma automatically groups components by this structure in the Assets panel, and the team gets dropdown submenus instead of endless scrolling.
- Divide the file into pages: Foundations (color, typography, grid), Components, Patterns, Documentation
- Inside Components, group by function, not by visual similarity
- Name component variants by property, not by number («blue», not «variant 3»)
- Use Variants and Auto Layout, not duplicate frames
What states must be included in every component
Here, people often economize, and this is an error that emerges during development. Every interactive component must have at least seven states: Default, Hover, Active, Disabled, Loading, Error, Focus. Focus is not an optional bonus, but an accessibility requirement: without it, users with keyboard navigation do not understand where the cursor is.
The scale of the task is well illustrated by the Banka UI example: a single list component there had 30+ variations — combinations of icon, avatar, badge, loading state, and action type. If you try to anticipate states 'by eye' during development, the component becomes a zoo of specific cases that are impossible to maintain.
Versioning and synchronization with the code — that's what is usually overlooked
UI kit that exists only in Figma and has no update process becomes outdated within one sprint. Here semantic versioning MAJOR.MINOR.PATCH is applied: MAJOR — breaking changes, MINOR — new components without loss of backward compatibility, PATCH — fixes and patches.
A good example is the practice of a team working with a large system: old design token names are not deleted immediately, but continue to work as aliases until a specific removalVersion, with an explicit warning through deprecations.json. The developer sees that the token is deprecated and has time to migrate, rather than an emergency fix in production.
Design and code synchronization is built on three pillars:
- Design tokens — a single source of color, spacing, typography values, which are read by both Figma and code
- Storybook — a live component showcase in real code, checked against mockups
- CI/CD — automatic verification that a token change has not broken components in production
Without this linkage, the UI kit in Figma and components in code diverge already after two or three releases, and nobody can say which version is 'correct'.
Who is responsible for the UI kit as the product scales
A team of seven people can maintain a design system of three platforms and more than twelve web projects — this is how the Banka UI team is organized: product manager, one developer per platform, two designers, one tester. This is not the smallest configuration, but it works due to clear division of responsibility.
The principle is simple: basic components are the responsibility of the design system team, while custom components belong to product teams. To avoid arguments each time, a checklist of three questions is applied: is it a basic component? is it needed for other projects? does it comply with the system's principles? If the answer is yes to all three questions, the component is refined and passed to the general UI kit, rather than remaining unique to a single product.
It is worth separately documenting not only the type of component, but also the rule for its selection: when to use a Primary button and when a Ghost button, why a modal window is preferable to an inline form in a specific scenario. Without such documentation, the UI kit becomes a set of details without instructions — and each team assembles something of their own from them.
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
