Дизайн-система бренда: зачем она нужна digital-команде
Дальше — по существу, без общих слов про «консистентность» и «единый визуальный язык», которые и так есть в каждой второй статье на эту тему.
Дизайн-система и UI-kit: где проходит граница
Это не синонимы, хотя путают их постоянно, и путаница обходится дорого — команда покупает UI-kit, а ждёт эффекта дизайн-системы. UI-kit — это набор готовых визуальных элементов: кнопки, поля, иконки, цвета. Дизайн-система — это UI-kit плюс правила его использования, код компонентов, документация и процесс поддержки. UI-kit можно скачать за вечер. Дизайн-систему нельзя купить готовую — она выращивается под конкретный продукт и команду.
| Параметр | UI-kit | Дизайн-система |
|---|---|---|
| Что внутри | Библиотека визуальных компонентов | Компоненты + код + правила + документация + процесс изменений |
| Кто использует | Дизайнеры | Дизайнеры, разработчики, PM, иногда маркетинг |
| Живёт ли самостоятельно | Да, как файл в Figma | Нет, требует владельца и регулярных обновлений |
| Когда достаточно | 1 продукт, команда до 3 человек, MVP | 2+ продукта, 3+ разработчика/дизайнера, регулярный релиз новых экранов |
Практический критерий простой: если у компании один сайт и один дизайнер — дизайн-система не нужна, хватит грамотного UI-kit. Если есть мобильное приложение, веб-версия, личный кабинет и лендинги, которые делают разные люди, — без дизайн-системы каждый новый продукт начинает жить своей визуальной жизнью, и через год бренд выглядит так, будто его делали три разных агентства.
Сколько это стоит: три сценария вместо одной цифры
Здесь конкуренты обычно называют вилку в лоб — «от 500 тысяч до нескольких миллионов» — и не объясняют, от чего она зависит. Разница в масштабе задачи, а не в жадности подрядчика.
| Сценарий | Команда | Срок | Бюджет |
|---|---|---|---|
| Стартовая система | 1 дизайнер + 1 фронтенд-разработчик | 4–8 недель | от 500 000 ₽ |
| Функциональная ДС для среднего продукта | дизайнер, разработчик, product-менеджер | 6–12 месяцев | 1–1,5 млн ₽ |
| Корпоративная ДС на несколько продуктов | дизайнеры, фронтенд, PM, UX-исследователь | от 12 месяцев, с постоянной поддержкой | 2,5 млн ₽ и выше |
Сравни делали первую версию своей дизайн-системы полгода и ещё полтора года ушло на то, чтобы перевести на неё весь сайт — это нормальная пропорция: создание ядра быстрее, чем миграция всего продукта на новые правила. Закладывать миграцию в сроки обязательно, иначе руководство ждёт результат через месяц после запуска системы, а получает его через полтора года.
Как меняется работа каждой роли — не в теории, а по часам
Вот тут большинство статей останавливаются на абстрактном «ускоряет процессы». В реальности механика такая: дизайнер в Forpes/Hexa UI раньше тратил 50–60% времени задачи на саму задачу, 20–25% на отрисовку компонента с нуля и 15–20% на поиск подходящего примера в старых макетах. После внедрения дизайн-системы соотношение перевернулось: 80% времени — на суть задачи, максимум 10% — на компонент (он уже готов, его нужно вставить и настроить), 10–15% — на поиск референса, потому что все примеры лежат в одном месте.
- Дизайнер перестаёт быть художником по кнопкам и начинает решать пользовательские задачи — переиспользование готовых компонентов в Финам и ВТБ доходит до 60% при запуске новых продуктов.
- Разработчик получает не картинку, а спецификацию с готовым кодом компонента — количество уточняющих вопросов дизайнеру, по данным Сравни, падает в 3 раза.
- Product-менеджер согласует не эстетику, а логику: в Ростелекоме внедрение co-design — совместной работы в Figma через Zoom — вместе с дизайн-системой позволило согласовать готовый прототип за одну встречу вместо нескольких недель переписки и правок.
Итоговая скорость сборки макетов у Сравни выросла в 2–3 раза — не потому что дизайнеры стали работать быстрее руками, а потому что перестали заново решать уже решённые задачи.
С чего начать, если опыта не было никогда
Самая частая ошибка — начинать с UI-kit «на всякий случай» без реального запроса от команды. Дизайн-система должна расти из боли, а не из моды.
- Проведите аудит существующих экранов: соберите все кнопки, поля, карточки из живого продукта в один файл. Обычно на этом этапе становится видно 5–7 версий одной и той же кнопки — это и есть аргумент для руководства.
- Выделите атомы: цвета, типографику, сетку, отступы. Это основа, без которой любой компонент собирается на глаз.
- Соберите первые 10–15 компонентов, которые используются чаще всего — формы, кнопки, карточки, модальные окна. Не пытайтесь закрыть всё сразу.
- Переведите компоненты в код параллельно с дизайном — если фронтенд-компонент появляется через месяц после дизайн-макета, разработчики продолжат верстать по-старому.
- Назначьте владельца системы — человека, который решает споры и одобряет изменения. Без владельца система превращается в свалку из версий за полгода.
- Запустите пилот на одном реальном продукте, а не на демо-странице — только так видно, где правила не работают на практике.
Инструменты: как связать Figma, код и документацию
Отдельная ошибка — собрать красивую библиотеку в Figma и оставить её изолированной от кода. Тогда разработчик верстает заново то, что дизайнер уже нарисовал, и вся экономия времени исчезает на стыке ролей.
| Инструмент | Роль в системе | С чем синхронизируется |
|---|---|---|
| Figma | Библиотека компонентов, токены стилей, макеты | Экспорт токенов в код через плагины (Tokens Studio и аналоги) |
| Storybook | Живая витрина компонентов в коде с их состояниями | Прямая ссылка на компонент из Figma-документации |
| Код-репозиторий (React/Vue-компоненты) | Единственный источник правды для продакшена | Версионируется, обновления публикуются как npm-пакет |
| Confluence/Notion | Правила использования, гайдлайны, история изменений | Ссылается на конкретные версии Figma и Storybook |
Работающая связка выглядит так: дизайнер меняет токен цвета в Figma → изменение попадает в код через синхронизацию токенов → компонент в Storybook обновляется автоматически → разработчик подтягивает новую версию пакета в продукт. Если хотя бы одно звено делается руками и «когда-нибудь», система начинает расходиться с реальным продуктом уже через пару месяцев — и это самая частая причина, почему дизайн-системы умирают через год после запуска.
Почему дизайн-системы иногда не срабатывают
Это тот самый практический разговор, которого обычно нет в статьях про дизайн-системы. Провал редко случается из-за плохого дизайна компонентов — он случается из-за организации процесса.
- Систему делают без владельца. Через полгода никто не может сказать, актуальна ли версия компонента в продакшене, и команда возвращается к старым привычкам.
- Дизайн и код развиваются раздельно. Дизайнер обновил компонент в Figma, разработчик об этом не узнал — система превращается в красивую картинку, которая не отражает реальный продукт.
- Систему строят «на будущее» без реального продукта. Абстрактные компоненты без привязки к конкретным экранам почти всегда переделываются с нуля, когда доходит до реальной задачи.
- Нет процесса запроса новых компонентов. Если дизайнер не знает, куда обратиться за нестандартным элементом, он рисует его сам — и система начинает дробиться на исключения.
- Команду не обучили пользоваться системой. Готовые компоненты есть, но их не используют по привычке — тогда вложенные деньги просто не отрабатывают себя.
Дизайн-система окупается не в момент запуска, а через 3–4 месяца регулярного использования, когда команда перестаёт спорить о мелочах и начинает спорить о продукте. Если этого не происходит — проблема почти всегда не в самой системе, а в том, что её внедрили и забыли, вместо того чтобы встроить в ежедневный процесс.
Дальше — по существу, без общих слов про «консистентность» и «единый визуальный язык», которые и так есть в каждой второй статье на эту тему.
Дизайн-система и UI-kit: где проходит граница
Это не синонимы, хотя путают их постоянно, и путаница обходится дорого — команда покупает UI-kit, а ждёт эффекта дизайн-системы. UI-kit — это набор готовых визуальных элементов: кнопки, поля, иконки, цвета. Дизайн-система — это UI-kit плюс правила его использования, код компонентов, документация и процесс поддержки. UI-kit можно скачать за вечер. Дизайн-систему нельзя купить готовую — она выращивается под конкретный продукт и команду.
| Параметр | UI-kit | Дизайн-система |
|---|---|---|
| Что внутри | Библиотека визуальных компонентов | Компоненты + код + правила + документация + процесс изменений |
| Кто использует | Дизайнеры | Дизайнеры, разработчики, PM, иногда маркетинг |
| Живёт ли самостоятельно | Да, как файл в Figma | Нет, требует владельца и регулярных обновлений |
| Когда достаточно | 1 продукт, команда до 3 человек, MVP | 2+ продукта, 3+ разработчика/дизайнера, регулярный релиз новых экранов |
Практический критерий простой: если у компании один сайт и один дизайнер — дизайн-система не нужна, хватит грамотного UI-kit. Если есть мобильное приложение, веб-версия, личный кабинет и лендинги, которые делают разные люди, — без дизайн-системы каждый новый продукт начинает жить своей визуальной жизнью, и через год бренд выглядит так, будто его делали три разных агентства.
Сколько это стоит: три сценария вместо одной цифры
Здесь конкуренты обычно называют вилку в лоб — «от 500 тысяч до нескольких миллионов» — и не объясняют, от чего она зависит. Разница в масштабе задачи, а не в жадности подрядчика.
| Сценарий | Команда | Срок | Бюджет |
|---|---|---|---|
| Стартовая система | 1 дизайнер + 1 фронтенд-разработчик | 4–8 недель | от 500 000 ₽ |
| Функциональная ДС для среднего продукта | дизайнер, разработчик, product-менеджер | 6–12 месяцев | 1–1,5 млн ₽ |
| Корпоративная ДС на несколько продуктов | дизайнеры, фронтенд, PM, UX-исследователь | от 12 месяцев, с постоянной поддержкой | 2,5 млн ₽ и выше |
Сравни делали первую версию своей дизайн-системы полгода и ещё полтора года ушло на то, чтобы перевести на неё весь сайт — это нормальная пропорция: создание ядра быстрее, чем миграция всего продукта на новые правила. Закладывать миграцию в сроки обязательно, иначе руководство ждёт результат через месяц после запуска системы, а получает его через полтора года.
Как меняется работа каждой роли — не в теории, а по часам
Вот тут большинство статей останавливаются на абстрактном «ускоряет процессы». В реальности механика такая: дизайнер в Forpes/Hexa UI раньше тратил 50–60% времени задачи на саму задачу, 20–25% на отрисовку компонента с нуля и 15–20% на поиск подходящего примера в старых макетах. После внедрения дизайн-системы соотношение перевернулось: 80% времени — на суть задачи, максимум 10% — на компонент (он уже готов, его нужно вставить и настроить), 10–15% — на поиск референса, потому что все примеры лежат в одном месте.
- Дизайнер перестаёт быть художником по кнопкам и начинает решать пользовательские задачи — переиспользование готовых компонентов в Финам и ВТБ доходит до 60% при запуске новых продуктов.
- Разработчик получает не картинку, а спецификацию с готовым кодом компонента — количество уточняющих вопросов дизайнеру, по данным Сравни, падает в 3 раза.
- Product-менеджер согласует не эстетику, а логику: в Ростелекоме внедрение co-design — совместной работы в Figma через Zoom — вместе с дизайн-системой позволило согласовать готовый прототип за одну встречу вместо нескольких недель переписки и правок.
Итоговая скорость сборки макетов у Сравни выросла в 2–3 раза — не потому что дизайнеры стали работать быстрее руками, а потому что перестали заново решать уже решённые задачи.
С чего начать, если опыта не было никогда
Самая частая ошибка — начинать с UI-kit «на всякий случай» без реального запроса от команды. Дизайн-система должна расти из боли, а не из моды.
- Проведите аудит существующих экранов: соберите все кнопки, поля, карточки из живого продукта в один файл. Обычно на этом этапе становится видно 5–7 версий одной и той же кнопки — это и есть аргумент для руководства.
- Выделите атомы: цвета, типографику, сетку, отступы. Это основа, без которой любой компонент собирается на глаз.
- Соберите первые 10–15 компонентов, которые используются чаще всего — формы, кнопки, карточки, модальные окна. Не пытайтесь закрыть всё сразу.
- Переведите компоненты в код параллельно с дизайном — если фронтенд-компонент появляется через месяц после дизайн-макета, разработчики продолжат верстать по-старому.
- Назначьте владельца системы — человека, который решает споры и одобряет изменения. Без владельца система превращается в свалку из версий за полгода.
- Запустите пилот на одном реальном продукте, а не на демо-странице — только так видно, где правила не работают на практике.
Инструменты: как связать Figma, код и документацию
Отдельная ошибка — собрать красивую библиотеку в Figma и оставить её изолированной от кода. Тогда разработчик верстает заново то, что дизайнер уже нарисовал, и вся экономия времени исчезает на стыке ролей.
| Инструмент | Роль в системе | С чем синхронизируется |
|---|---|---|
| Figma | Библиотека компонентов, токены стилей, макеты | Экспорт токенов в код через плагины (Tokens Studio и аналоги) |
| Storybook | Живая витрина компонентов в коде с их состояниями | Прямая ссылка на компонент из Figma-документации |
| Код-репозиторий (React/Vue-компоненты) | Единственный источник правды для продакшена | Версионируется, обновления публикуются как npm-пакет |
| Confluence/Notion | Правила использования, гайдлайны, история изменений | Ссылается на конкретные версии Figma и Storybook |
Работающая связка выглядит так: дизайнер меняет токен цвета в Figma → изменение попадает в код через синхронизацию токенов → компонент в Storybook обновляется автоматически → разработчик подтягивает новую версию пакета в продукт. Если хотя бы одно звено делается руками и «когда-нибудь», система начинает расходиться с реальным продуктом уже через пару месяцев — и это самая частая причина, почему дизайн-системы умирают через год после запуска.
Почему дизайн-системы иногда не срабатывают
Это тот самый практический разговор, которого обычно нет в статьях про дизайн-системы. Провал редко случается из-за плохого дизайна компонентов — он случается из-за организации процесса.
- Систему делают без владельца. Через полгода никто не может сказать, актуальна ли версия компонента в продакшене, и команда возвращается к старым привычкам.
- Дизайн и код развиваются раздельно. Дизайнер обновил компонент в Figma, разработчик об этом не узнал — система превращается в красивую картинку, которая не отражает реальный продукт.
- Систему строят «на будущее» без реального продукта. Абстрактные компоненты без привязки к конкретным экранам почти всегда переделываются с нуля, когда доходит до реальной задачи.
- Нет процесса запроса новых компонентов. Если дизайнер не знает, куда обратиться за нестандартным элементом, он рисует его сам — и система начинает дробиться на исключения.
- Команду не обучили пользоваться системой. Готовые компоненты есть, но их не используют по привычке — тогда вложенные деньги просто не отрабатывают себя.
Дизайн-система окупается не в момент запуска, а через 3–4 месяца регулярного использования, когда команда перестаёт спорить о мелочах и начинает спорить о продукте. Если этого не происходит — проблема почти всегда не в самой системе, а в том, что её внедрили и забыли, вместо того чтобы встроить в ежедневный процесс.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
