Дизайн
ADN Agency
11 475

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

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

В закладки
Аудио

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

Алексей Шепелин
арт-директор

Зачем всё поменяли

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

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

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

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

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

Прототипирование

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

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

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

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

​Тут только мобильная версия. Для десктопа получится примерно такая же картина

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

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

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

Рефакторинг дизайна

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

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

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

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

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

Гайдлайн и библиотека компонентов

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

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

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

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

Auto Layout

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

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

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

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

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

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

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

Менеджмент

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

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

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

Автоматизация обозначения макетов

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

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

1.1.1.D Главная страница гость

1.1.2.M Авторизация пользователя на главной

2.1.1.T Каталог, список

2.1.2.M Каталог карточки

2.2.1.D Карточка продукта

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

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

  • Все макеты с одинаковыми координатами по оси Y принадлежат одному разделу.
  • Если отступ между макетами меньше X пикселей, это макеты одной страницы.
  • Если отступ между макетами больше Х пикселей, это разные страницы.

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

Выгрузка макетов для демо клиенту

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

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

Таблица оценки трудозатрат

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

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

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

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

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

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

Спецификация

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

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

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

​Представим, что название комментария — это заголовок блока, а ответы на него — абзацы текста в блоке. Да это же готовый инструмент разметки!
Если проект большой, выглядит внушительно.​

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

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

​Шаблон документа

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

Итого

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

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

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "ADN Agency", "author_type": "self", "tags": ["\u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b","\u043c\u0430\u043a\u0435\u0442\u044b","figma"], "comments": 110, "likes": 146, "favorites": 513, "is_advertisement": false, "subsite_label": "design", "id": 106807, "is_wide": true, "is_ugc": true, "date": "Thu, 13 Feb 2020 11:41:36 +0300", "is_special": false }
Создать объявление на vc.ru
Маркетинг
Управление репутацией, или инструменты, что увеличивают конверсию в заказы (SERM, отзывы и другие инструменты ORM)
Здесь вы получите полный разбор управления репутацией в интернете.
0
{ "id": 106807, "author_id": 107621, "diff_limit": 1000, "urls": {"diff":"\/comments\/106807\/get","add":"\/comments\/106807\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/106807"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199114, "last_count_and_date": null }
110 комментариев
Популярные
По порядку
Написать комментарий...
42

Коммент в поддержку перехода на Фигму. Когда в 2020 году присылают макет сайта в PSD, так и хочется спросить: «Да что, б**ть, с вами не так?!»

Ответить
4

Вы еще пороху не нюхали, видать) Еще присылают в иллюстраторе и ... Exel. 

Ответить
7

Корел забыли.:-)

Ответить
0

Я свой первый дизайн во Flash делал. До сих пор неловко становится, когда вспоминаю.

Ответить
1

За то четко и в векторе и с анимацией

Ответить
0

У меня пара случаев была - в jpg присылали свёрстанные макеты, говорили что это и есть исходник и страшно удивлялись, узнавая правду.

Ответить
3

Честно по началу тяжеловато было переходить на Figma с PS. Очень смущал маленький инструментарий. Но буквально сделав пару макетов - понял, что и не нужно столько инструментов, которые есть в PS.

Ответить
0

Эх, я один из тех, кто до сих пор шлёт макеты в psd :(
Фигма крутая, спору нет, и я с удовольствием на неё перейду, как только она научится поддерживать два и более монитора. 

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

Тут надо сделать ремарка, что дело не только в переключении с окна на окно, а и в возможности разнести панели инструментов на разные мониторы, чтобы оптимизировать рабочее пространство.

Ну и конечно же, хочется реально нативного приложения, а electron. Уверен, что это чисто моя личная доёбка, но инпут-лаг таки присутствует и он может доставлять неприятности в работе с большими макетами.

Ответить
5

У десктопного клиента можно запустить несколько окон (не говоря уже о вкладках браузера), можно разные окна разнести на разные мониторы, можно открыть в обоих окнах один и тот же макет.

Ответить
0

Видимо я не верно выразился или вы меня не верно поняли :) 

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

