Дизайн-система продукта — компоненты, токены и правила изменений

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

У дизайн-системы обычно два слоя. Первый — визуальные основы: типографика, цвета, сетка, интервалы, радиусы, тени и правила адаптации. Второй — компоненты: кнопка, поле формы, карточка товара, табы, уведомление, таблица, фильтр. Компонент описывают не как единственный рисунок, а как набор состояний и вариантов. Например, у поля есть обычное, заполненное, неактивное и ошибочное состояние; у кнопки — размер, приоритет, загрузка, реакция на наведение и фокус. Если в макете есть только обычная синяя кнопка, разработчик всё равно должен принять решения за дизайнера, а редактору и тестировщику нечем проверить результат.

Основа, из которой растут компоненты, часто называется токенами. Токен — это именованная переменная: не просто серый цвет с кодом, а, например, цвет вторичного текста; не случайный отступ, а шаг шкалы. Токены позволяют изменить правило в одном месте и применить его к интерфейсу последовательно. В коде они могут стать CSS-переменными, а в макете — стилями. Это не избавляет от дизайнерского решения: сначала команда должна определить, что именно считается вторичным текстом, опасным действием или акцентом. Иначе библиотека лишь быстро размножит случайные решения.

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

UI-kit отвечает на вопрос «из чего собрать экран», а дизайн-система — «по какому правилу решение останется одинаковым после следующего изменения».

Кроме компонентов, системе нужны принципы и паттерны. Принцип объясняет компромисс: например, почему критическое действие не прячут за наведением. Паттерн связывает несколько компонентов в повторяемую задачу — вход, поиск, оформление или исправление ошибки. Контент здесь не приложение к дизайну: текст кнопки, подсказка, пустое состояние и сообщение об ошибке входят в поведение паттерна наравне с разметкой и стилем.

Зачем это бизнесу? В продукте с несколькими командами одни и те же споры обычно повторяются: какого размера должна быть кнопка, где показывать ошибку, можно ли в новом разделе использовать другой фильтр. Без общего языка каждое изменение становится маленьким проектом согласований. С системой меняется не только скорость рисования экранов. Появляется способ оценить влияние правки: заменить компонент, создать новый вариант или сознательно сделать исключение. Для Руслана, который развивает технический каталог, это означает предсказуемые карточки, фильтры и таблицы; для Дарьи — понятнее планировать развитие личного кабинета и принимать работу подрядчика.

Но дизайн-система не окупается автоматически. Одноэкранному лендингу с одним призывом к действию обычно достаточно аккуратных стилей и нескольких повторяемых элементов. Создавать для него каталог токенов, версионирование и отдельный портал документации — значит тратить время на инфраструктуру, которой почти некому пользоваться. Другая крайность — собрать десятки универсальных компонентов до появления реальных сценариев. Получается витрина возможностей, но не инструмент: компонент не знает бизнес-контекста, а команда всё равно рисует исключения рядом с ним.

Хороший повод начать — не желание выглядеть технологично, а повторяемость. Посчитайте, сколько раз на продукте встречаются одни и те же поля, статусы заказов, таблицы и уведомления; сколько людей их меняют; где интерфейс уже выглядит по-разному для одинакового действия. Затем возьмите один болезненный поток, например оформление заявки или работу с каталогом, и опишите его компоненты со всеми состояниями. Это безопаснее, чем пытаться стандартизировать весь продукт за одну итерацию. Связь с адаптивным дизайном здесь прямая: у каждого компонента нужно заранее решить, как он перестраивается, а не надеяться, что мобильная версия получится сама.

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

Токен — именованное значение, которое описывает роль в интерфейсе: основной текст, опасное действие, граница блока, отступ между полями. В нём важнее не запись #123456, а смысл. Когда меняется фирменный акцент или контраст, команда корректирует роль, а не ищет вручную цвет в сотнях макетов и файлов стилей.

Обычно различают базовые и семантические токены. Базовый хранит исходное значение: цвет, размер, радиус, длительность. Семантический связывает его с назначением: text-primary, button-danger, space-section. Такая прослойка даёт возможность поменять тему, плотность или режим интерфейса без того, чтобы название цвета стало ложью. Но токены не решают, какую информацию показать в карточке и когда кнопка нужна пользователю: эти решения остаются в сценарии и контенте.

