Дизайн-система бренда: от логотипа до цифровых интерфейсов

Дизайн-система, брендбук и UI-кит — это разные слои, и путать их дорого

На старте почти все компании делают одну и ту же ошибку: заказывают брендбук и считают, что дизайн-система готова. Это не так. Брендбук отвечает за смыслы и эмоции бренда — миссию, тон коммуникации, логотип и его охранное поле. UI-кит — это набор готовых визуальных элементов: кнопки, поля ввода, карточки. А дизайн-система — надстройка над обоими: она добавляет правила, токены, документацию и процесс принятия решений, который живёт дольше любого редизайна.

Что делать первым? Если у компании один продукт — начинайте с UI-кита на основе существующего брендбука, дизайн-система в полном объёме здесь избыточна. Если продуктов три и больше, или экосистема растёт — стройте дизайн-систему сразу, иначе UI-киты продуктов разойдутся уже через полгода параллельной разработки.

Дизайн-токены: как один переменная синхронизирует дизайн и код

Токены — это именованные переменные, в которых хранятся значения цвета, шрифта, отступа, радиуса скругления. Не «#FFCC00», а «color-brand-primary». Первой этот подход системно применила Salesforce, и это буквально перевернуло индустрию: дизайнеры и разработчики перестали синхронизировать значения вручную, копируя хексы из макета в код.

Технически это сильно облегчилось с появлением Local Variables в Figma — теперь токены хранятся в одном месте и автоматически синхронизируются в код, без ручного экспорта JSON-файлов, как это делалось раньше.

Тёмная тема — лучший тест на то, правильно ли устроены токены в вашей системе. Если у вас захардкожен цвет текста, при переключении темы всё ломается вручную, компонент за компонентом. Если цвет привязан к токену «text-primary», который меняет значение в зависимости от темы — переключение происходит само. Показательный пример — дизайн-система Mediascope, где фирменный лимонно-жёлтый цвет для текста на светлом фоне автоматически заменяется на горчичный, потому что чистый лимонный на белом читается плохо. Цвет здесь работает по алгоритму контрастности, а не как статичное значение — и это правильный принцип для любой системы, которая заботится о доступности (WCAG).

Кейс: как дизайн-система перерастает в платформу — на примере банковской экосистемы

Пока у компании один цифровой продукт, дизайн-система остаётся словарём компонентов: кнопка, инпут, карточка. Проблема начинается, когда продуктов становится пять, десять, пятнадцать — как это произошло у Газпромбанка с Banka UI или у X5 с «Пятёрочкой». Каждая продуктовая команда хочет кастомизировать карточку товара под свою логику, и если система не готова к этому архитектурно, начинается расползание: одна и та же сущность выглядит по-разному в приложении, на сайте и в личном кабинете.

Решение — второй уровень абстракции. Система перестаёт быть просто набором компонентов и становится платформой с готовыми идиомами: например, карточка товара описывается не как один жёсткий шаблон, а как конструкция с явно зафиксированными точками кастомизации — что можно менять (текст, изображение, бейджи), а что менять нельзя (отступы, иерархия элементов, минимальная область касания). Похожий принцип реализован в МегаФоне: там система разделена на Core-уровень — базовые стили и компоненты, единые для всей компании, — и Product-библиотеки, где организмы и шаблоны адаптируются под конкретные вертикали бизнеса. Это позволяет держать общий ДНК бренда и одновременно давать продуктовым командам свободу там, где она действительно нужна.

Когда добавлять компонент, а когда — разрешить кастомизацию

Это решение почти никогда не описывают конкретно, а именно оно определяет, не превратится ли система в хаос за год активного роста. Рабочий алгоритм выглядит так:

1. Запрос поступает от продуктовой команды — фиксируется в общем бэклоге дизайн-системы, а не решается в переписке между двумя дизайнерами.
2. Проверяется частота: если похожий паттерн запрашивают две или больше команды — это кандидат в компонент системы, а не разовая кастомизация.
3. Проверяется совместимость с токенами и текущей архитектурой: можно ли реализовать через существующие переменные без создания нового визуального языка.
4. Если паттерн уникален для одного продукта и не противоречит принципам системы — выдаётся локальная кастомизация в рамках зафиксированных «точек свободы», без изменения ядра.
5. Если паттерн массовый и меняет саму логику взаимодействия — компонент дорабатывается на уровне Core, изменение проходит через ревью дизайн-совета.

Без этого процесса дизайн-система рано превращается в склад мёртвых компонентов, которые никто не поддерживает, потому что каждая команда сделала свою версию «на скорую руку».

Стоимость и сроки разработки

Цена сильно зависит от масштаба, и здесь нет смысла ориентироваться на абстрактные «от и до» без цифр. Дизайн-система с 40 базовыми компонентами обходится в 250–500 тысяч рублей, это 200–400 часов работы дизайнеров и разработчиков совместно. Крупная система — от 80 компонентов, с полноценной токенизацией, документацией и поддержкой тёмной темы — стоит $300–600 тысяч, а сроки растягиваются на 4–6 месяцев. Быстрее не получится сделать качественно: время уходит не на рисование компонентов, а на согласование правил между командами, а это самая медленная часть процесса.

Как добиться реального внедрения, а не системы «для галочки»

Готовая библиотека компонентов в Figma не равна работающей дизайн-системе — она становится рабочим инструментом только тогда, когда её реально используют в разработке. Внедрение обычно проходит через несколько этапов:

• аудит текущих интерфейсов и выявление уже существующих паттернов — система строится не с нуля, а на основе того, что реально работает;
• токенизация — перенос цветов, шрифтов, отступов в переменные до того, как начинается сборка компонентов;
• пилотный продукт — система внедряется на одном продукте, а не сразу во всей экосистеме, чтобы протестировать процесс без риска для всего портфеля;
• документация с примерами использования и явными запретами — что делать нельзя, а не только что можно;
• назначение владельца системы — команды или человека, который принимает решения по бэклогу изменений;
• метрики adoption — без них внедрение легко превращается в разовый проект, о котором забывают через полгода.

Показатели успеха измеримы: сокращение времени на проектирование интерфейсов на 30–40%, ускорение онбординга новых дизайнеров и разработчиков на 40%, заметное снижение нестыковок между макетом и реализацией — это результаты, которые наблюдают компании при правильной реализации и adoption дизайн-систем. Если через полгода после запуска системы эти цифры не двигаются — проблема не в компонентах, а в процессе принятия решений, который либо не выстроен, либо игнорируется командами.