Как мы построили все процессы разработки и внедрения дизайна вокруг одного инструмента.
Привет! Я — Ваня Соловьёв, дизайн-директор в DocDoc (входит в группу Сбербанк). Сегодня рубрика 🦸♂️ Тим-тим, в которой я расскажу, как мы уживаемся с другими командами.
В 2017 году наши интерфейсы создавались в Sketch, прототипы собирались в Marvel, а в разработку передавались через Zeplin. Всё было стандартно для того времени, пока не появилась Figma.
Эта статья не про сравнение инструментов, таких статей уже написано в избытке. Она про то, как в нашей компании Figma помогла:
- дизайну стать публичным, а не привилегией одного дизайнера;
- организовать весь процесс работы над дизайном без лишней документации;
- избавиться от ненужных инструментов и ресурсов на их поддержку.
Для дизайнера
Дизайнер больше не хранит макеты локально, в виде файлов. Не обменивается скриншотами интерфейсов с менеджером и не пересылает нужные макеты другим дизайнерам. У макета есть ссылка и она доступна всем участникам процесса.
Создал макет → собрал интерактивный прототип → передал в разработку — и всё это по одной ссылке.
Процесс создания дизайна перестал проходить «за семью печатями», он стал публичным. Обычный случай в нашей работе: дизайнер создаёт интерфейс, к нему в макет заходит другой участник задачи и оставляет свой совет в виде комментария.
В Figma удобно не только поддерживать свои макеты, пользоваться общей дизайн-системой, но и взаимодействовать с разработчиками, тестировщикам и менеджерами. Когда продуктовая команда пилит фичу, очень важно не плодить лишних версий и состояний макетов, чтобы не тормозить всю команду.
Для менеджера
У нас семь продуктовых менеджеров и каждый — лидер своего направления. Для их удобства, мы организовали файлы таким образом, что у каждого есть свой проект в Figma: запись к врачу, диагностика, телемедицина и т.д. Им достаточно одной ссылки для того, чтобы все наработки по их задачам были под рукой.
Пример проекта по Телемедицине
Доработки они заносят в виде комментариев к нужной части макета. Мы совместно решили, что большие нигде правки принимать не будем: ни в протоколах, ни в Jira, ни в мессенджерах. В комментарии упоминается нужный дизайнер и к нему на почту приходит уведомление.
Все хранится онлайн, не надо трястись, что не получишь доступ к макету, работая с другого компьютера. Я точно знаю, что доработки можно поставить только в виде комментария в макете и они будут сделаны. Это очень круто. Кроме того история комментариев позволяет восстановить события.
Для разработчика и тестировщика
Раньше, когда мы передавали макеты разработчикам через Zeplin у них с дизайнерами было разное представление о макетах. Дизайнеры видели полную картину переходов в Sketch, а разработчики только конкретный экран в Zeplin. Ребята не всегда понимали, какой экран за каким следует и тратили время на расспросы.
Разработчики видели только конкретный макет в Zeplin
В Figma разработчики видят туже самую картину, что и дизайнеры. Для единства мы придерживаемся такой организации макетов: по горизонтали переходы между экранами, по вертикали — внутри экранов. Это помогло ребятам чувствовать себя в макетах «как дома».
По горизонтали переходы между экранами, по вертикали — внутри экранов
Удобно, что все макеты в одном месте и доступ у всех, комфортно делать ревью — есть комментарии. Макеты всегда актуальны и в одном и том же виде для всех участников, удобно, что отдельно макеты для iOS и Android. Еще круто, что можно сделать ссылку на конкретный экрана, и вставить его в документацию.
Мы используем одинаковые названия переменных в цветах и стилях, это помогает не плодить лишние сущности при верстке интерфейса. Разработчики могут самостоятельно выгрузить себе любой элемент в макете, не тратя время на просьбу дизайнеру сделать это. Например, можно получить svg-код иконки или экспортировать её в нужном формате.
Когда привыкаешь к онлайн-сервисам, вроде Figma, предыдущие инструменты кажутся чем-то первобытным и очень далеким. Никаких файлообменников, проблем с лицензией, установкой ПО, вместо этого — просто ссылка в описании задачи в Jira. Чтобы получить CSS-стили элемента достаточно сделать два клика.
Для маркетолога
Задачи маркетинга, направленные на веб мы тоже делаем в Figma. У них есть свой проект, где хранятся все макеты. Так дизайнерам маркетинга проще придерживаться нашего фирменного стиля — все элементы есть в Figma.
Найти акцию, которую делали осенью 2018 года? Пф, легко!
Хорошо работает и наоборот: дизайнер маркетинга нарисовал иллюстрации, перенёс их в Figma. Продуктовый дизайнер забрал их к себе в интерфейс и при необходимости немного поправил форму и цвет — ведь всё векторное.
Сейчас мы работаем над конструктором иллюстраций в Figma
Легко объяснить дизайнеру, где и какие визуальные элементы необходимо поменять/убрать/добавить. Вместо тысячи слов можно один раз показать, где и что нужно сделать. К этим комментариям дизайнеры могут возвращаться в удобное для них время.
А когда задача маркетинговая, но касается напрямую продукта, то командная работа дизайнеров из двух отделов выходит на новый уровень. Один придумывает визуальную концепцию, другой примеряет ее на интерфейс — всё в одном макете и в одно время!
Главная мысль
Дизайн — итог работы команды, а не одного человека. Стремитесь к тому, чтобы каждый участник мог взаимодействовать с ним комфортно. Уходите от локальных инструментов и ищите те, которые объединяют вас и ваши процессы.
Фигма - это песня просто. Разделяю ваши восторги)
А как вы отслеживаете изменения? Ну вот пока релиз сделали и выкатили, вы сделали дизайн ревью, его надо тоже делать. Потом еще одно. И еще. И в итоге у вас куча изменений раскиданных по разным проектам? Тут экран еще старый смотри этот проект, этот уже 2 раза новый смотри сюда, а до этого он был таким как в проекте Релиз_4-2_final_2_правки.
Николай, спасибо за хороший вопрос. Постараюсь дать хороший ответ.
У нас есть мастер-файлы, помечаем их ⭐️, в которых дизайн = дизайну на бою. Все новые гипотезы мы делаем в файле «Тестирование», и там отображаем не весь путь, а только локальный кусок интерфейса, где показана новая гипотеза. Если по итогам А/Б-теста гипотеза побеждает, то после релиза на бой мы объединяем экраны этой гипотезы с мастер-файлом, которому она принадлежит.
Такой подход позволяет нам не дублировать экраны лишний раз и держать макеты в умеренной чистоте.
Спасибо!
Это реклама?
Ни разу. Вместо Фигмы может быть любой инструмент. Главное, чтобы он помогал вашей команде быть одним целым.
Фигма говно! Минусуйте, сучки!
Ну что вы. Это же не ветка адептов Фигмы. Ваше мнение, хоть и не обоснованное, тоже важно.
Хотелось бы услышать как вы делаете интерактивные прототипы?
В Figma весьма скудный набор для презентации прототипа (особенно, если речь идет не о приложении, а о десктоп версии). Пока вместо плясок с бубном остановился на старом добром Axure.
Михаил, привет.
Нужно понимать, что для вас значит «интерактивные прототипы». Для нас Figma полностью заменила Marvel и Invision.
Помимо стандартных переходов между экранами, в ней можно делать:
— всплывающие попапы и модальные окна;
— горизонтальный скролл элементов;
— залипание элемента при скролле;
— псевдо-анимацию, когда ты задаешь время смены кадров (гифка ниже)
Спасибо!
Под интерактивом я имел ввиду самое банальное понятие: раскрытие характера и степени взаимодействия между объектами.
Сложные взаимодействия по типу: раскрывающийся список, ховеры кнопок, буллиты, анимация слайдера и тд. сделать, конечно, можно, но приходилось плодить кучу бесполезных элементов, которые не нужны были при дальнейшей разработке и засоряли файлы проекта, да и трудозатратно.
Поэтому возник вопрос, возможно у вас использовались какие-то наработки.
Спасибо!
Как раз выше прокомментировал.
Так же очень удобно поддерживать актуальную версию прототипа на основе созданного макета.
Допустим вы отрисовали макет, собрали прототип в акшуре, но в итоге на очередном совещании решили, что ваш макет "ниочинь" и вы вынуждены выполнить двойную работу перерисовав макет и заново собрав прототип, в фигме такой проблемы нет, спешлфою Михаил, записал видео, как избежать взрыв пукана от очередных правок
Вячеслав, да, это понятно. Спасибо за видео.
Возможно нужно еще пару раз попробовать.
Если вы рисуете допустим кейс для мобильного приложения, то скорее всего в макете есть разделение на страницы ios/android, что мешает сделать 3 страницу с прототипом и собрать прототип в ней, при этом не засоряя макет для верстки ?
Мы также пользуемся Figma - самый оптимальный инструмент для разработки интерфейса, интерактив делаем в Principle. Общее представление в нем создаётся достаточно просто..
Я строил свои продукты на основе Sketch + Abstract. И вот сейчас пришел в новый продукт, на данный момент от меня требуется сформировать дизайн-систему. Продукт работает уже более двух лет, и все материалы в Sketch. Переход на Figma повлечет за собой падение продуктивности всех дизайнеров.
Тем не менее связка Sketch + Abstract не менее хороша, чем Figma. Тем более, смотря на скриншоты, реально напрягает версионирование в теле документа. Если команда крупная, а итерации мелкие, что тогда? В Abstract есть коммиты. И они реально спасают все. Больше никаких файлов "вариант 666", а самые актуальные версии видно как на ладони. В самых мелких итерациях.
Короче, что-то вы перегнули с заголовком.
Почитал про связку Sketch + Abstract ещё раз, но не нашел ответов на несколько вопросов. Роман — помогайте. Можете ответить, позволяет ли эта связка делать следующие вещи:
— совместная работа над макетом онлайн с другим дизайнером;
— менеджер находится в вашем макете и вы прямо при нём вносите правки, для ускорения процесса;
— для того, чтобы посмотреть макеты менеджерам, им нужно лишь войти в свой аккаунт в Фигме, ничего за них платить не нужно;
— собрать интерактивный прототип, потом изменить макет, но флоу прототипа останется и ничего настраивать заново не нужно;
— поработать с чужого компьютера, просто зайдя в браузер и войти под собой.
Роман, спасибо, что не безразличны к этому вопросу. Как я писал выше, цель этой статьи — не сравнение инструментов.
Я сам не использовал связку Sketch + Abstract, но читал статью о том, как Майкрософт сделал свою дизайн-систему именно на этой связке. На бумаге все выглядело хорошо и аккуратно.
Мы не задаемся вопросом, «а что было в 51 варианте? давайте поищем и посмотрим». Сделали гипотезу, протестировали. Не зашла — чуть подправили её в том же макете и проверяем снова. Если нам нужно вернуться к одной из прошлых версий — есть история изменений.
Если мы изменили макет, и надо донести правки до разработчика — есть комментарии в духе «тут новая иконка и отступ больше».
Еще такой вопрос: еще не пробовали по API Figma объединить дизайн и разработку?
Нет, еще не пробовали. Я читал истории успеха тех, кто это сделал — они довольны.
Комментарий недоступен