редакции
Никто не м*дак, или как дизайнерам взаимодействовать с разработчиками
Привет! Это студия Tetraform. Прошлым летом на «Дизайн-выходных» мы выступали с темой «Коммуникации как продукт». Наши ребята рассказали о том, как дизайнеру эффективно взаимодействовать с другими членами продуктовой команды. Запись оставим в конце статьи.
В этот раз хотим углубиться в тему взаимоотношений дизайнеров и разработчиков. Почему это важно? Задачи дизайнеров интерфейсов и разработчиков тесно связаны. Часто бывает так, что на проект приглашают две независимые аутсорс-команды. Добиться их слаженной работы — это уже половина успеха.
Погрузитесь в задачу вместе
В идеальном мире продакт или проджект-менеджер на старте проекта знакомит участников команды, погружает всех в единый контекст и рассказывает про цели и задачи продукта. А дальше проводятся сессии планирования, дейлики и совещания. При таком подходе все участники продуктовой команды всегда видят, что происходит с продуктом на каждом этапе и помогают друг-другу советом или делом.
Но это в идеальном мире...
Часто дизайнеру приходится самому проявлять инициативу в некоторых моментах и выстраивать коммуникации. Если, конечно, он хочет создать что-то действительно эффективное для бизнеса и удобное для пользователя.
И самое важное, что он должен сделать — организовать пару общих встреч с разработчиками на старте и в процессе. Больше всего ошибок и багов возникает из-за того, что люди просто не смогли на берегу договориться о важных вещах: как организовать Figma, как передавать макеты и проводить ревью, в каких единицах измерения будем работать (px или rem).
Больше всего ошибок и багов возникает из-за того, что люди просто не смогли на берегу договориться о важных вещах
Принимайте важные решения сообща
Перед тем, как взяться за создание макетов, дизайнер проводит исследовательскую работу: например, собирает гипотезы, проводит глубинные интервью с ЦА, собирает модель персон и анализирует конкурентов. На этом этапе подключение разработчиков не требуется.
Но дальше запускаются два процесса, которые могут идти параллельно: разработка стилистического и функционального решения для продукта (User Journey Map и User Flow).
Ко второму процессу есть смысл привлекать разработчиков, ведь они — ценный источник юзкейсов. А еще они мыслят не так, как дизайнеры, и могут предлагать классные решения, которые дизайнер часто не видит со своей стороны. На первых этапах от разработчиков нужны не столько их навыки, сколько их опыт и логика
Вообще устраивать генерационные штуки всей командой — это очень полезно.
Систематизируйте рабочее пространство
Чтобы не запутаться в макетах Figma, лучше разделить рабочие пространства. Мы обычно создаем отдельные страницы для:
— User Flow, User Journey Map и других схем
— Вайрфреймов
— Макетов с примененной стилистикой
— UI-кита
— Страниц, которые передаются в верстку
Так никто не запутается, а разработчики смогут оперативно забирать макеты.
Займите проактивную позицию
Плохо, когда все делают всё молча, а потом друг на друга злятся. Например, дизайнер молча нарисовал макеты, а потом скинул их разрабам. Верстальщик недопонял логику какого-то элемента, разозлился, но ничего не переспросил. Сделал так, как сам видит.
В итоге все сломалось или получилось не таким, как задумано. Дизайнер расстроен, заказчик недоволен. Нужно переделывать.
А вот если бы дизайнер пригласил команду разработчиков на созвон, рассказал о своих решениях, объяснил Flow и попросил задавать вопросы и подсвечивать непонятные моменты — все было бы по-другому. Как обещали в начале статьи — делимся выступлением. На видео много говорим о том, какие проблемы возникают в коммуникации продуктовых команд и как их решать. Будет полезно для дизайнеров, разработчиков, проджектов и всех, кто работает в продуктовых командах. А какие сложности при взаимодействии с разработчиками возникали у вас? 
Поделитесь в комментариях.