Дома у меня два монитора и обычно различные панели граф. редактора вынесены на второй монитор, таким образом у меня большая чистая рабочая область, скрин https://img.artc.at/scrn/1978521602363.jpg

В фигме же, по бокам не сворачиваемые панели, которые ограничивают рабочую область, скрин https://img.artc.at/scrn/7298158775048.png
Опять таки, может я чего-то просто не правильно делаю и панели таки сворачиваются? 

Ответить
1

Их можно скрыть в меню  (View -> Show/Hide UI), но так, как с продуктами Adobe, когда все панели на отдельном окне не получится, принцип работы другой. 

Ответить
1

По первому скриншоту видно что от трети до половины площади экрана вы всё равно не используете, даже при приближении страницы. Так как макеты страниц чаще вертикальные. Из этого могу предположить что вынос всех палитр на другой экран даёт скорее психологический эффект. Может это просто дело привычки? Подумайте об этом.

Ответить
0

Работаю уже 5 лет на MacBook Pro Retina - суть тут как раз в том что мобильные экраны видно в масштабе 1 к 1. Зачем нудно два монитора сложно даже представить. Тем более они точно у вас не Retina - а это же просто смерть глазам.

Ответить
0

В плане изображения самый лучший.

Ответить
4

Вы можете открывать 2 вкладки браузера на разных экранах и получите примерно тот же эффект.  Либо приложение для основной работы + вкладку браузера с прототипом. Я согласен, что есть свои минусы и лаги, но с точки зрения гибкости инструмент получился прекрасный.

Ответить
1

Согласен про гибкость. Пример того, что наворотили ребята из АДН — агоневый агонь! Особенно мне нравится пункт про автоматизацию спецификации :)

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

Ответить
0

Я так и не понял чем он лучше. Родноt приложение обновилось стало удобней в навигации и вклдках. Это приложение показывает по сути  web view. Открыл одно и тоже в обоих посмотрел занятую память в системе - тоже самое. У родного приложения висит task GPU Helper - значит есть какие-то оптимизации. 

Ответить
0

А я не говорил, что оно лучше. Я пользуюсь оригинальным. Просто это переписал на native энтузиастом, почитайте статью его на медиуме

Ответить
1

Очередной цифровой понтовщик. Вот когда вижу таких на vc хочется спросить: «да бл откуда вы такие вылезаете дешевые? Серёжа, не все сидят в фигма и скетч, очевидно.

Ответить
2

Ну, собственно, возникает вопрос - почему?

Ответить
0

Популярность же фигмы — ёпта, ИМХО — обусловлена её кроссплатформенностью, простотой работы, и возможностью бесплатно работать в браузере, а значит на максимальном количестве железа. 

А так как у нас уже после двух-трёх роликов на ютубе отдельные личности мнят себя не меньше, чем сеньёром, то и не удивительно, что о фигме говорят буквально на каждом углу :)

Ну и конечно же совместная работа и апи, которые стали киллер-фичей для компаний. Я до сих пор в легком восторге от описанного в статье В)

Ответить
2

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

Ответить
0

Тоесть, инструмент, который позволяет просто гибко и быстро выполнять задачу даже без скриптов, которые описаны в статье - непригоден для мелких агентств по вашему? Хм, мсье знает толк…

Ответить
0

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

Ответить
0

ого. такие случаи еще бывают?

Ответить
1

много... очень много!

Ответить
14

"Теперь менеджеру достаточно лишь вставить ссылку на файл в ANAL"

Что, прям туда?
*простите за испорченность*

Ответить
14

"чаще всего жалуются на выгорание — рутина. Автоматизация помогла нам её победить, если не всю, то почти всю."

..мне кажется вы не очень понимаете какую рутину дизайнеры имею ввиду)

Ответить
0

Но фраза понравилась

Ответить
3

"- Ребят, ANAL у всех отрабатывает?"

