Как переехать со Sketch на Figma. Опыт Semrush
Как команда UI/UX-дизайнеров перешла на Figma, и почему нас не устраивали Zeplin, Sketch и Google Drive. Описываем плюсы и недостатки всех и делимся чек-листом для безболезненной смены инструментов.
Когда-то наша UI-команда была молодой и ветреной, то есть небольшой (пять человек), продуктов в Semrush — немного (11), а источником правды для стилей и отступов была библиотека с кнопками и некоторыми базовыми инпутами в смарт-объектах в фотошопе.
Тогда связка инструментов была такая: Photoshop → Zeplin. А все макеты хранились на Google Drive в тщательно или не очень сгруппированных папках.
Стало больно после всего этого? Если вы дизайнер в продуктовой команде, то сейчас у вас должно всплыть улыбающееся сквозь боль лицо старичка Гарольда.
В этом материале мы собрали боли нашей дизайн-команды в работе с инструментами до перехода на Figma. При этом, конечно же, мы очень благодарны Sketch — он научил нас работать с библиотеками и UI-компонентами и постоянно учиться новому. Надеемся, что наш опыт и вопросы, которые мы задавали себе при переносе большой дизайн-библиотеки между инструментами, помогут какой-нибудь команде сделать это так же безболезненно и быстро.
Как было до перехода на Figma
В какой-то момент для нас стало счастьем пересесть с иглы фотошопа на Sketch. Как раз в то время Bohemian Coding добавили функциональность для создания кросс-файловых символов.
Перспектива построить библиотеку с символами в Sketch, которые можно будет переиспользовать в разных макетах, была для нас волшебной. Особенно после передвигания пикселей в фотошопе и постоянных забегов по коллегам и гайдам в pdf и png, чтобы вспомнить, что там по отступам в кнопках.
В Figma функциональности с компонентами на тот момент ещё не было. Он тогда был инструментом сомнительным, но подающим надежды.
Один из дизайнеров начал собирать библиотеку символов в Sketch, набивая шишки и играясь с костылями. У некоторых наших компонентов было много вариаций, поэтому библиотека выходила очень объемная. А большой вложенности в символах было не избежать. В итоге с некоторыми из них выходило что-то такое:
Набор наших рабочих инструментов поменялся на: Sketch → Zeplin. А макеты мы продолжали хранить на Google Drive.
Понадобились месяц или два, чтобы команда привыкла работать в новом инструменте. Для этого мы проводили небольшие встречи, где рассказывали друг другу лайфхаки для работы со Sketch.
Параллельно мы завели отдельный канал в корпоративном Slаck для обмена плагинами, советами и проблемами. На этой ноте все должны были стать счастливы и веселы. Некоторое время так оно и было.
Почему решили поменять инструмент
В постоянно растущей команде время от времени задумываешься о том, как процессы сделать лучше: передача и поиск макетов, корректно работающие инструменты и хорошая понятная библиотека компонентов.
На одном из командных ретро (нас тогда стало уже 11, а количество продуктов Semrush увеличилось до 44) мы решили обсудить инструменты и работу с макетами, библиотекой и командами разработки.
На тот момент команда вот так шуточно определила для себя эмоции по отношению к инструментам, с которыми мы работали:
После этой разминки мы собрали уже несколько проблем, которые для нас стали определяющими в переходе на новый инструмент.
Минусы Sketch, Google Drive и Zeplin
Google Drive
- Синхронизация файлов плохо работала между разными машинами. Часто из-за неё появлялись дубли исходников, а открывать один файл и работать над ним одновременно с коллегой, конечно же, было невозможно — чьи-то изменения обязательно пропадали.
- Были жуткие случаи, когда библиотеки компонентов дублировались, у кого-то из ребят они пропадали, и слетали все связи компонентов макета с актуальной версией. Это была одна из главных болей работы с библиотекой. Sketch Cloud на момент, когда мы уже пользовались нашей библиотекой, ещё не было (эту возможность Bohemian Coding добавили 28 февраля 2018 года).
- Ну, и человеческий фактор, конечно же, из-за которого в той или иной папке могла происходить полная энтропия.
Sketch
Мы очень любили Sketch, но не могли смириться с некоторыми моментами, замедляющими работу.
- Breaking changes были почти в каждой новой версии инструмента. Например, изначально в Sketch нельзя было менять цвет шейпов через свойства слоя, только через вложенные символы и маски внутри. В 2019 году Bohemian Coding добавили возможность менять цвета стиля внутри символа. При этом просто убрать маски внутри уже работающей библиотеки было нельзя, так как у всех ребят в макетах выбранные цвета радостно или не очень вернулись бы к дефолтным. Больно.
- Личная большая боль дизайнера, который занимался библиотеками и поддерживал их актуальность, — баг с дублированием символов основной библиотеки в файл, который упоминался выше. В каждом макете создавалась страница Symbols, где дублировались компоненты из основной библиотеки. Часто приходилось вручную перелинковывать символы в файле на символы основной библиотеки (ар-р-р!).
- Библиотека была огромная, у компонентов — куча вариаций. Приходилось мириться с большой вложенностью символов. А на поддержку компонентов уходило много времени.
- Очень хотелось упростить библиотеку, работу с ней и её поддержку. Помните эту большую вложенность компонентов выше? Вот-вот.
- Использование символов с большой вложенностью для некоторых ребят было неудобно, так как меню с ними было очень маленьким, а миниатюры не особенно помогали. Представьте, что вы только пришли в команду, а там огромная библиотека компонентов, где всё нужно изучить и потыкать.
- Нельзя было просто дать ссылку на нужный артборд и показать разработчику что-то конкретное при обсуждении. Каждый раз приходилось экспортировать макет в Zeplin.
- Работа с вектором в Sketch была удобной, однако сильно уступала Adobe Illustrator в плане настройки и корректного экспорта svg-ассетов.
- Часто встречались необъяснимые баги и разное поведение символов в разных макетах на разных машинах.
- Некоторые полезные плагины со временем и новыми версиями Sketch переставали поддерживаться.
- В какой-то момент Sketch начал чаще «падать» и терять все изменения.
- Не было возможности работать с макетами на другой машине (в облаке).
- Свою роль играло и желание попробовать новый инструмент.
Zeplin
- Zeplin криво отображал некоторые символы и элементы. Это очень бесило, особенно когда вообще не были непонятны причины подобного поведения.
- Была долгая синхронизация между Sketch и Zeplin. Иногда, пока ты выгружал актуальные макеты для разработчиков, можно было выпить чаю, узнать, как дела у коллег. При многократном повторении это очень раздражало (не чай и коллеги, конечно же, а Zeplin). Особенно такая трата времени печалила при работе с продуктами, которые постоянно обновляются и изменяются.
- Внутри инструмента нельзя было открывать несколько вкладок с макетами.
- Помимо всего этого, Zeplin для нас была ещё одним (лишним) источником правды, в котором нужно было не забывать поддерживать актуальность гайдов и макетов.
- Не всегда удобно было показывать логику работы. А возможность связывать макеты в кликабельные прототипы появилась, когда мы уже переходили к другой связке инструментов.
Наша команда росла, продуктов становилось больше (можно посмотреть темпы роста количества на этой странице), количество макетов и папок на Google Drive увеличивалось. А значит, все описанные выше проблемы могли умножаться на количество новых людей. Этого очень не хотелось, поэтому мы собрали внутри команды рабочую группу и расписали план перехода на Figma.
Плюсы Sketch
Конечно же, у Sketch были и плюсы, от которых некоторые ребята в команде отказывались скрепя сердце.
- Было много полезных классных плагинов, которые помогали в работе. Какое-то время они появлялись чуть ли не каждую неделю.
- В Sketch простой и понятный интерфейс, который был отдушиной после привычных, но всё же перегруженных интерфейсов программ Adobe.
- В Sketch было удобно работать со слоями и масками.
Sketch в целом всех устраивал, но однозначно устаревал по ряду фичей.
Подготовка к переходу на Figma
Перенос нескольких библиотек с компонентами из Sketch в Figma был важным шагом для нашей дизайн-команды. Поэтому мы собрали рабочую группу из заинтересованных человек. Эти ребята помимо основных задач занимались проработкой плана перехода на новый инструмент (нас там было пять человек, трое из которых уже давно с горящими глазами рассказывали, что может Figma).
Сперва мы составили список вопросов, на которые нам нужно было ответить: возможности инструмента, плюсы и минусы Sketch, флоу работы над задачами и прочее. Кроме того, отдельным документом мы собрали список всего, что нужно будет перенести (все базовые компоненты, иконки, графики, паттерны и пр.) и кто за какую часть будет ответственным.
Наш UI-лид семь раз созванивался с sales-командой Figma, задавал вопросы, читал их FAQ и гайды. Сперва выходило, что при сравнении в лоб Figma для нашей компании (с учётом количества дизайнеров, не только UI, но и UX) был дороже Sketch. В итоге же вышло дешевле, чем связка Sketch + Zeplin.
Пара команд разработки уже использовали в своей работе Figma. Мы учли их опыт и начали разбираться, как всё это объединить для одной организации и ничего не сломать.
Вот список вопросов, на которые мы отвечали перед окончательным решением перейти всей командой на Figma. Надеемся, он вам пригодится.
Процесс перехода
В основной Sketch-библиотеке на момент перехода у нас было более сорока компонентов и их вариаций. Кроме нее у нас есть отдельные библиотеки с иконками, иллюстрациями и паттернами.
Один из дизайнеров рабочей группы примерно год назад для собственного удобства начал переносить некоторые компоненты из Sketch в Figma. Мы решили отталкиваться от его наработок. Разделили между группой в три человека существующие компоненты, посмотрели, какие из них нужно доработать в Figma, а какие — собирать с нуля. И постепенно начали.
За время переноса мы записали для себя общие принципы построения компонентов, договоренности по названиям слоев, групп и вообще. Возможно, это будет полезно и вашей команде, если вы вдруг переносите свои библиотеки из Sketch в Figma.
Что важно помнить при создании нового компонента в Figma
Общее
- В основной библиотеке должно быть только нужное в работе над макетами. Все вспомогательные вещи уносите на отдельную страницу (мы у себя назвали ее Atoms). К вспомогательным вещам относятся те элементы, которые не могут функционировать в интерфейсе сами.
- Вложенность компонентов мы старались делать не больше двух–трёх подгрупп. Три — это предельно много.
- Не усложнять компоненты. Всё, что можно объединить и унифицировать в один компонент, можно смело вносить в него. Потом будет гораздо удобнее править один компонент, чем искать похожие по всем страницам библиотеки.
- Делать состояния и вариации компонентов внутри него или отдельными мастерами? Зависит от его сложности. В небольших и базовых компонентах удобно вкладывать состояния и вариации внутрь и добавлять соответствующие свойства через панель Variants. В сложных и больших компонентах состояния лучше делать отдельными мастерами. Это сократит их вес и возможные лаги при работе с ними.
- Не усложнять группировку компонентов.
Названия слоёв
- Внутри компонента названия текстовых слоев делайте уникальными.
- Между компонентами названия взаимозаменяемых текстовых слоев должны быть одинаковыми. Это нужно для легкой замены компонентов между собой, без утраты уже введенного текста.
Названия компонентов
- В Figma вложенность компонентов на панели слева проще, чем в Sketch, поэтому можно использовать меньше вложенностей, которые создаются с помощью "/".
- Называйте компоненты так, чтобы в панели Assets они отображались в логичном порядке. Например, состояния дропдауна или модального окна могут иметь в начале названия порядковое число.
- Нижнее подчёркивание в начале названия "_" делает компонент приватным и видимым только редакторам библиотеки.
Важно помнить при изменении уже существующего компонента:
- Если вы добавляете в уже существующий компонент что-то новое, лучше это скрывать, иначе в экземплярах компонента свеже-добавленные элементы будут включены. И вы можете случайно что-то сломать в чужих макетах.
- Если хочется кардинально изменить уже существующий компонент, удалите мастер, который вы хотите править. Старый мастер можно будет восстановить из его компонентов при необходимости. Создайте новый мастер компонента, – и вы ничего не сломаете в макетах у коллег.
Итоги
Переезд библиотек из Sketch в Figma в нашей команде занял чуть больше месяца силами пяти человек. Начали мы 19 марта 2020, а 24 апреля все основные компоненты и стили уже были готовы к работе библиотеками. При этом мы ещё занимались основными задачами, а переездом — в оставшееся от них время.
После переноса компонентов в Figma рабочая группа провела небольшие мастер-классы ребятам из UX/UI команды. Рассказывали и показывали, как всё работает и строится в библиотеке. Наш UI-лид провел демо по организации в Figma для всей продуктовой команды и маркетинговых дизайнеров.
Уже через месяц после переезда со Sketch на Figma можно было выделить такие результаты:
- Сократилось количество «источников правды» для дизайнеров и разработчиков. Теперь и те, и другие смотрят в один файл и могут работать над ним одновременно.
- Стало очень просто делиться макетами в команде и между командами.
- Исчезла большая для нас проблема с дубликатами файлов и библиотек на Google Drive, восстановлением старых версий макетов.
- Примерно в полтора-два раза сократилась вложенность и количество слоев внутри компонентов. Библиотеки стали значительно проще и удобнее в использовании, развитии и поддержке.
- На страницах компонентов появились ссылки на актуальную документацию.
- Сообщения про баги в компонентах теперь большинство ребят оставляют прямо в библиотеках, что не отвлекает дизайнеров, которые занимаются их поддержкой.
- Появление функциональности Variants в Figma дало крутую возможность настроить свойства в дизайн-компонентах. Наподобие того, как это сделано в коде.
- В Figma Community огромное количество полезных плагинов и ресурсов, которые помогают в решении разных рутинных задач.
- Наши основные библиотеки теперь доступны для сторонних разработчиков.
Что дальше
Переезд на Figma оправдал ожидания нашей команды. Стало проще работать с макетами и библиотеками дизайн-системы и обсуждать решения прямо в файлах. Даже просто хулиганить при совместной работе в Figma очень классно. Между прочим, это иногда очень полезно!
Дальше мы планируем недеструктивно связать наши дизайн-компоненты с react-компонентами, развивать библиотеки и делиться наработками в Figma Community.