Как мы используем Figma API для доставки дизайна в Production
Я продуктовый дизайнер в Яндекс.Картах и хочу рассказать, как мы связали макеты в Figma с разработкой и кодом. Сейчас изменения графики, стилей текста и цветов автоматически прорастают в код мобильных приложений. Но сначала расскажу почему мы выбрали для этого Figma.
Почему Фигма?
Раньше у нас была цепочка из нескольких инструментов и довольно непростой процесс. Мы использовали Sketch — для макетов, Zeplin — для передачи макетов разработке и PaintCode — для передачи графических ресурсов в разных форматах (xml, objective-c/swift). Сами макеты и ресурсы хранились в облаке (Яндекс.Диске), вся команда имела к ним прямой доступ.
Мы давно смотрели в сторону альтернатив и в начале мая решили изменить свой стек в сторону фигмы. В отличии от скетча, фигма позволяет более гибко работать с библиотекой компонентов, улучшает взаимодействие в команде, решает проблемы хранения и передачи макетов разработке, так как хранит всё в облаке. Переход в фигму в нашем случае исключал из цепочки Zeplin и Диск, а это уже минус два инструмента.
Для передачи графических ресурсов мы решили использовать возможности API фигмы. Как оказалось, API фигмы дает доступ ко всей структуре файла и позволяет экспортировать любые части в нужные нам форматы. Некоторые ребята уже сейчас используют API в своем процессе. Так, например, Github получает иконки для своего веб-интерфейса из макета фигмы. А еще есть инструмент Relay, который позволяет выгружать всю графику напрямую в ваш репозиторий github . Я сделал подборку полезных ссылок про работу API Figma:
- Документация к API с понятными примерами на сайте Figma.
- GitHub использует Figma API для своих процессов, небольшой рассказ про это. А еще про взаимодействие внутри команды.
- Relay for Figma. Инструмент для выгрузки графики из макета в ваш github.
- Figma to React в блоге Figma.
- Подробный разбор работы API фигмы.
У нас, как у и всех, была дизайн-библиотека в скетче, которая хранила все наши переиспользуемые ресурсы. Для старта работы нам сначала нужно было переформатировать нашу дизайн-библиотеку с учетом возможностей API фигмы.
Библиотека компонентов
Мы пересмотрели всю структуру библиотеки, думая сразу над тем, как будем отдавать ресурсы разработке. Получилось разделить все на три файла:
- Core хранит цвета, стили текста и интерфейсные иконки. Этот файл используется только дизайнерами. Здесь могут храниться как финальные решения, так и драфты иконок или цветов.
- Atoms содержит компоненты (кнопки, списки и тд), которые мы постоянно используем в создании интерфейса;
- Dev Core хранит финальные ресурсы для разработки и спецификации компонентов. Сюда мы складываем ресурсы для экспорта разработчикам. Как раз про него далее и пойдет речь.
Интеграция библиотеки в код
Мы хотели получить систему, при которой все ресурсы забираются автоматически через API фигмы. То есть, если мы захотим изменить какой-либо цвет в интерфейсе, стиль текста или иконку, это можно будет сделать только в фигме и не использовать другие инструменты (PaintCode, ручной экспорт ресурсов).
Находясь в постоянном контакте с разработкой, мы согласовывали внутри каждый момент, чтобы всем было удобно. В итоге выработали схему отдельных страниц для иконок, цветов, стилей текста и компонентов, удобную для автоматического экспорта через API. Это дало жесткую связку дизайн-библиотеки и кодовой базы. Сейчас наша команда разработки запускает скрипт и получает все обновления напрямую за пару секунд.
Но, конечно, не обошлось без трудностей. Как вы знаете, разные платформы используют разные ресурсы: Android — drawable xml, iOS — pdf/png, Web — svg. Фигма не поддерживает экспорт в drawable xml, поэтому ребятам из андроида приходится на своей стороне дополнительно делать из svg xml. Помимо этого, у Карт есть ночная и дневная тема, а значит, и у ресурсов должны быть две версии. Мы делаем дневную и ночную версии для сложной графики, которая состоит из нескольких цветов. Если же иконка одноцветная, то она красится маской на стороне разработки, а в файле Dev Core она черная.
В итоге был автоматизирован очень кропотливый процесс, но это накладывает ряд ограничений — приходится придерживаться четких правил по неймингу. Мы используем только lowercase названия с нижним подчеркиванием. Например, для иконок формат правильного имени получился такой: [name]_[state]_[size]_[day/night].
С большим количеством ресурсов легко ошибиться, нам нужна была дополнительная проверка на стороне фигмы, чтобы процесс парсинга был всегда беспроблемным. К счастью, не так давно фигма начала поддерживать плагины, и, чтобы проверять валидность библиотеки на стороне дизайнеров, я написал свое расширение.
Плагин для проверки библиотеки
Написать плагин оказалось совсем несложно, у фигмы отличная документация, писать нужно на JS. Сразу скажу, что делать с файлом фигмы через код можно все что угодно, посмотрите на кучу плагинов, доступных прямо сейчас. Еще удобно, что любой код легко проверить в консоли.
Наш плагин для Figma умеет следующее:
- проверяет все ли в порядке с именами. Если есть ошибка, то проблемные объекты выделяются и вас призумливает к ним, показывается сообщение. Это нужно, потому что дизайнеры могут случайно использовать не тот символ (например русские символы, пробелы или тире);
- находит дубликаты по имени, выделяет объекты с ошибками и призумливает к ним, выводит сообщение;
- проверяет наличие пары Day/Night. Важно, чтобы объекты которые имеют дневную версию имели и ночную версию.
- расставляет все объекты в алфавитном порядке для удобства.
Если вам интересно, то код моего плагина найти можно здесь.
Компоненты
Помимо прочего, в Dev Core мы храним компоненты дизайн-системы и их описание. Сейчас это кнопки, списки, лоадеры, шапки, различные попапы и тд. Все эти компоненты привязаны к нашим дизайн-библиотекам.
Это нужно для того, чтобы у дизайна и разработки были единые компоненты и единый свод правил. Еще наша команда разработки собрала приложение для просмотра всех ресурсов и компонентов на мобильном устройстве. Все что забирается из фигмы собрано там и это легко посмотреть в одном месте.
Итог
Figmа позволяет нам работать в тесном контакте с разработкой и делать продукт быстрее и лучше. Как итог мы смогли автоматизировать очень рутинную часть своей работы и существенно упростить процесс. В наших планах интегрировать фигму еще и в процесс создания карт.