Творчество без рутины: как мы автоматизировали процессы с Figma

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

Года полтора назад мы уже рассказывали о наших дизайн-процессах на примере проектирования. Тогда мы использовали связку Axure — Sketch — Zeplin, и она нас полностью устраивала. Но у этой системы есть минусы. Мы сталкивались с рассинхроном между ожидаемыми и фактическими трудозатратами на проекте. К тому же она обречена на потери данных.

Пара примеров. Данные из Axure в Sketch переносятся вручную по блокам — долго, легко ошибиться. Sketch — хороший инструмент, но, увы, не облачный. Чтобы команда увидела изменения, нужно вручную выгрузить новую версию макета в Zeplin или Dropbox — тоже долго, тоже легко ошибиться. Да, мы в курсе, что в Sketch уже начали прикручивать возможность работы с облаком, но поезд уже ушёл.

Раньше мы легко справлялись с этими трудностями, но проекты агентства становятся крупнее: средний по масштабам уже превышает 100–150 экранов. Соответственно, и потерь становится всё больше, а уследить за ними всё тяжелее. Поэтому мы решили перейти на инструмент с единой средой. Так мы и задумались о Figma.

Подготовка к переходу началась осенью. В октябре мы провели первые тесты: прогнали через Figma несколько проектов. Нам понравилось. При этом мы нашли, как ещё можно применять этот инструмент.

В начале ноября полноценно внедрили Figma в наши процессы, а декабрь посвятили автоматизации разного рода рутины. Но обо всём по порядку.

В большинстве студий и агентств прототипы ограничивается базовыми экранами и состояниями. Их выбирают по основным пользовательским сценариям: например, поиск товара в интернет-магазине и покупка. Второстепенные сценарии на прототипах часто пропускают или показывают поверхностно. Всё потому, что небольшие компании не могут себе позволить отвести лишнюю неделю работы специалиста, чтобы добавить несколько состояний.

Классический прототип представляет из себя набор страниц, связанных друг с другом ссылками. Чем сложнее продукт, тем больше в нём взаимосвязей, в том числе неочевидных. Риск что-то упустить всегда высок.

Это касается не только команды дизайнеров. Менеджер может что-то не заложить в смету, из-за чего случаются факапы по срокам. Разработчик может не понять, как работает переход между экранами, и сделать не то.

Чтобы все эти связи продумать сразу, нужно делать детальный прототип.

Мы изучаем аналитику клиента, проводим исследования и на основе результатов определяем основной принцип взаимодействия: мобильные или десктопные устройства.

Исходя из этого, выбираем базовое разрешение. Отрисовываем его, учитывая все состояния страниц, неявную функциональность и неочевидные, но возможные сценарии. В остальных разрешениях готовим ключевые и нестандартные страницы.

Создавать настолько детальные прототипы в Axure и переносить их вручную в Sketch — обрекать себя на страдания. Но с Figma мы теперь делаем такие проекты без боли.

Передача материала дизайнеру стала намного проще: он клонирует себе основной проект и продолжает в нём работу.

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

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

Рефакторинг дизайна — процесс трудоёмкий. Зато после него мы быстрее собираем остальные страницы. В целом по срокам выигрываем, плюс получаем чистенький дизайн.

Фронтенд-разработчики тоже экономят много времени и сил. Раньше им приходилось размышлять: «В этих местах отступы отличаются на два пикселя, а тут шрифты отличаются только межстрочным интервалом — это косяк или так задумано?» После рефакторинга у них такие вопросы возникают значительно реже.

В прошлом инструментарии не было набора предустановленных компонентов, из которых можно быстро собирать прототипы. Поэтому прототипы получались разнородными. Когда мы перешли на единый инструмент, этот момент стал более явным — прототипы нужно стандартизировать.

Мы сформировали в Figma свою библиотеку компонентов: сетки, шрифтовые стили, контролы, отступы, наименования цветов, типовые иконки.

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

Библиотека компонентов и гайдлайн помогают дизайнерам быстрее готовить прототипы и дизайн-макеты. Разработчикам — не тратить время на рутину. Компании — поднять планку качества.

Когда мы собираем адаптивные макеты и прорисовываем различные состояния, нас сильно выручает функция Auto Layout, которая появилась в Figma в ноябре 2019 года.

В Sketch мы теряли много времени на pixel perfect и мелкие доработки. Допустим, в макет понадобилось добавить кнопку или изменить название у продукта в каталоге. Для этого приходилось вручную перемещать на холсте все объекты, стоящие ниже того, который мы редактируем. Долго, легко ошибиться. Сейчас можно настроить так:

Новая функция в Figma в этом плане делает волшебство. Связываем элементы в Auto Layout, задаём выравнивание, отступы. Теперь можем менять содержимое объекта — все заданные параметры сохраняются. Разные объекты можно объединить между собой в блок, к которому также применяется Auto Layout.

Перемещаем блок куда нужно и при этом не перетаскиваем остальные элементы. Нужно вставить кнопку — перетаскиваем в нужное место мышкой, и она сразу встаёт так, будто была там всегда.

