Пока продукт небольшой, команда может обходиться отдельными договорённостями: какой цвет использовать для основной кнопки, как показывать ошибку и какие отступы оставлять между полями. С ростом продукта эти решения начинают расходиться. В макетах появляются похожие компоненты с разными названиями, а разработчики заново уточняют уже обсуждённые детали.
Дизайн-система объединяет повторяемые решения, правила их применения и порядок обновления. Разберём, с чего начать, как организовать библиотеку в Pixso и как передавать изменения между дизайном и разработкой.
Что такое дизайн-система и зачем она нужна
Дизайн-система — это набор компонентов, визуальных решений и правил, по которым команда создаёт и развивает интерфейс. В неё входят не только кнопки и поля ввода, но и объяснение их поведения: когда показывать ошибку, как обозначать недоступное действие и что происходит после отправки формы.
Её польза заметна в повторяющихся задачах. Если форма регистрации и форма оплаты используют одинаковое поле, дизайнеру не нужно заново определять его состояния. Разработчик получает согласованное описание, а при изменении компонента команда понимает, какие экраны нужно проверить.
Из чего состоит дизайн-система
Стили и дизайн-токены. Стили задают повторяемое оформление, например параметры текста. Токены связывают название с конкретным значением — цветом, размером или другим параметром. Название по назначению, например цвет ошибки, помогает обсуждать решение независимо от его текущего значения. Цветовые роли в интерфейсе связывают палитру с фоном, текстом, действием и состояниями.
Библиотека компонентов. Кнопки, поля и карточки должны включать состояния, которые действительно нужны продукту. Для поля это могут быть обычное состояние, ошибка и недоступность. Иконки и изображения — тоже дизайн-ресурсы, но их наличие само по себе не заменяет описание поведения компонента. При выборе настроек кнопки полезно разделить варианты и булевы свойства компонентов: первые задают оформление и состояние, вторые позволяют управлять видимостью необязательных элементов.
Правила применения и обновления. Укажите, когда выбирать компонент, какие свойства можно менять и кто принимает решение о новой версии. Один и тот же компонент без понятных правил легко превращается в десятки несогласованных копий.
Зафиксируйте правила оформления UI-компонентов рядом с примерами использования. Начните с элементов, которые повторяются чаще всего, а не с попытки заранее описать весь будущий продукт.
Как поддерживать согласованность дизайна и кода
Компонент в макете и компонент в программном проекте — разные ресурсы. Общее название помогает их сопоставить, но изменение макета ещё не означает, что разработчик обновил реализацию.
Например, команда меняет высоту поля и положение текста ошибки. В библиотеке дизайна нужно подготовить состояния и опубликовать изменение; в коде — изменить компонент и проверить его в формах. Если форма в коде использует дополнительную подсказку, которой нет в макете, это расхождение нужно обсудить отдельно.
Назначьте ответственных за библиотеку и реализацию, согласуйте названия и описывайте причину каждого существенного изменения. Так разработчик понимает, что требуется перенести, а дизайнер — где новая версия уже используется.
Как использовать DSM и библиотеку Pixso
В Pixso библиотека помогает повторно использовать компоненты и стили, а режим управления дизайн-системой DSM — работать со спецификациями ресурсов и их соответствием коду.
Чтобы открыть DSM, выберите файл с опубликованной библиотекой. В документации описаны три входа:
Меню названия файла в редакторе: режим дизайн-системы.
Раздел ресурсов команды: открытие файла в дизайн-системе.
Список библиотек в редакторе: открытие дизайн-системы выбранной библиотеки.
Псевдонимы связывают названия в дизайне и коде. В DSM дизайнер и разработчик могут задать соответствие для ресурса. Например, договориться, какое имя компонента в макете соответствует имени во фронтенд-библиотеке. Если названия и свойства уже совпадают, дополнительный псевдоним может не понадобиться.
Для работы с кодом настройте сопоставление под библиотеку проекта. Полученный фрагмент разработчик проверяет и интегрирует в приложение. Согласованные имена сокращают ручную расшифровку макета, но не обновляют программный репозиторий автоматически. Порядок настройки описан в документации DSM для разработчиков на английском.
Обзор продукта поможет спланировать управление дизайн-системой в Pixso. Для первого применения выберите небольшой набор: основную кнопку, поле ввода и связанные стили. На нём проще согласовать названия и передачу изменений.
Как публиковать и принимать обновления библиотеки
Здесь важно различать работу внутри одного файла и использование общей библиотеки. В одном файле изменения основного компонента применяются к связанным экземплярам с учётом их переопределённых свойств. Чтобы передать изменения опубликованного компонента в другие файлы, нужно сначала опубликовать новую версию ресурсов.
После публикации Pixso сообщает об обновлении в файлах, где используются соответствующие компоненты и стили. Участник команды просматривает изменения и принимает все обновления или отдельные. Применение можно отложить и вернуться к нему через библиотеку. Это управляемое обновление, а не немедленная замена всех макетов команды. Действия описаны в справке «Библиотека ресурсов».
Предположим, у основной кнопки увеличили высоту, чтобы разместить длинные подписи. Автор библиотеки описывает изменение и публикует его. Дизайнер экрана оплаты просматривает обновление, применяет его и проверяет строку с двумя кнопками. Если новая высота нарушает расположение элементов, он исправляет экран до передачи в разработку. Команда получает повторно используемый компонент и сохраняет контроль над конкретным макетом.
Определите, кто публикует ресурсы, кто принимает обновления в продуктовых файлах и кто переносит изменения в код. Права на просмотр и редактирование настраивайте под эту работу. В описании версии указывайте затронутые состояния и ожидаемый результат: «Увеличена высота кнопки; проверьте формы с длинными подписями» полезнее, чем «Улучшен дизайн».
Частые вопросы
Нужна ли дизайн-система маленькой команде?
Начните с общего набора часто используемых компонентов и коротких правил. Полноценная документация для каждого возможного сценария обычно не нужна на старте. Расширяйте систему там, где повторяются вопросы, возникают дубли или расходятся макеты и код.
Чем дизайн-система отличается от UI-кита?
UI-кит прежде всего содержит готовые визуальные элементы. Дизайн-система также описывает их назначение, поведение, связь с реализацией и порядок изменений. Команда должна понимать не только где взять кнопку, но и какую выбрать и как обновлять экраны после её изменения.
Обновятся ли все файлы сразу после изменения компонента?
Изменение основного компонента внутри файла и обновление общей библиотеки — разные процессы. Для других файлов изменения сначала публикуют, затем их можно просмотреть и применить. Поэтому при планировании релиза нужно учитывать и обновление библиотеки, и принятие изменений в рабочих макетах.
Как передать изменения разработчику?
Укажите компонент и изменённые свойства, приложите необходимые состояния и согласуйте соответствующие имена в коде. Настройки DSM помогают связать ресурсы, но реализацию и поведение готового интерфейса команда проверяет в самом проекте.
Начните с одного повторяющегося сценария
Возьмите форму, которая встречается в нескольких частях продукта. Соберите её общие компоненты и состояния, договоритесь о названиях и опубликуйте библиотеку в Pixso. Затем проведите одно изменение через весь процесс: публикацию, просмотр обновления, применение в макете и реализацию в коде. На таком небольшом участке быстро видно, какие правила и роли ещё нужно согласовать.
