UI-кит бренда: состав и принципы организации
Чем UI-кит отличается от дизайн-системы
Путаница между этими терминами живёт в 90% брифов, с которыми к нам приходят клиенты. UI-кит — это набор готовых визуальных компонентов: кнопки, поля ввода, иконки, карточки. Дизайн-система — это UI-кит плюс правила, документация, принципы использования, design tokens и процессы синхронизации с кодом. UI-кит — часть дизайн-системы, её видимый, «файловый» слой в Figma.
Когда чего достаточно? Если у вас один продукт и команда из двух-трёх человек — хватит UI-кита. Если продукт растёт на несколько платформ, а над интерфейсом работают разные команды — без дизайн-системы начнётся хаос: одинаковые кнопки будут вести себя по-разному на iOS, Android и в вебе.
| Критерий | UI-кит | Дизайн-система |
|---|---|---|
| Что внутри | Компоненты и стили | Компоненты + правила + токены + процессы |
| Когда достаточно | Один продукт, маленькая команда | Несколько платформ/продуктов |
| Кто поддерживает | 1-2 дизайнера | Отдельная команда (продакт, дизайнеры, разработчики, QA) |
| Синхронизация с кодом | Часто отсутствует | Обязательна (design tokens, Storybook) |
Из чего состоит рабочий UI-кит
Базовый UI-кит не обязан быть огромным. На практике 15-20 компонентов закрывают около 80% задач интерфейса — остальное это частные случаи, которые можно собрать из тех же атомов. Расширенные системы вроде Banka UI разрастаются до 100+ компонентов с синхронизацией между iOS, Android и Web, но это уже история про масштаб, а не про необходимость.
Обязательный минимум, без которого UI-кит нельзя считать рабочим:
- Кнопки — минимум три типа: Primary, Secondary, Ghost/Tertiary
- Инпуты, чекбоксы, радиокнопки, тоглы
- Выпадающие списки и модальные окна
- Карточки и навигационные элементы
- Индикаторы загрузки и алерты
- Иконки — от 50 до 200+ штук в зависимости от продукта
Отдельно стоит модульная сетка. Отраслевой стандарт — модуль 8px с подмодулями 4px и 2px для мелких элементов. Все отступы и размеры кратны 8: 8, 16, 24, 32, 48, 64, 80px. Это не эстетическая прихоть, а способ мгновенно понять, откуда взялась цифра «14px» в макете — если она не кратна модулю, это ошибка, а не «дизайнерское решение».
Как структурировать UI-кит в Figma, чтобы его не приходилось разгадывать
Главная проблема большинства UI-китов — не отсутствие компонентов, а хаотичное именование. Через полгода даже автор файла не может быстро найти нужный вариант кнопки среди 40 похожих.
Рабочая схема — иерархическое именование через слэш: файл/страница/фрейм/категория/вложенность. Например: componentsAndroid/lists/elements/circle40×40/blue. Figma автоматически группирует компоненты по этой структуре в панели Assets, и команда получает выпадающие подменю вместо бесконечного скролла.
- Разделите файл на страницы: Foundations (цвет, типографика, сетка), Components, Patterns, Documentation
- Внутри Components группируйте по функции, а не по визуальному сходству
- Называйте варианты компонента по свойству, а не по номеру («blue», а не «variant 3»)
- Используйте Variants и Auto Layout, а не дублирующиеся фреймы
Какие состояния обязательно закладывать в каждый компонент
Здесь чаще всего экономят, и это ошибка, которая всплывает уже в разработке. Каждый интерактивный компонент должен иметь минимум семь состояний: Default, Hover, Active, Disabled, Loading, Error, Focus. Focus — не опциональный бонус, а требование доступности: без него пользователи с клавиатурной навигацией не понимают, где находится курсор.
Масштаб задачи хорошо иллюстрирует пример Banka UI: один-единственный компонент списка там имел 30+ вариаций — комбинации иконки, аватара, бейджа, состояния загрузки и типа действия. Если закладывать состояния «на глаз» уже в процессе разработки, компонент превращается в зоопарк частных случаев, которые невозможно поддерживать.
Версионность и синхронизация с кодом — то, что обычно упускают
UI-кит, который живёт только в Figma и не имеет процесса обновления, устаревает за один спринт. Здесь работает семантическое версионирование MAJOR.MINOR.PATCH: MAJOR — ломающие изменения, MINOR — новые компоненты без потери обратной совместимости, PATCH — правки и фиксы.
Хороший пример — практика команды, работающей с крупной системой: старые имена design tokens не удаляются мгновенно, а продолжают работать как alias до конкретной removalVersion, с явным предупреждением через deprecations.json. Разработчик видит, что токен устарел, и у него есть время на миграцию, а не аварийная правка в проде.
Синхронизация дизайна и кода строится на трёх опорах:
- Design tokens — единый источник значений цвета, отступов, типографики, который читают и Figma, и код
- Storybook — живая витрина компонентов в реальном коде, сверяемая с макетами
- CI/CD — автоматическая проверка, что изменение токена не сломало компоненты в проде
Без этой связки UI-кит в Figma и компоненты в коде расходятся уже через два-три релиза, и никто не может сказать, какая версия «правильная».
Кто отвечает за UI-кит при росте продукта
Команда из семи человек способна поддерживать дизайн-систему масштаба трёх платформ и двенадцати с лишним веб-проектов — так устроена команда Banka UI: продакт-менеджер, по разработчику на каждую платформу, два дизайнера, один тестировщик. Это не самая маленькая конфигурация, но она работает благодаря чёткому разделению ответственности.
Принцип простой: базовые компоненты — зона ответственности команды дизайн-системы, кастомные — продуктовых команд. Чтобы не спорить каждый раз, применяют чек-лист из трёх вопросов: это базовый компонент? нужен ли он другим проектам? соответствует ли он принципам системы? Если да на все три — компонент дорабатывается и передаётся в общий UI-кит, а не остаётся уникальным для одного продукта.
Отдельно стоит документировать не только вид компонента, но и правило его выбора: когда использовать Primary-кнопку, а когда Ghost, почему модальное окно предпочтительнее инлайн-формы в конкретном сценарии. Без такой документации UI-кит превращается в набор деталей без инструкции — и каждая команда собирает из них что-то своё.
Чем UI-кит отличается от дизайн-системы
Путаница между этими терминами живёт в 90% брифов, с которыми к нам приходят клиенты. UI-кит — это набор готовых визуальных компонентов: кнопки, поля ввода, иконки, карточки. Дизайн-система — это UI-кит плюс правила, документация, принципы использования, design tokens и процессы синхронизации с кодом. UI-кит — часть дизайн-системы, её видимый, «файловый» слой в Figma.
Когда чего достаточно? Если у вас один продукт и команда из двух-трёх человек — хватит UI-кита. Если продукт растёт на несколько платформ, а над интерфейсом работают разные команды — без дизайн-системы начнётся хаос: одинаковые кнопки будут вести себя по-разному на iOS, Android и в вебе.
| Критерий | UI-кит | Дизайн-система |
|---|---|---|
| Что внутри | Компоненты и стили | Компоненты + правила + токены + процессы |
| Когда достаточно | Один продукт, маленькая команда | Несколько платформ/продуктов |
| Кто поддерживает | 1-2 дизайнера | Отдельная команда (продакт, дизайнеры, разработчики, QA) |
| Синхронизация с кодом | Часто отсутствует | Обязательна (design tokens, Storybook) |
Из чего состоит рабочий UI-кит
Базовый UI-кит не обязан быть огромным. На практике 15-20 компонентов закрывают около 80% задач интерфейса — остальное это частные случаи, которые можно собрать из тех же атомов. Расширенные системы вроде Banka UI разрастаются до 100+ компонентов с синхронизацией между iOS, Android и Web, но это уже история про масштаб, а не про необходимость.
Обязательный минимум, без которого UI-кит нельзя считать рабочим:
- Кнопки — минимум три типа: Primary, Secondary, Ghost/Tertiary
- Инпуты, чекбоксы, радиокнопки, тоглы
- Выпадающие списки и модальные окна
- Карточки и навигационные элементы
- Индикаторы загрузки и алерты
- Иконки — от 50 до 200+ штук в зависимости от продукта
Отдельно стоит модульная сетка. Отраслевой стандарт — модуль 8px с подмодулями 4px и 2px для мелких элементов. Все отступы и размеры кратны 8: 8, 16, 24, 32, 48, 64, 80px. Это не эстетическая прихоть, а способ мгновенно понять, откуда взялась цифра «14px» в макете — если она не кратна модулю, это ошибка, а не «дизайнерское решение».
Как структурировать UI-кит в Figma, чтобы его не приходилось разгадывать
Главная проблема большинства UI-китов — не отсутствие компонентов, а хаотичное именование. Через полгода даже автор файла не может быстро найти нужный вариант кнопки среди 40 похожих.
Рабочая схема — иерархическое именование через слэш: файл/страница/фрейм/категория/вложенность. Например: componentsAndroid/lists/elements/circle40×40/blue. Figma автоматически группирует компоненты по этой структуре в панели Assets, и команда получает выпадающие подменю вместо бесконечного скролла.
- Разделите файл на страницы: Foundations (цвет, типографика, сетка), Components, Patterns, Documentation
- Внутри Components группируйте по функции, а не по визуальному сходству
- Называйте варианты компонента по свойству, а не по номеру («blue», а не «variant 3»)
- Используйте Variants и Auto Layout, а не дублирующиеся фреймы
Какие состояния обязательно закладывать в каждый компонент
Здесь чаще всего экономят, и это ошибка, которая всплывает уже в разработке. Каждый интерактивный компонент должен иметь минимум семь состояний: Default, Hover, Active, Disabled, Loading, Error, Focus. Focus — не опциональный бонус, а требование доступности: без него пользователи с клавиатурной навигацией не понимают, где находится курсор.
Масштаб задачи хорошо иллюстрирует пример Banka UI: один-единственный компонент списка там имел 30+ вариаций — комбинации иконки, аватара, бейджа, состояния загрузки и типа действия. Если закладывать состояния «на глаз» уже в процессе разработки, компонент превращается в зоопарк частных случаев, которые невозможно поддерживать.
Версионность и синхронизация с кодом — то, что обычно упускают
UI-кит, который живёт только в Figma и не имеет процесса обновления, устаревает за один спринт. Здесь работает семантическое версионирование MAJOR.MINOR.PATCH: MAJOR — ломающие изменения, MINOR — новые компоненты без потери обратной совместимости, PATCH — правки и фиксы.
Хороший пример — практика команды, работающей с крупной системой: старые имена design tokens не удаляются мгновенно, а продолжают работать как alias до конкретной removalVersion, с явным предупреждением через deprecations.json. Разработчик видит, что токен устарел, и у него есть время на миграцию, а не аварийная правка в проде.
Синхронизация дизайна и кода строится на трёх опорах:
- Design tokens — единый источник значений цвета, отступов, типографики, который читают и Figma, и код
- Storybook — живая витрина компонентов в реальном коде, сверяемая с макетами
- CI/CD — автоматическая проверка, что изменение токена не сломало компоненты в проде
Без этой связки UI-кит в Figma и компоненты в коде расходятся уже через два-три релиза, и никто не может сказать, какая версия «правильная».
Кто отвечает за UI-кит при росте продукта
Команда из семи человек способна поддерживать дизайн-систему масштаба трёх платформ и двенадцати с лишним веб-проектов — так устроена команда Banka UI: продакт-менеджер, по разработчику на каждую платформу, два дизайнера, один тестировщик. Это не самая маленькая конфигурация, но она работает благодаря чёткому разделению ответственности.
Принцип простой: базовые компоненты — зона ответственности команды дизайн-системы, кастомные — продуктовых команд. Чтобы не спорить каждый раз, применяют чек-лист из трёх вопросов: это базовый компонент? нужен ли он другим проектам? соответствует ли он принципам системы? Если да на все три — компонент дорабатывается и передаётся в общий UI-кит, а не остаётся уникальным для одного продукта.
Отдельно стоит документировать не только вид компонента, но и правило его выбора: когда использовать Primary-кнопку, а когда Ghost, почему модальное окно предпочтительнее инлайн-формы в конкретном сценарии. Без такой документации UI-кит превращается в набор деталей без инструкции — и каждая команда собирает из них что-то своё.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
