От хаоса к структуре. Как организовать взаимодействие дизайнера и фронтов.

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

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

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

И вот почему:
◦ На проекте 1 дизайнер и 1 фронт, оба очень глубоко погружены в продукт, знают где какой экран лежит
◦ У них тесная коммуникация — микровзаимодействия и ux проговариваются словами
◦ Продукт не имеет развитую навигацию, ключевых сценариев не так много.

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

Легко представить результат — часть знаний о продукте может быть утрачена, могут уйти из виду корнер-кейсы. А при попытке что-либо улучшить в продукте, нужно будет прорисовывать отдельно Userflow, сравнивая макет и реализацию на фронте. А если вдруг понадобится внедрить какие-то сквозные правки по навигации, то тут 2 варианта: либо правки внедрятся сразу на фронте и при этом может быть что-то упущено, либо надо будет потратить много времени на актуализацию макетов и пересборку структуры.

Мы фокусируемся на потребностях пользователя, на том, как он будет решать свои задачи в нашем продукте. Поэтому в основе наших обсуждений с командой лежат джобы и User story.

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

Ситуация пользователя — это одна секция. Например, первый вход и повторный вход. Внутри ситуации прорисованы Userflow — сценарии решения пользовательских задач.

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

Представьте ситуацию — команде нужно начинать разработку фронта, и вдруг: «Галя! У нас отмена!» — табы не того размера.

Вы уже предчувствуете долгие правки и кучу нервов?

Так вот — все это можно избежать если использовать компонент-лейаут. Одна правка в таком компоненте — и она сразу прорастает во все экраны!

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

Следующее, что нам помогает синхронизироваться в моменте — это использование функции Ready for dev. Эта функция доступна и без лицензии на dev mode. Мы в команде договорились, что если секция отмечена зеленой иконкой ready for dev, значит она полностью готова к разработке. Если иконка стала желтой, значит произошли изменения, которые еще не утверждены. Если в этот промежуточный момент появились вопросы — они обсуждаются в чате телеграма.

Процесс ревью организован таким образом, чтобы и дизайнер и фронт понимали, что сейчас происходит, на каком мы этапе. А также позволяет получить на проде продукт максимально приближенный к первоначальному замыслу. Слева помещается макет, справа скрин в таком же масштабе и размере экрана. Круглый стикер с номером пункта к исправлению помещается на скрин, чтобы быстрее считывать, о чем идет речь. И этот же номер указывается в таблице. Таблица расположена рядом. В самой таблице мы видим описание что не так — это просто факт, который требуется исправить, следующая колонка — как надо. Здесь описываем буквально какой вид и поведение мы ожидаем. Затем указываем уровень критичности — низкий, средний, высокий. И отправляем фронту. Фронт ознакамливается с пунктами — в телеграме обсуждаются вопросы, если что-то исправить не удастся, например, для такой реализации не готов бэк, то в последней колонке «Исправление», ставится лейбл «не будет исправ��ено» и рядом помещается стикер с причиной. Далее фронт берет задачу в работу, выполняет изменения и дает знать, что дизайнер может финально смотреть реализацию. А в последней колонке таблицы проставляется статус «исправлено», «не исправлено». По тому, что не исправлено, общение происходит в тиките.

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

Делюсь с вами файликом, который поможет подобным образом организовать дизайн-ревью, здесь шаблон таблички, чтобы взять да и начать!

Подписывайтесь на мой телеграм-канал, где я пишу заметки из жизни продуктового дизайнера.