Дизайн-система для веб-дизайнера
Практическое объяснение дизайн-системы: из чего она состоит, чем отличается от UI-кита и какой может быть первая рабочая версия для сайта

Дизайн-система даёт веб-дизайнеру общий набор токенов, компонентов, паттернов, документации и правил владения. Она уменьшает количество случайных расхождений, помогает продумывать адаптивные состояния и упрощает передачу макетов в разработку. Небольшому сайту не нужна корпоративная библиотека, но полезна компактная система повторяющихся проектных решений.
Библиотека компонентов превращается в дизайн-систему не тогда, когда в Figma аккуратно разложены кнопки, а когда команда может объяснить, зачем нужен компонент, где его применять, как он ведёт себя в разных состояниях и кто отвечает за изменения.
На референсе с принципами бренд-дизайна в Refframe виден связный визуальный язык: цвет, типографическая шкала, интервалы, разделители и трёхколоночный ритм поддерживают друг друга. Дизайн-система должна сохранить эти отношения как повторяемые решения, а не заставлять следующего дизайнера имитировать скриншот.
Дизайн-система - это общий договор
Рабочая система связывает шесть слоёв. Основы задают цвет, типографику, интервалы, радиусы, тени и движение. Токены дают этим решениям устойчивые имена. Компоненты объединяют их в повторяемые элементы интерфейса. Паттерны объясняют, как компоненты решают типовые задачи. Документация фиксирует назначение и ограничения. Управление определяет, кто и по каким правилам меняет систему.
Библиотека референсов находится рядом, но выполняет другую работу. Референсы сохраняют визуальный контекст до того, как решение стало правилом. Токены и компоненты сохраняют правило после того, как команда его приняла.
Поэтому UI-кита недостаточно. Он обычно показывает доступные детали. Дизайн-система дополнительно описывает состояния, адаптивное поведение, ограничения контента, требования доступности, связь с кодом и владельца решения.
Что меняется в повседневной работе
Ценность системы не в том, что все страницы начинают выглядеть одинаково. Она делает повторяющиеся решения намеренными.
Веб-дизайнер получает ответы на конкретные вопросы:
- какой цвет текста используется на приглушённой поверхности;
- есть ли у вторичной кнопки состояния загрузки и блокировки;
- как перестраиваются три карточки при длинном тексте и узком экране;
- является ли новый интервал осознанным исключением или случайным значением;
- какой компонент в коде соответствует компоненту в Figma.
Спор тоже становится предметнее. Вместо обсуждения, кажется ли отступ немного неправильным, команда решает, подходит ли текущая шкала интервалов для этого сценария и стоит ли её расширять.
Первая версия может быть небольшой
Сайту из пяти страниц редко нужна инфраструктура крупного продукта. Начните с решений, которые уже повторяются.
Для обычного веб-проекта достаточно:
- семантических цветов для текста, поверхностей, границ, действий и статусов;
- короткой типографической шкалы для дисплейного текста, заголовков, основного текста, подписей и меток;
- шкалы интервалов;
- ширины контейнеров, колонок, полей и правил перестройки;
- кнопок, ссылок, полей, карточек, навигации и нескольких контентных паттернов;
- состояний hover, focus, active, disabled, loading, error и success там, где они нужны;
- коротких заметок по применению и назначенного владельца.
Переменные Figma хранят повторяемые значения и режимы, а компоненты, варианты и свойства моделируют поведение элементов. Механику описывают официальные руководства Figma по переменным и компонентам. Главная дизайнерская задача - выбрать небольшой словарь, который соответствует продукту, а не выставить наружу каждое исходное значение.
Токены должны описывать назначение
Название blue-500 сообщает, как выглядит значение. Название text-primary или action-background сообщает, какую работу оно выполняет. Оба уровня полезны: примитивная палитра хранит исходные значения, а семантические алиасы связывают их с ролями интерфейса.
U.S. Web Design System описывает токены как ограниченный набор вариантов для цвета, интервалов, типографики и других свойств. Ограничение здесь полезно: система уменьшает случайный выбор, но оставляет место для обоснованных исключений.
Системе нужны примеры и границы
На старте документация может находиться прямо рядом с компонентами. Для важной переменной или компонента укажите назначение, правильный пример, ошибочное применение, ограничения контента, поддерживаемые состояния и ссылку на реализацию.
Отдельно запишите границы системы. Промостраница может намеренно использовать другой дисплейный шрифт. Плотной таблице может понадобиться интервал, которого нет в маркетинговых карточках. Названное и проверенное исключение не разрушает систему. Незаметное исключение создаёт дрейф.
Начните с аудита интерфейса
Выберите три показательные страницы: контентную, конверсионную и страницу с формой или интерактивностью. Соберите повторяющиеся цвета, текстовые роли, интервалы, контейнеры, контролы и состояния. Объедините почти одинаковые значения и проверьте, несёт ли различие смысл.
Создайте в Refframe одну доску с визуальными прецедентами проекта. Отделите референсы структуры от примеров тона, типографики и взаимодействия. Доска сохранит аргументацию, а дизайн-система превратит принятые решения в повторяемые правила.
Цель не в том, чтобы задокументировать весь интерфейс до следующего макета. Достаточно сделать следующее повторяющееся решение понятнее и менее зависимым от памяти.
Источники
- Guide to variables in Figma, Figma
- Components collection: Overview, Figma
- Design tokens, U.S. Web Design System