Дизайн-система для веб-дизайнера

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

Процессы
Refframe Team8 мин
Правила типографики, цветов, компонентов и компоновки связаны с макетом сайта
Визуальный язык становится системой, когда его решения названы, повторяемы и поддерживаются командой.

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

Библиотека компонентов превращается в дизайн-систему не тогда, когда в 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 одну доску с визуальными прецедентами проекта. Отделите референсы структуры от примеров тона, типографики и взаимодействия. Доска сохранит аргументацию, а дизайн-система превратит принятые решения в повторяемые правила.

Цель не в том, чтобы задокументировать весь интерфейс до следующего макета. Достаточно сделать следующее повторяющееся решение понятнее и менее зависимым от памяти.

Источники

  1. Guide to variables in Figma, Figma
  2. Components collection: Overview, Figma
  3. Design tokens, U.S. Web Design System