Творчество без рутины: как мы автоматизировали процессы с 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 позволила нам совершенствовать свои процессы непрерывно.

0
146 комментариев
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Vyacheslav Rubanyuk

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

Ответить
Развернуть ветку
9 комментариев
Doco4ka

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

Ответить
Развернуть ветку
Bender Rodriguez

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

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

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

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

Ответить
Развернуть ветку
18 комментариев
LabO

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

Ответить
Развернуть ветку
6 комментариев
Roman Kamushken

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

Ответить
Развернуть ветку
1 комментарий
Анна Гласс

+++

Ответить
Развернуть ветку
Iorek Bearnisson

Ну да ладно, это начинающие дизайнеры обычно — их научат на бесплатных вебинарах лендосы клепать, в фш это можно делать еще (хотя я считаю даже это извращением). С опытом обычно проходит. Пусть попробуют в фш поработать над проектом, в команде которого 30–40 человек участвует из разных стран и городов, несколько тысяч экранов и огромная дизайн-система на несколько файлов. Будет ли заказчик готов терпеть потери времени из-за софта? На крупных проектах один день разработки стоит для заказчика больше, чем этот горе-дизайнер за следующие несколько лет не получит.

А вообще в живую не встречал дизайнеров интерфейсов, которые работают в фш, только тут в комментах, может тролли? Это как мыться в тазу на улице, когда дома есть душ с горячей водой. 

Ответить
Развернуть ветку
Гриша Булыжников

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

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

Ответить
Развернуть ветку
LabO

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

Ответить
Развернуть ветку
Karzec

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

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

Ответить
Развернуть ветку
Pillacchera Indelebile

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

Ответить
Развернуть ветку
Ilya Lesov

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

Ответить
Развернуть ветку
6 комментариев
Pavel Petyanov

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

Ответить
Развернуть ветку
Kiryl Shurynau

Что? Давно https://www.figma.com/downloads/ 

Ответить
Развернуть ветку
6 комментариев
Doco4ka

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

Ответить
Развернуть ветку
12 комментариев
Iorek Bearnisson

Тут от железа и рук дизайнера зависит. У меня на бюджетной модели MacBook Pro 2017 действительно немного тормозил макет с 1 млн слоев, в то время как люди, заходившие с обычных офисных ПК, страдали в разы сильнее. А про «руки дизайнера» — не стоит разводить 1 млн слоев в одном файле и нужно вовремя проводить рефакторинг. 

Ответить
Развернуть ветку
Юрий Владимирович

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

Ответить
Развернуть ветку
ADN Agency
Автор

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

Ответить
Развернуть ветку
9 комментариев
Lirnik

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

Ответить
Развернуть ветку
Алексей Шепелин

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

Ответить
Развернуть ветку
3 комментария
Alexandr Demidov

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

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

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

Ответить
Развернуть ветку
Александр К

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

Ответить
Развернуть ветку
Алексей Шепелин

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

Ответить
Развернуть ветку
6 комментариев
Анна Гласс

Спасибо огромное за стататью) Реально вкусненько)) Те редкие моменты, когда действительно круто почитать и это полезно. Скажите, где еще можно чекнуть ваши материалы? Очхочется учится - пожырней и побольше, пожалуйста)

Ответить
Развернуть ветку
Алексей Шепелин

Спасибо! У нас есть блог https://blog.adn.agency/ и периодически там бывают довольно вкусные вещи)

Ответить
Развернуть ветку
Анна Гласс

Возник такой вопрос, у вас рефакторингом занимаются не дизы, это повсеместная практика или только ваша? Или я неправильно поняла?

Ответить
Развернуть ветку
2 комментария
Mikhail Dubovoi

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

Ответить
Развернуть ветку
Алексей Шепелин

Спасибо!

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

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

Ответить
Развернуть ветку
2 комментария
Nikolay Lebedev

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

Ответить
Развернуть ветку
Шамбалийский Версталлах

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

Ответить
Развернуть ветку
Дима Брейвен

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

Ответить
Развернуть ветку
Roman Solonovich

Очень интересно! Спасибо за огромный практический материал!

Ответить
Развернуть ветку
Ольга Стогова

Ребята, какие же вы классные! 

Ответить
Развернуть ветку
Александр Богацький

Поделитесь плагином по структуризации фреймов, пожалуйста :)

Ответить
Развернуть ветку
Виталий Воробьев
ANAL парсит список через API Figma

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
1 комментарий
Алексей Курлаев

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

Ответить
Развернуть ветку
Игорь Маркелов

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

Ответить
Развернуть ветку
Iorek Bearnisson

В чем именно проявляется убогость? 

Ответить
Развернуть ветку
Женя Рыкеева

figma - офигенная штука! начала изучать web-дизайн, сначала в adobe пыталась по урокам работать, потом про неё узнала. поняла, что те, кто использует adobe и указывает его знания в вакансии (хотя они лишними не будут), сильно отстали от жизни и много теряют. очень много. 

Ответить
Развернуть ветку
Евгений Попов

Круто! Спасибо за статью!

Ответить
Развернуть ветку
Aloha Nik

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

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

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

Ответить
Развернуть ветку
Алексей Шепелин

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

Ответить
Развернуть ветку
Александр К

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

Ответить
Развернуть ветку
1 комментарий
Виталий Подольский

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

Ответить
Развернуть ветку
Дмитрий Ольшевский

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

Ответить
Развернуть ветку
3 комментария
Игнат Смирнов

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

Ответить
Развернуть ветку
Sakari Sauso

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

Ответить
Развернуть ветку
Алексей Шепелин

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

Ответить
Развернуть ветку
1 комментарий
Cергей С

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

Ответить
Развернуть ветку
Дмитрий Ольшевский

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

Ответить
Развернуть ветку
Artem Latynof

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

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

Ответить
Развернуть ветку
Maria Vereschak

Auto complete моя любовь. Все, что возможно автоматизировать с помощью него, автоматизирую. А, если эти элементы, основанные на аутокомплите переводить в компоненты, то просто сказка))

Ответить
Развернуть ветку
Влад Микулов

Спасибо за представленный опыт, очень полезно, сохранил

Ответить
Развернуть ветку
Генри Эмиксезян

Скажите. а как вы решаете задачу подсказки разработчику в какой компонент какое поле с бэка приходит? Было бы удобно сразу в фигме видеть не только текст-плейсхолдер, но и название атрибута, которое в него вставляется. Комментарии в этом смысле не очень удобны, т.к. можно запутаться в каком чего смотреть

Ответить
Развернуть ветку
Motion VFX

Что вы будете делать, когда сеть отрубят? А если облако накроется?

Ответить
Развернуть ветку
Iryna Kyzichkina

Спасибо за ANAL!!!))

Ответить
Развернуть ветку
Сергей Гольцов

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

Ответить
Развернуть ветку
143 комментария
Раскрывать всегда