Привет, Хабровчане! Я Рома — продуктовый дизайнер Tomoru.Team. Мы разрабатываем новый сервис в рекрутинге и HR
Дизайнеры и разработчики работаю вместе (и не всегда это только фронтендеры) над перекладываем макетов из Фигмы в прод. И часто с этим этапом бывают проблемы — нет единого принципа работы в передаче макетов, у всех свои фреймворки и методы работы. А также терминология — часто у дизайнеров и разработчков одно и то же слово значит разные вещи (что усложняет коммуникацию)
В этой статье хочу рассказать как за полгода мы с командой смогли выстроить достаточно рабочую схему по передаче макетов без болей и горения пятой точки:
#0 Контекст
Расскажу кратко про наше приложение, чтобы понимать почему именно такой фреймворк у нас получился.
Мы делаем сервис на платформе Telegram’a — Mini App (да да, те самые хомяки сделаны также). Mini App — по сути является веб-приложением, что упрощает разработку, ведь изначально мы планировали делать отдельные 3 приложения под iOS, Android и Веб. А теперь все упростилось до одного, что удобно. Важно — работаем мы в одном файле Фигмы, с оплаченной командой и доступом к Dev mode.
#1 Структура Фигмы
Начинаем с описание структуры внутри файла — у нас есть 10 страниц:
Типографика и цвета
Иконки
UI-kit
UX-kit
Готовые макеты
Передано в разработку
Апрув
Ревью
Придумываем
Архив
Давайте коротко про каждую страницу:
Типографика и цвет — тут отражаем какие шрифты со стилями мы используем, а также палитра цветов в 2-ух темах — светлая и тёмная. Также важно сказать, что в Телеграме у нас цвет разделены на 2 типа – Native и Custom. Native — цвета Телеги, которые не подлежат изменениям. Custom — любые цвета, которые дизайнер может придумать : )
Иконки — тут отображаем иконки, которые используем. Делим их по размерам в пикселях — 12, 16, 20, 24, 38, 32, 36, 40 + отдельно флаги стран.
UI-kit — стандартная история, про него можете почитать отдельные статьи.
UX-kit — а вот эту штука не очевидна, поэтому немного подробнее что это. В UX-kit’е мы описываем различные паттерны поведения, которые повторяются в интерфейсе: Загрузка в кнопках, когда показываем различные алерты (системные оповещения), как работают кнопки «Удалить» и т.д. Идея в том, чтобы не плодить лишние сущности в макетах, а также чтобы иметь систематизацию не только в плане UI, но и в UX.
Готовые макеты — тут лежат макеты, которые прошли этап дизайн ревью и выложены на прод. Информация на этой странице по макетам является идентичной той, что и в проде.
Передано в разработку — тут находятся макеты, которые разработка взяла в работу после этапа оценки и без претензий к дизайну. Изменения в макеты на этом этапе уже не вносятся, кроме косметических (опечатки, ошибки в тексте, возможно где-то стоит не тот цвет) при это уведомлять об этом изменении отдельно через проджект менеджера или фронта, который делает задачу.
Апрув — на этой странице представлены макеты, которые максимально готовы к передаче. На эти макеты уже посмотрел проджект и задал базовые вопросы, которые отработал дизайнер. Данные макеты нужны для знакомства с разработчиков с макетами.
Ревью — сюда попадают макеты, которые разработка реализовала и на этапе дизайн-ревью дизайнер обнаружил ошибки. В макетах подсвечиваются эти недочёты и передаютя в фомарте ревью.
Придумываем — это свободная зона для творчества дизайнера. Разработка вообще не смотрит на то, что происходит на этой странице, так как может случайно утонуть в несистемности. Здесь обитает дизайнер, придумывая различные сценарии и упаковывая их в отдельные «Слайды». Также на этой странице Проджект может ознакомится с некоторыми макетами, которые в дальнейшем попадут в «Апрув»
Архив — сюда попадают макет, которые вышли из актуальности (чаще всего это «Готовые макеты», которые изменились). Но также там могут оказать какие-то отдельные сценарии, которые потеряли актуальность.
По структуре базово это все. Можно добавлять опционально другие этапы, которые вы посчитаете важными, но все вышеперечисленные я бы всегда держал при себе, так как коммуникация и понимания что происходит в макетах становится намного яснее.
#2 Подготовка макетов
Что же по итогу делать с самими макетами, давайте проведем небольшой чек-лист:
1. Цвет — использовать только те, что вы занесли в «Variables», чтобы можно было быстро переключаться между темами (мы же подбирали под каждый цвет минимум 2 состояния)
2. Типографика — используем только те стили, которые уже занесены. Используем шрифты, на которые у нас есть лицензия, либо с бесплатной лицензией (ну или системные)
3. Компоненты — стараемся все элементы в работе делать компонентами. Прям по максимуму. Также каждый компонент разделяем на «состояния». Например у нашего компонента «Input_text» состояния: Default, Active, Completed, Error, Disabled. Также сам этот компонент состоит из других компонентов, но это другая история… По возможности описывайте каждый компонент в UI-kit’e — для чего используется, какие есть особенности, какое поведение имеет. Эта работа в первые разы может пугать из-за непонимания как начать. Рекомендую перед тем, как взяться за работу, ознакомиться с живыми референсами — посмотрите дизайн-систему «Контура» или «Ростелекома». Они простые в изучении и понимании как повторить такой результат. Если хочется взять именно «потыкать живое» — зайдите в Figma Community и откройте документы, которые теперь идут изначально для всех: iOS kit, Material 3 Design kit и Simple Design kit от Фигмы (этого будет достаточно). Если хочется упороться — откройте аккаунт VK (можно закопаться в изучение на несколько недель)
4. Фреймы и секции — Фигма позаботилась о нас уже давно, но все равно не многие используют новые возможности с секциями. Но по порядку. Фреймы используем для самих макетов (приложение, модальные окна, страницы сайта и прочее). Секции — место складирования фреймов по заданной логике. Мы разделяем все по сценариям. Это удобно и для понимания общего макета, и для проектирования отдельных сценариев.
5. Переходы — каждый раз, когда делаете какой-то активный компонент, сразу нарисуйте от него «стрелку», чтобы понимать, что эта «кнопка» куда-то должна будет вести. Так вы не потеряете всевозможные экраны и переходы на другие страницы + менеджеру и разработчику так будет куда проще ориентироваться в макете, во время изучения.
6. Mark as ready to dev — вместе с командой определитесь что значит этот значок для экранов :) Будете вы его использовать или нет, что он будет означать, может быть на разных страницах он будет иметь разный смысл.
Пример: у нас на странице «Апрув» значок «martd» обозначает, что макет согласован на приёмке с разработкой и не требует никаких уточнений, и его можно оценить (потому что если встреча с приёмкой макетов идет уже больше часа, что-то может быть упущено)
7. Названия — давайте адекватные названия всех элементов на макете. Сейчас для этого достаточно воспользоваться ИИ внутри Фигмы с переименованием слоёв (ну или делайте все по старинки — своими ручками)
8. Анимации — если у вас есть анимация для каких-либо элементов, её надо отразить на макете. Мы кладём рядом с основной секцией отдельную секцию с анимацией, либо ссылкой на анимацию, которую вы нашли в готовом виде (но стоит уточнить у разработки можно ли такое решение повторить для вашего проекта)
9. Состояния макета – больше часть работы, продумать все сценарии, и их надо все отразить на макете. А как выглядит страница, если медленный интернет? А что если картинка не прогрузилась(привет UX-kit)? А какой тут скелетон? А что показываем при ошибке? А при этой? Кароче в начале будет много уточнений со стороны разработке, но со временем вы сами поймёте что является обязательным для отображением.
10. Графика — часто в макетах встречается графика: растровая или векторная. Обозначьте как разработке будет удобно брать её. Кто-то требует выгружать все в отдельно. Что-то можно складывать рядом с фреймами макетов и выгружать прямо из Фигмы. Решите этот вопрос на берегу, чтобы не было вопросов после.
11. Новые вводные — каждый раз, когда для новых макетов вы разработали новый компонент, или новое состояние для старого компонента, добавили новый стиль цвета или текста, указывайте это в той же секции для сценария. Это важная часть, которая впоследствии поможет разработке дать более точную оценку в storypoint’ах
#3 Согласование
Тоже большая часть работы дизайнера, которая имеется в компании.
Согласование обычно 4-уровневое:
1. Самопроверка
2. Бизнес-апрув
3. Проджект менеджер
4. Приёмка разработки
Самопроверка — тут думаю все понятно, Перед тем как идти показывать что сделал, посмотри на своё детище сам. Возможно уже в первой строчке макете допущена очепятка.
Бизнес-апрув — раскрывать этот этап не будет, так как это не тема статьи, но упомянуть надо. Без этого этапа остальные не имеют особого значения. Чаще всего кто-то пришёл к вам с запросом сделать макеты, и скорее всего это тот самый бизнес-заказчик. Если все норм — можно идти к следующему этапу
Проджект менеджер — на этом этапе вам подсветят все недочёты с точки зрения логики, частично затрагивая вопросы от разработки, так как по этим макетам проджект будет писать ТЗ для разработки. Наверно на этом этапе уже уточнить все возможные нюансы, и когда все окей и ТЗ уже написано — переносим наши макеты на страницу «Апрув» и идем на встречу с разработкой. Также стоит заметить, что ваши макеты могут быть немного структурно видоизменены, так как разработка старается часто декомпозировать большие задачи на более малые и понятны. Поэтому ваш большой макет как единый сцерианий проджект может попросить разделить на 4 отдельные секции-задачи, которые пойдут как разные ТЗшки.
Приёмка разработки — тут мы приходим на общую встречу с разработчиками и проджектом. Идём по каждой секции макетов по отдельности, параллельно объясняя смысл увиденного и что предстоит сделать (объяснять может как дизайнер, так и проджект). Если у разработки появляются какие-то вопросы, на которых в макете нет ответов — идем доделывать этот макет. Если все окей — то считается что приёмка успешна и после будет оценка задач. Дизайнер может присутствовать на оценки и принимать участие — профит для диза в том, что он начинает понимать сложность реализации каждого отдельного макета или решения, что впоследствии может позитивно повлиять на проектирование.
#4 Ревью
После того как макеты отдали разработке, стоит проверить, точно ли все правильно они сделали. Проверять стоит все что вы сделали, и при понимании насколько это отходит от макетной версии. В идеале — получить полную копию макета.
В каком формате делать ревью — если есть какое-то несоответствие сделайте так:
1. Создайте секцию
2. Положите свой макет
3. Положите скриншот с прода
4. Текстовыми баблами опишите, что именно не так, и как надо сделать
5. Проведите от баблов стрелки к конкретному месту ошибки
6. Опционально, проведите стрелку до верного решения на макете
После того как выписали все правки в макете, подпишите секцию название «Ревью номер_задачи дата» и отправьте проджекту, либо приложите в таск-трекере вашей команды и тегнете разработчика. Ну и далее проводите ревью, пока не добьемся желаемого результата. Иногда сделать один в один как на макете оказывается проблематично, так как могда быть первичная недооценка какого-то решения. И легче «Готовые макеты» подогнать про реалии прода, так как время дизайнера и разработчика стоят по-разному и затраченное время тоже разное. Но тут стоит рассматривать каждый случай в отдельности.
#5 Итог
Такие статьи помогаю на базовом уровне. Мы поделились тем, как это работает сейчас у нас, на нашем уровне развития. Сейчас в этой схеме нет бизнес-аналитика, отдельного продакт-менеджера и различных других ролей, которые могут повлиять на процесс. Но сейчас наша структура работы достаточно устойчива и практически не даёт перебоев (критических так вообще нет).
Но помните — в каждой команде свой пайплайн работы, методы и фреймворки. Все стоит обсуждать и внедрять на уровне команды, перед этим обсудить все моменты
Если нашли для себя что-то новое в работе — пишите в комментарии «Спасибо Рома»
Также заходите ко мне в телеграм канал где я рассказываю про дизайн и себя — https://t.me/skvortcov_design
