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

Alex Dyakov
Nov 21, 2019 · 5 min read

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

Яндекс.Карты Mobile

Опыт разработки, истории и советы от команды мобильного приложения Яндекс.Карты

Thanks to Николай Лихогруд and Alexander Goremykin

Alex Dyakov

Written by

Product designer at Yandex

Яндекс.Карты Mobile

Опыт разработки, истории и советы от команды мобильного приложения Яндекс.Карты

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade