Как мы используем Figma API для доставки дизайна в Production

Alex Dyakov
Яндекс.Карты Mobile
5 min readNov 21, 2019

Я продуктовый дизайнер в Яндекс.Картах и хочу рассказать, как мы связали макеты в Figma с разработкой и кодом. Сейчас изменения графики, стилей текста и цветов автоматически прорастают в код мобильных приложений. Но сначала расскажу почему мы выбрали для этого Figma.

Почему Фигма?

Раньше у нас была цепочка из нескольких инструментов и довольно непростой процесс. Мы использовали Sketch — для макетов, Zeplin — для передачи макетов разработке и PaintCode — для передачи графических ресурсов в разных форматах (xml, objective-c/swift). Сами макеты и ресурсы хранились в облаке (Яндекс.Диске), вся команда имела к ним прямой доступ.

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

Для передачи графических ресурсов мы решили использовать возможности API фигмы. Как оказалось, API фигмы дает доступ ко всей структуре файла и позволяет экспортировать любые части в нужные нам форматы. Некоторые ребята уже сейчас используют API в своем процессе. Так, например, Github получает иконки для своего веб-интерфейса из макета фигмы. А еще есть инструмент Relay, который позволяет выгружать всю графику напрямую в ваш репозиторий github . Я сделал подборку полезных ссылок про работу API Figma:

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

--

--