Никто не м*дак, или как дизайнерам взаимодействовать с разработчиками

Привет! Это студия Tetraform. Прошлым летом на «Дизайн-выходных» мы выступали с темой «Коммуникации как продукт». Наши ребята рассказали о том, как дизайнеру эффективно взаимодействовать с другими членами продуктовой команды. Запись оставим в конце статьи.

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

Здесь не будет психологических советов. Только реальный опыт и прикладные лайфхаки от нашего продакт-дизайнера Кости Маслянникова.

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

Но это в идеальном мире...

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

И самое важное, что он должен сделать — организовать пару общих встреч с разработчиками на старте и в процессе. Больше всего ошибок и багов возникает из-за того, что люди просто не смогли на берегу договориться о важных вещах: как организовать Figma, как передавать макеты и проводить ревью, в каких единицах измерения будем работать (px или rem).

Перед тем, как взяться за создание макетов, дизайнер проводит исследовательскую работу: например, собирает гипотезы, проводит глубинные интервью с ЦА, собирает модель персон и анализирует конкурентов. На этом этапе подключение разработчиков не требуется.

Но дальше запускаются два процесса, которые могут идти параллельно: разработка стилистического и функционального решения для продукта (User Journey Map и User Flow).

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

Вообще устраивать генерационные штуки всей командой — это очень полезно.

Чтобы не запутаться в макетах Figma, лучше разделить рабочие пространства. Мы обычно создаем отдельные страницы для:

— User Flow, User Journey Map и других схем

— Вайрфреймов

— Макетов с примененной стилистикой

— UI-кита

— Страниц, которые передаются в верстку

Так никто не запутается, а разработчики смогут оперативно забирать макеты.

Плохо, когда все делают всё молча, а потом друг на друга злятся. Например, дизайнер молча нарисовал макеты, а потом скинул их разрабам. Верстальщик недопонял логику какого-то элемента, разозлился, но ничего не переспросил. Сделал так, как сам видит.

В итоге все сломалось или получилось не таким, как задумано. Дизайнер расстроен, заказчик недоволен. Нужно переделывать.

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

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