Что важно, у нас получилось использовать Auto Layout на уровне страниц. Теперь дизайнер один раз задаёт базовые правила на рефакторинге дизайн-концепции и собирает остальные страницы, как в конструкторе. Меньше рутины — больше времени на погружение в проект.

Это хорошо видно на примере отступов между элементами в макетах. Наша идеология работы с отступами близка к идее Kelnik. Но раньше следовать ей было тяжело.

Вот понадобилось, например, поменять отступ между заголовком и блоком над ним. Нам для этого нужно было пройтись по всем макетам и везде поправить этот отступ вручную, сдвигая весь контент. Сейчас в таких случаях меняем высоту компонента в одном месте — всё остальное перестраивается само.

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

Мы написали набор скриптов и получили инструмент, который назвали «Автоматизация раздражающей аналитической работы» (Automatization of Nerve-wracking Analytical Labour). Сокращённо ANAL.

Вот что мы сделали.

Раньше у нас не было стандарта для названий. Каждый обозначал макеты так, как ему было удобно, но нам это не мешало. Когда же проекты стали крупнее, началась путаница.

Поэтому мы разработали понятную и прозрачную систему. Такую, чтобы по одному лишь названию было предельно понятно, что это за страница и где её место в проекте. Клиентам тоже нетрудно в ней разобраться, и это помогает нам говорить с ними на одном языке. Теперь названия выглядят так:

Первая цифра — раздел. Вторая цифра — страница. Третья — состояние страницы. Буква — тип устройства (M — мобильные, T — планшеты, D — десктоп).

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

Плагин разбирает эти макеты, на основе ширины определяет тип устройства и готовит к формату, который потом скармливается API (о нем ниже). В качестве бонуса он добавляет шаблоны для разметки названий страниц и разделов, это пригодится при выгрузке на следующих этапах.

Раньше всё выгружалось вручную в Dropbox или отдельными ссылками на Figma. Если блок макетов был большим, менеджер проходил по каждому, копировал ссылки в табличку и отдавал клиенту.

Решение нашли в генерации обычных страничек на основе макета. ANAL парсит список через API Figma, разбирает по разрешениям и группирует по разделам согласно нумерации. От менеджера требуется только выбрать необходимый набор строк и передать клиенту.

Нам она нужна, чтобы понимать, что мы должны сделать и сколько времени мы на это потратим. Клиенту — чтобы понимать, за что он платит деньги.

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

Дизайнеры и разработчики проходятся по состояниям, выбирают, что из всего этого им нужно будет подготовить, и проставляют часы.

Раньше менеджеры создавали таблицу вручную на основе списка макетов из Axure и Sketch. Порой вообще на основе файлов в Dropbox. Долго, муторно.

Вместе с менеджерами мы подготовили шаблон Google-таблички. Затем с помощью API настроили выгрузку данных из Figma под этот шаблон. Все формулы, ссылки на страницы и состояния вплоть до разрешений проставляются автоматически.

Теперь менеджеру достаточно лишь вставить ссылку на файл в ANAL и проверить корректность выгрузки. Часы рутины мы заменили парой кликов мышкой. Менеджеры рады, а наши сметы стали точнее и аргументированнее.

По сути, это техническое задание для разработчика. Единого стандарта нет, но обычно это длинные, нудные и подробные текстовые документы. Многие пишут их чисто ради отчётности, потому что разработчики их всё равно не читают.

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

Решение нашли в системе комментариев в Figma. Она позволяет создавать ветку обсуждения для каждого комментария, а еще привязывать комментарии к конкретному месту на странице. Комментарии нумеруются, есть возможность на эти комментарии ссылаться.

Все важные вещи, на которые нужно обратить внимание разработчику, пишем в комментариях. Ссылку даём скрипту — получаем Google-документ. В нём всё разложено по полочкам: перечислены все страницы, состояния, пояснения к ним и прямые ссылки на соответствующие макеты. Включая нумерацию комментариев из Figma.

Остаётся внести пару чисто косметических правок, дописать не относящиеся к макетам разделы и передать документ разработчику.

В итоге UX-дизайнер производит разметку быстро и в удобной для него среде. Менеджер экономит кучу времени на написание отчётности. Разработчик получает документ, в котором всё чётко-ясно. При этом он в любой момент может перейти в Figma, где всё будет ещё и кликабельно.

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

Нам стало легче прогнозировать ресурсы на разработку и попадать в первоначальную оценку. Теперь команда реже пропускает какие-то функциональные элементы и чаще попадает в сроки.

Проекты в целом мы теперь прорабатываем глубже и запускаем быстрее. Клиент при этом получает больше возможностей для тестирования своих гипотез на ранних этапах.

Мы продолжаем двигаться в сторону автоматизации процессов, минимизации рутинных операций у наших ребят, и есть ощущение, что в этой теме можно найти еще много интересного. И это главный итог — Figma позволила нам совершенствовать свои процессы непрерывно.

#figma #макеты #процессы