Ответить
18

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

Ответить
9

Ваша компания разрабатывает ANAL только своим сотрудникам?

Ответить
2

Это не наша технология, но стало интересно как ANAL может сделать работу более продуктивной

Ответить
0

Мне кажется в один прекрасный день ваши сотрудники слишком буквально поймут как работать с ANAL и переобутся. Острожнее.

Ответить
0

Раньше приходилось нанимать целый штат аналитиков чтобы сделать то, с чем справляется ANAL нашей компании.

Ответить
0

Спасибо, я ждал эти комментарии

Ответить
5

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

Ответить
–17

Сделали бы они десктопную версию, цены бы Фигме не было. А так, такой же тормозящий кал, как и Марвелапп со Студио от Инвижн

Ответить
12

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

Ответить
0

Можно вопросик? Насколько крупный проект вы поддерживаете в фигме? И как предугадать когда интернета не будет?

Ответить
1

Все ок работает MacBook Pro 2018 
Sketch тупит в разы сильней на таких же макетах

Ответить
0

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

Ответить
3

В каком месте Figma тормозит? Вообще не замечаю лагов. Единственное - нужно время на подгрузку элементов при запуске макета.

Ответить
0

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

Ответить
–1

Фигма лагает только в том случае, когда в проекте есть растр, во всех остальных ни разу не видел лагов при любых размерах проекта

Ответить
0

Хм. Интересное замечание. На собственном опыте наблюдение основано?

Ответить
0

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

Ответить
0

Со скетчем таких проблем вообще нет)

Ответить
0

Figma - подтягивает проект с облака. Sketch - загружает локальный проект.

Ответить
–1

да ладно) а я и не знал)) спасибо! вы мне глаза открыли!

Ответить
0

Ну так и зачем сравнивать тогда по этому признаку редакторы?

Ответить
0

К слову сказать, читал я ваши комментарии чуть выше. Вот действительно, что странно, так это сравнивать Фотошоп и Фигму. Вообще любой растровый редактор с любым векторным. Сравнивали бы с Иллюстратором.

Ответить
0

Потому что я работал в Фотошопе. Иллюстратор это про создание чего то одного (лого, иконки, и вот это все). Не видел я, чтоб в Иллюстраторе сайты проектировали.

По этому я и написал про свой опыт.

Мне зашла Фигма. Вы работаете в Скетче. Если вам удобен Скетч - я не осуждаю.

Ответить
–1

Наверное, подходящих размерчиков не было? :)

Ответить
0

потому что я посчитал этот критерий важным для себя

Ответить
4

Полезная статья, спасибо. Было бы максимально полезно если бы ссылки были на инструменты (гитхаб на плагин для фигмы / таблицы / и тд) 

Ответить
1

Нет смысла выкладывать эти материалы в сеть. Плагин заточен под наш процесс и постоянно допиливается, API у Figma простое, главное ведь — идея. Таблица со спецификацией тоже заточена под нас и не даст вам большого профита в отрыве от других материалов.

Ответить
5

Я бы тоже посмотрел, ведь допилить основу можно под любой процесс. Даёшь свободный софт :)

Ответить
8

Пока не готовы. Но, вполне возможно, сделаем это, когда плагин получше допилим и подготовим инструкцию.

Ответить
4

В любом случае спасибо за идею, может раньше свой напишу тогда и опубликуюсь :Р

Ответить
1

было бы круто)

Ответить
0

Время бы еще подыскать под это, загвоздка в этом

Ответить
0

вопрос желания, и время можно запланировать 

Ответить
1

да, было бы очень полезно)

Ответить
0

Смысл есть , так как помимо прочтения сути хорошей идеи , существенно увеличит степень ее понимания прогнав ее через свой опыт/действия (используя так сказать демонстрационный кейс)

Ответить
3

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

Ответить
0

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

Ответить
0

код -> дизайн 

Есть уже в Реакте 

Ответить
0

Из макета в код и обратно? 

