Лого vc.ru

Оптимизация работы портальной дизайн-команды с помощью Sketch и облака — опыт Mail.Ru Group

Оптимизация работы портальной дизайн-команды с помощью Sketch и облака — опыт Mail.Ru Group

Андрей Сундиев из отдела дизайна Mail.Ru Group поделился опытом того, как можно оптимизировать работу команды над постоянно обновляющимися файлами и проектами при помощи облачных систем хранения.

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

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

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

Хранение и именование файлов

Когда над продуктом работают несколько дизайнеров, то им просто необходимо выстроить общее пространство, чтобы ничто не препятствовало эффективной работе. Как часто вы слышите: «Эй, а где у нас лежит этот макет?», «Как мне найти макеты по такому-то проекту?», «А где лежат ассеты, использованные в макете?». Немножко занудства и педантичности позволили нам почти забыть про эти вопросы.

Все дизайнеры нашей портальной команды работают в общем облаке, разбитом на папки проектов:

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

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

Собрав всю команду, мы в течение нескольких необычайно шумных сессий договорились до следующего формата:

В корне папки продукта идёт разбивка на используемые в проекте платформы. Основные портальные проекты Mail.Ru пережили несколько заметных редизайнов, поэтому следующий уровень мы разбили на «поколения» продуктов. Этот базовый этап позволил нам разложить по полочкам основу и отделить актуальные материалы от заведомо устаревших.

Отмечу, что устаревшие макеты мы, не кривя душой, отправили в папку «Arсhive» (у каждого проекта своя), так как практика показывает, что обращаемся мы к ним крайне редко и не видим смысла инвестировать время в наведение там полного порядка.

На следующем уровне, как я уже упоминал, возможны вариации, но в общем виде это выглядит так:

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

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

Внутри папки с задачей есть несколько обязательных разделов:

  • _Export — для всех экспортируемых ассетов: иконки, скрины, фоновые изображения и так далее.
  • _Obsolete — для драфтовых и устаревших макетов.

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

Теперь, приступая к работе над проектом, дизайнеру не приходится с болью в сердце смотреть на папки «_final», «_final-ok», «_new» и так далее. Теперь мы всегда знаем, где брать материалы по проекту, а также какой макет наиболее актуален. В этом нам здорово помогает Sketch.

Организация макетов

Sketch кардинально изменил то, как мы можем структурировать свои макеты. В прошлом остались авгиевы конюшни из 50 PSD- «ver.1, ver.2,… ver.90» и заставлявшие дымиться мой Mak файлы со всеми состояниями в скрытых папках или layer comps. Всё стало гораздо проще.

Сочетание Artboards и Pages в Sketch позволяет без особых проблем и ущерба производительности хранить весь интерфейс в одном мастер-файле. Схема при этом довольно проста:

  • Pages служат для разбиения интерфейса на экраны.
  • Artboards — для отображения состояний одного экрана.

Возьмем, к примеру, интерфейс «Почты» Mail.Ru:

По страницам у нас разложены основные экраны «Почты»: список писем, письмо, написание письма, настройки. По артбордам состояния: поиск, нотификации, выпадающие меню и тому подобное.

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

Мастер-файлы и шаблоны

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

В каждом проекте существует «мастер» — весь актуальный набор файлов проекта, которые сейчас в разработке. Было бы слишком рискованно вносить изменения сразу в «мастер», так как это может непредсказуемо отразиться на проекте.

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

Чем это может помочь нам? Нет, мы не стали использовать Git (хотя могли бы, и некоторые идут именно этим путем), но немного пересмотрели уже имеющиеся инструменты. Если оперировать понятиями разработчиков, то и у нас есть свой «мастер» — основной Sketch-файл со всеми экранами и состояниями интерфейса.

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


Чтобы быстро создавать ветки, не трогая «мастер», мы используем шаблоны Sketch (идеей поделился с нами в своё время Олег Андрианов, применивший это в команде «Однокласников»).

Для этого необходимо создать ярлык (hard-link) на мастер-файл в папке шаблонов Sketch. Мастер-файл лежит на нашем общем облаке, а ярлык на него у каждого дизайнера на машине.

Для того чтобы создать связь, нужно прописать одну простую команду в терминале (terminal.app):

ln -s "/Users/username/Work folder/Master-file.sketch" "/Users/username/Library/Application Support/com.bohemiancoding.sketch3/Templates/Master-file.sketch"

  • Первый блок в кавычках — это путь до папки, где лежит мастер-файл.
  • Второй блок — это путь до папки Templates в Sketch.

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

Этот прием, разумеется, работает для любых Sketch-файлов, поэтому мы не остановились на UI Kit и добавили в шаблоны другие часто используемые файлы, например, пак с иконками и иллюстрациями. Теперь при необходимости добавить в макет интерфейсную иконку или небольшую иллюстрацию мы обращаемся к этому шаблону, где они лежат в svg, готовые к экспорту.

В таком большом (и постоянно расширяющемся) документе можно было бы запутаться, однако тут выручает поиск Sketch. Если слои логично проименованы, то найти нужный не составляет труда. А сочетание клавиш «cmd + 2» переносит тебя к выбранному элементу.

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

Присылайте свои колонки и интерфейсные кейсы на interface@vc.ru.

0

Давно уже многие работают в связке Sketch + Dropbox и описывали это.
Сотрудники отдела дизайна Mail.Ru Group, вы тоже Dropbox используете?)

Эта схема работает с любым облачным хранилищем. Про такую связку писали много раз, Олег Андрианов рассказывал на Dribbble Meetup в прошлом году — www.youtube.com/watch?v=_PKdqm-o16g. Но Андрей собрал более полный вариант, описывающий все этапы работы, не только отдельные куски.

А что с контролем версий, или я читал статью по диагонали?

0

Контроль версий осуществляется за счет функционала того облачного сервиса, который вы используете.

0

На всякий случай, уточню: речь идет о контроле версий какого-то компонента или о версионировании, т.е. возможности "откатиться" на более старую версию файла а-ля бэкап?

В тексте идет речь про hard link, а в консольной команде и на скриншоте — symlink

0

неделя технически безграмотных статей на VC ;)

0

Опечатка, виноват(
Конечно же, речь о symlink

Прямой эфир
Компания отказалась от email
в пользу общения при помощи мемов
Подписаться на push-уведомления