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

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

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

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

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

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

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

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

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

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

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

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

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