Дизайн-система бренда: как связать айдентику с продуктом
Дизайн-система с нуля или заплатка на готовый бренд — разница в результате
Большинство компаний идут по одному и тому же пути: сначала рисуют логотип, палитру и гайдлайны, потом отдают всё это разработчикам, которые уже что-то запрограммировали. Дизайн-система в этой модели появляется как инструмент спасения — попытка навести порядок в хаосе несогласованных компонентов. Это работает, но дорого и медленно, потому что каждое несоответствие между брендбуком и кодом приходится вычищать вручную.
Второй подход — закладывать дизайн-систему одновременно с разработкой айдентики, ещё на этапе, когда бренд-дизайнер выбирает цвет акцента. В этом случае решение «наш основной синий — #0070BB» сразу превращается в токен, который попадает и в брендбук, и в код одним движением. Не нужно потом «переводить» визуальную идентичность на язык интерфейсов — она изначально описана на языке, понятном обеим сторонам.
| Критерий | Дизайн-система постфактум | Дизайн-система с нуля |
|---|---|---|
| Момент внедрения | После запуска продукта, когда накопились расхождения | Параллельно с разработкой айдентики |
| Источник правды | Брендбук и код существуют раздельно | Единая токен-система для обоих |
| Скорость масштабирования | Каждое изменение бренда требует ручной синхронизации | Изменение токена автоматически распространяется везде |
| Стоимость поддержки | Растёт с каждым новым продуктом или направлением | Остаётся стабильной за счёт архитектуры |
Дизайн-система становится критической необходимостью не «когда команда разрослась», а в конкретный момент: когда у продукта появляется вторая платформа или второй бренд под тем же юрлицом. Пока это один сайт и одна команда из трёх человек, брендбук в PDF вполне справляется. Как только речь заходит о вебе, мобильном приложении и партнёрских виджетах одновременно — без единого источника токенов расхождения гарантированы в течение первых двух месяцев.
Три уровня токенов: как связать решение бренд-дизайнера с кнопкой в коде
Ключевая ошибка — воспринимать дизайн-токены как просто «переменные для цвета». На деле это механизм трансляции стратегии бренда в код, и работает он через три уровня иерархии.
- Primitive tokens — сырые значения без смысла, просто данные:
#0070BB,16px,Inter. - Semantic tokens — то же значение, но с ролью в системе:
action-color,text-primary. Здесь решение бренд-дизайнера («основной цвет должен ассоциироваться с действием») впервые получает имя, понятное разработчику. - Component tokens — привязка к конкретному элементу интерфейса:
c6ButtonPrimary. Именно на этом уровне абстрактная айдентика становится пикселем на экране пользователя.
Без среднего слоя система разваливается: изменить фирменный цвет означает искать и переписывать значение в сотне мест. С грамотной иерархией ребрендинг цвета — это правка одного primitive-токена, которая каскадом обновляет все компоненты.
Синхронизация брендбука и кода: два инструмента против одного разрыва
Живой брендбук отличается от статичного PDF тем, что изменение в одном месте автоматически появляется в другом. Технически это решается через связку Figma → Git → Code, а посредником выступают плагины Tokens Studio или Specify.
- Бренд-дизайнер задаёт значения токенов в Figma Variables — это единственное место, где хранится «источник правды» для визуальных решений.
- Tokens Studio экспортирует токены в JSON и синхронизирует их с Git-репозиторием.
- Сборка проекта подтягивает эти файлы и генерирует CSS-переменные или объекты для нативной разработки.
- Изменение токена в Figma запускает пул-реквест — команда разработки видит diff и подтверждает обновление.
Разница с ручным подходом принципиальная: дизайнер меняет цвет кнопки в Figma, и через один пул-реквест это значение появляется во всех интерфейсах, где используется этот токен, — без созвонов и написания тикетов на «поправить оттенок».
Масштабирование на несколько брендов: почему одна система лучше пяти брендбуков
Проблема множественных брендбуков особенно остро встаёт у компаний с портфелем брендов. X5 (Пятёрочка, Перекрёсток) решили её через токены в Figma Variables: один сервис личного кабинета адаптируется под разные брендбуки переключением режима одной кнопкой — переменные подменяются, компоненты остаются те же.
МегаФон выстроил трёхуровневую архитектуру иначе — не через переключение режима, а через наследование:
- Core-библиотека — базовые компоненты, «ДНК» бренда, неизменная для всех направлений.
- Base-библиотека — компоненты для основных интерфейсов, наследующие от Core.
- Направленческие библиотеки — B2C, B2X, ТВ и другие, каждая со своим стилем коммуникации, но на общем фундаменте.
Разница между двумя моделями не в технологии, а в задаче: X5 нужно переключение между полностью самостоятельными брендами, МегаФону — контролируемая вариативность внутри одного бренда с разными аудиториями. Выбор архитектуры должен идти от структуры портфеля, а не от того, что «так сделали в другой компании».
Экономика: во что реально выливается отсутствие связки
Аргумент «это дорого сделать сразу» разбивается о цифры. Яндекс за счёт унифицированного UI-кита и CSS-библиотеки сократил время выполнения задач в три раза и сэкономил 2,3 млн рублей. Для компании среднего размера — 5 дизайнеров и 10 разработчиков — при инвестиции 30% времени в разработку системы возврат составляет +170% ROI для дизайнеров, +120% для разработчиков и +135% в целом, то есть 2,70 доллара на каждый вложенный доллар за пять лет.
| Показатель | Без единой системы токенов | С трёхуровневой системой |
|---|---|---|
| Время на согласование изменения цвета/шрифта | Дни, ручная проверка каждого экрана | Часы, автоматический каскад |
| Расхождение бренда между платформами | Накапливается с каждым релизом | Исключено архитектурой |
| ROI на 5 лет (пример 5 дизайнеров / 10 разработчиков) | Не измеряется, потери скрыты в переработках | +135%, 2,70$ на 1$ |
Это не теоретическая выгода. Каждый час, потраченный дизайнером на «подгонку под бренд» вручную, — это час, который система токенов могла бы отдать бесплатно, автоматическим наследованием значений. Компании, которые откладывают внедрение до момента «когда будет время», обычно приходят к этому решению уже после болезненного ребрендинга, где пересчёт всех несинхронизированных компонентов занимает месяцы.
Дизайн-система с нуля или заплатка на готовый бренд — разница в результате
Большинство компаний идут по одному и тому же пути: сначала рисуют логотип, палитру и гайдлайны, потом отдают всё это разработчикам, которые уже что-то запрограммировали. Дизайн-система в этой модели появляется как инструмент спасения — попытка навести порядок в хаосе несогласованных компонентов. Это работает, но дорого и медленно, потому что каждое несоответствие между брендбуком и кодом приходится вычищать вручную.
Второй подход — закладывать дизайн-систему одновременно с разработкой айдентики, ещё на этапе, когда бренд-дизайнер выбирает цвет акцента. В этом случае решение «наш основной синий — #0070BB» сразу превращается в токен, который попадает и в брендбук, и в код одним движением. Не нужно потом «переводить» визуальную идентичность на язык интерфейсов — она изначально описана на языке, понятном обеим сторонам.
| Критерий | Дизайн-система постфактум | Дизайн-система с нуля |
|---|---|---|
| Момент внедрения | После запуска продукта, когда накопились расхождения | Параллельно с разработкой айдентики |
| Источник правды | Брендбук и код существуют раздельно | Единая токен-система для обоих |
| Скорость масштабирования | Каждое изменение бренда требует ручной синхронизации | Изменение токена автоматически распространяется везде |
| Стоимость поддержки | Растёт с каждым новым продуктом или направлением | Остаётся стабильной за счёт архитектуры |
Дизайн-система становится критической необходимостью не «когда команда разрослась», а в конкретный момент: когда у продукта появляется вторая платформа или второй бренд под тем же юрлицом. Пока это один сайт и одна команда из трёх человек, брендбук в PDF вполне справляется. Как только речь заходит о вебе, мобильном приложении и партнёрских виджетах одновременно — без единого источника токенов расхождения гарантированы в течение первых двух месяцев.
Три уровня токенов: как связать решение бренд-дизайнера с кнопкой в коде
Ключевая ошибка — воспринимать дизайн-токены как просто «переменные для цвета». На деле это механизм трансляции стратегии бренда в код, и работает он через три уровня иерархии.
- Primitive tokens — сырые значения без смысла, просто данные:
#0070BB,16px,Inter. - Semantic tokens — то же значение, но с ролью в системе:
action-color,text-primary. Здесь решение бренд-дизайнера («основной цвет должен ассоциироваться с действием») впервые получает имя, понятное разработчику. - Component tokens — привязка к конкретному элементу интерфейса:
c6ButtonPrimary. Именно на этом уровне абстрактная айдентика становится пикселем на экране пользователя.
Без среднего слоя система разваливается: изменить фирменный цвет означает искать и переписывать значение в сотне мест. С грамотной иерархией ребрендинг цвета — это правка одного primitive-токена, которая каскадом обновляет все компоненты.
Синхронизация брендбука и кода: два инструмента против одного разрыва
Живой брендбук отличается от статичного PDF тем, что изменение в одном месте автоматически появляется в другом. Технически это решается через связку Figma → Git → Code, а посредником выступают плагины Tokens Studio или Specify.
- Бренд-дизайнер задаёт значения токенов в Figma Variables — это единственное место, где хранится «источник правды» для визуальных решений.
- Tokens Studio экспортирует токены в JSON и синхронизирует их с Git-репозиторием.
- Сборка проекта подтягивает эти файлы и генерирует CSS-переменные или объекты для нативной разработки.
- Изменение токена в Figma запускает пул-реквест — команда разработки видит diff и подтверждает обновление.
Разница с ручным подходом принципиальная: дизайнер меняет цвет кнопки в Figma, и через один пул-реквест это значение появляется во всех интерфейсах, где используется этот токен, — без созвонов и написания тикетов на «поправить оттенок».
Масштабирование на несколько брендов: почему одна система лучше пяти брендбуков
Проблема множественных брендбуков особенно остро встаёт у компаний с портфелем брендов. X5 (Пятёрочка, Перекрёсток) решили её через токены в Figma Variables: один сервис личного кабинета адаптируется под разные брендбуки переключением режима одной кнопкой — переменные подменяются, компоненты остаются те же.
МегаФон выстроил трёхуровневую архитектуру иначе — не через переключение режима, а через наследование:
- Core-библиотека — базовые компоненты, «ДНК» бренда, неизменная для всех направлений.
- Base-библиотека — компоненты для основных интерфейсов, наследующие от Core.
- Направленческие библиотеки — B2C, B2X, ТВ и другие, каждая со своим стилем коммуникации, но на общем фундаменте.
Разница между двумя моделями не в технологии, а в задаче: X5 нужно переключение между полностью самостоятельными брендами, МегаФону — контролируемая вариативность внутри одного бренда с разными аудиториями. Выбор архитектуры должен идти от структуры портфеля, а не от того, что «так сделали в другой компании».
Экономика: во что реально выливается отсутствие связки
Аргумент «это дорого сделать сразу» разбивается о цифры. Яндекс за счёт унифицированного UI-кита и CSS-библиотеки сократил время выполнения задач в три раза и сэкономил 2,3 млн рублей. Для компании среднего размера — 5 дизайнеров и 10 разработчиков — при инвестиции 30% времени в разработку системы возврат составляет +170% ROI для дизайнеров, +120% для разработчиков и +135% в целом, то есть 2,70 доллара на каждый вложенный доллар за пять лет.
| Показатель | Без единой системы токенов | С трёхуровневой системой |
|---|---|---|
| Время на согласование изменения цвета/шрифта | Дни, ручная проверка каждого экрана | Часы, автоматический каскад |
| Расхождение бренда между платформами | Накапливается с каждым релизом | Исключено архитектурой |
| ROI на 5 лет (пример 5 дизайнеров / 10 разработчиков) | Не измеряется, потери скрыты в переработках | +135%, 2,70$ на 1$ |
Это не теоретическая выгода. Каждый час, потраченный дизайнером на «подгонку под бренд» вручную, — это час, который система токенов могла бы отдать бесплатно, автоматическим наследованием значений. Компании, которые откладывают внедрение до момента «когда будет время», обычно приходят к этому решению уже после болезненного ребрендинга, где пересчёт всех несинхронизированных компонентов занимает месяцы.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