Ответить
1

Да, можно из из реакта в макет.
Есть react-sketchapp и react-figma . Еще react-studio но это отдельный инструмент. 

Ответить
0

может Framer X как-то с ней подружится через plugin 

Ответить
0

Думал об этом, но пока по затратам лично для нас не стоит оно того.

Ответить
2

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

Скетчевый плагин от Анимы решал эти проблемы ещё года три назад

Ответить
1

А что за третий блок удалили в конце? Наверняка можно было обойтись без него. Или объединить текст, инпут и этот невидимый отступ (если я правильно понял) в одну группу и удалить полностью

Ответить
2

Этот отступ - самое важное. Про него в статье была ссылка на то, как это Кельник делает. За счет того, что он есть и забит в компонентах проекта мы можем очень быстро менять все его экземпляры на проекте если это потребуется (а такое периодически может происходить). Здесь он просто с нулевым opacity стоит для красоты. Как-то так.

Ответить
0

Кстати, у Кельник и у вас на скрине – явно отмечены только вертикальные отступы, но как на счет горизонтальных? 

Ответить
0

Теоретически это можно делать, но на практике не имеет смысла. Слишком много условий, особенно если учитывать, что в рамках состояний экрана (например, Tablet 768 - 1024)  верстка обычно резиновая.

Ответить
0

Но фиксированных размеров тоже хватает: горизонтальный ряд интерфейсных элементов, аватар+ФИО и т.д.. С ними, как правило, такие же косяки на верстке. Мне просто интересно, где та грань, когда дизайнер перестает вручную воспроизводить функционал zeplin.

Ответить
2

Речь ведь не о дублировании zeplin, скорее о том, как упростить сборку макетов на основе предустановленных параметров. 

Для себя мы определяем основное: возможность повторного использования. С вертикальными это просто, они легко дробятся на классы (межблочные, внутри блока, внутри элемента и так далее). Из горизонталей тут на эту роль разве что паддинги идут у некоторых блоков, что довольно ситуативно и проще один раз такие штуки заверстать (по крайней мере пока это так, мб найдем удобное решение).

Ответить
0

А тут не круче было сделать компонент заголовок+поле и уже эти компоненты в автолейаут обернуть? Кажется, так вы бы избавились от этого костыля

Ответить
0

Да, тоже вариант, но я бы не сказал, что это костыль. Сам инпут итак лежит в компоненте (лейбл, поле инпута с плейсхолдером, дескрипшн), у которого настроен Auto Layout. Просто инпут вы можете как отдельно использовать где-то, убрав тот же лейбл с дескрипшном, так и в рамках составной формы и тут этот отступ будет скорее мешать. Т.е. в рамках одного кейса, который был выше, это выглядит костыльно, но в рамках продукта в целом вполне норм.

Ответить
0

Клевая статья, очень хорошо все разложено!
У меня 2 вопроса:
1. Насколько рационально отрисовывать 7 макетов под разные разрешения и как к такому разнообразию относятся заказчики ?  На большинстве проектов 4 вполне хватает: один для мобильных, второй для планшетов, и 2 для десктопа.
2. Как я понимаю прототипы так же делаете в Figma. Насколько сложнее разрабатывать интерактивные прототипы по сравнению с Axure? В Axure же можно заказчику приближенно показать как будет работать готовый сайт (вкладки и табы, наведение на элементы, счетчики, а если добавлять функции, то и добавление в корзину с изменением количества и цены).

Ответить
4

Спасибо!

1. Это имеет смысл делать для первых страниц, которые вы готовите (главная, ключевые страницы, страницы с нестандартной версткой), так как часть вашей аудитории зайдет с HD, часть с какого-нибудь старого ноута с 1280-1300, кто-то с пятерки старой, а у кого-то планшет китайский,  непонятно какого разрешения вообще.  Кейсы могут быть любыми и вы должны заранее спрогнозировать поведение макета в максимально широком диапазоне состояний чтобы снизить процент отказов. При этом все страницы никто и не готовит в 7 разрешениях: обычно фронт с дизайнером проходят по списку и выделяют те разрешения, которые нужны фронту, чтобы понять поведение макета. Клиенты на это обычно довольно позитивно реагируют.

