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