Design Tokens Format Module 2025.10 описывает формат обмена токенами между инструментами. Его опубликовала Community Group при W3C; это не стандарт W3C и не готовая модель для каждого продукта. Формат помогает передавать согласованные значения, но не решает, какие токены нужны, кто их меняет и как проверить влияние обновления.

На практике полезно начать с одного повторяющегося конфликта. Например, в формах разные команды по-разному показывают обязательность поля и ошибку. Пилотный компонент описывает подпись, помощь, значение, ошибку, disabled, загрузку, фокус и успешное действие. После этого видно, какие токены и правила действительно нужны, а какие существуют только ради аккуратной библиотеки.

Кнопка «Отправить» в статичном макете — не компонент в рабочем смысле. Компонентом она становится, когда понятны варианты текста, размер, приоритет, доступность, условия недоступности, реакция на повторный клик и место в потоке. Для карточки товара придётся договориться ещё о длинном названии, отсутствии изображения, недоступной цене, скидке, сравнении и узком экране.

Material показывает, что состояния взаимодействия — отдельный слой интерфейса. Это не обязанность копировать конкретную библиотеку Google. Смысл в другом: одинаковое действие не должно получать случайные правила в каждом разделе. Требования WCAG тоже нельзя переложить на один дизайн-файл: контраст, видимый фокус, доступное имя и порядок взаимодействия проверяются в итоговой реализации.

Исключения неизбежны. Важно не запрещать их, а записывать причину. Если новая форма не укладывается в общий компонент, команда выбирает: добавить вариант в систему, сделать локальное решение или пересмотреть сам сценарий. Такой журнал защищает систему от двух крайностей — бесконтрольного копирования и универсального компонента с тридцатью переключателями.

Компонент без состояний и условия применения — это картинка, которая переносит решение на разработчика и пользователя.

Расхождение обычно начинается незаметно: дизайнер поменял вариант карточки в макете, разработчик поправил старый компонент в коде, редактор добавил длинный заголовок. Через несколько релизов у названия один смысл, а у трёх реализаций — разное поведение. Поэтому версии и владелец нужны не бюрократии, а чтобы назвать актуальное правило.

Минимальный процесс может быть простым: заявка на изменение с контекстом, решение владельца, обновление макета и кода, пример использования, дата выпуска и проверка критических сценариев. В небольшой команде это одна задача в трекере и короткая страница документации. В большой — отдельный review и релизные заметки. В обоих случаях важно, чтобы ссылка на компонент в макете не обещала то, чего нет в production.

Перед общей заменой компонента стоит пройти хотя бы один старый экран с реальными данными и формой ошибки. Это помогает не сломать накопленный интерфейс «улучшением» общего правила. Frontend здесь важен не как техническая деталь, а как место, где договорённость становится поведением браузера.

Внедрение измеряют не числом нарисованных компонентов. Полезнее смотреть, сколько критичных экранов использует актуальный вариант, где остаются локальные копии, сколько времени занимает согласованное изменение и какие дефекты повторяются после релиза. Эти наблюдения не доказывают экономию сами по себе, но показывают, стал ли общий язык реально использоваться.

UX/UI-дизайн задаёт сценарий, который система должна поддержать. Frontend превращает правила в работающие компоненты; MVP помогает не строить библиотеку раньше, чем появилась проверяемая потребность. Для повторяющихся изменений полезно заранее договориться, что будет считаться экспериментом и как его проверять в A/B-тестировании.

Дизайн-система нужна не для коллекции компонентов, а для управляемого развития интерфейса. Начинать стоит с реального повторяющегося сценария и честно фиксировать правила, а не с универсальной библиотеки на будущее. Если новый экран требует исключения, это не провал: повод проверить, чего не хватает в компоненте, в правилах или в самом пользовательском сценарии.

Перед следующим кварталом полезно выбрать не число новых компонентов, а один измеримый долг: несогласованные формы, разные статусы заказа или повторяющиеся фильтры. Для него назначают владельца, границу пилота и способ проверить, что общее правило действительно работает в макете и браузере. Если пилот затронул один экран, его ещё не стоит объявлять системой: перенесите правило, например форму, из заявки в личный кабинет и сверьте, совпадают ли состояния и логика в макете, коде и документации. Если во втором контексте приходится заново придумывать исключения, пилот зафиксировал частный шаблон, а не общее правило. Такой старт не обещает мгновенную экономию, зато не создаёт инфраструктуру без пользователя.