2. Большая часть (вкладки, табы, ховеры) работает в целом примерно так же. Более сложный функционал (добавление в корзину) описывается на уровне сценариев (но да, тут минус в том, что сложные интерактивные сценарии в фигме пока полноценно не получается отрабатывать). Однако, суммарные плюсы перехода перевешивают.

Ответить
0

Спасибо за развернутый ответ!
Если не секрет, сколько примерно часов затратили на разработку такой система? Т.к. проделана колоссальная работа, то видимо разработка велась несколькими дизайнерами и программистами.

Ответить
1

Спасибо!  Тестовый прогон 2 дизайнерами на двух новых проектах (по таймингу примерно так же, как на скетче вышло, дельта очень небольшая).  Плагин и обработчик писался одним разработчиком, суммарно примерно 2,5 недели времени (в свободное от коммерции время).  Гайдлайн я писал около месяца (не каждый день и по чуть-чуть), библиотека компонентов собрана за 1,5 недели одним дизайнером (ну и постоянно обновляется, конечно). 

Ответить
1

ANAL парсит список через API Figma

Вы так аналитиков называете?)

Ответить
0

Плагин же

Ответить
1

понравилась склейка в спеку – прям крутотень!

Ответить
1

Спасибо, отличная статья!

Ответить
1

Красавцы. Клевый подход. Мы примерно также фигачим.

Ответить
0

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

Ответить
0

В фигме есть интересные фишки, которые хотелось бы видеть в sketch без плагинов, но мы тоже полноценно не переходим, иногда можем там работать с проектом.

Ответить
0

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

Минусы фигмы, что она из облака иногда очень долго грузится.

Скажите, а как у вас реализуется версионность макета той или иной страницы? (Или я упустил в статье?)

Ответить
1

Спасибо! У Фигмы есть контроль версий из коробки. Не идеальный, но намного лучше всех аналогов, что мы успели попробовать за время пользования Скетча. Вообще, если макетов много, спасает общая библиотека компонентов под конкретный проект + контроль версий + регламент работы, который понятен всем участникам.

Ответить
0

У фигмы есть история изменения макета. А самим мне кажется не надо хранить старые версии. Они только путаницу создают. Да и зачем они?

Ответить
0

Путаницу создают, но были ситуации, когда приходилось использовать старый дизайн и вот тут файл отдельный спасал.

Ответить
0

Спасибо. Полезный материал. Пока еще использую Sketch, но попробую применить к себе ваш подход.

Ответить
0

В скетч все тоже самое, только без облачного бздения дизайнерами в проекте.., пока.

Ответить
0

Но есть же sketch cloud.

Ответить
1

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

Ответить
0

Я тоже так думал, пока не поработал какое-то время с группами в Фигме. Разница чувствуется (да, я понимаю, что Скетч пытается догнать и наращивает функционал)

Ответить
0

PornHub быстро заинтересуется 

Ответить
0

Классно! Но с неймингом у вас явно беда. Или это вы так менеджеров любите, что хотите чтобы они хоть что-то в анал вставляли? :) 

Ответить
0

Отличная статья! Нет проблем с тем, что в figma нет long tap или hold для мобильных устройств?

Ответить
0

У нас в основном веб, а в нем это не такой частый кейс у мобилок

Ответить
0

ясно, спасибо!

Ответить
0

Очень круто! Жду когда такое закатят и в геймдев) 

Ответить
0

Ода фигме... блдзбло

Ответить
0

Может материал и полезный, но ток для тех кто совсем не в теме..

Написать плагин для нейминга - гуд. Если б выложили в доступ - думаю кому-то бы очень помогло.. Хотя, есть функция cmd+r, которая работает и со множеством объектов сразу.

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "page_type": "default" }