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

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

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

Предыстория: Задача. Магия. Решение

У меня получилось именно так. Я пришла в команду, у которой уже был опыт работы с дизайнером, но отсутствовали культура исследований и прозрачный процесс. Дизайнер был вне спринта, не ходил на дейлики и другие командные встречи. Просто слушал то, что говорили стейкхолдеры, уходил на несколько месяцев проработки задачи и возвращался с непонятными команде решениями, которые потом бесконечно дополнял и переделывал.

Я же пришла со структурой и желанием насадить свое «правильное» восприятие процесса и дизайна без синхронизации с командой. К тому времени у меня уже был опыт и своё сложившееся понимание процессов. Я начинала в креативной студии, где макеты передавали в реализацию на аутсорс. Там была минимальная коммуникация с  разработчиками. Она ограничивалась описанием состояний элементов и анимации. Пришлось совершить немало ошибок и глубоко проработать вопрос, прежде чем у меня сформировалось объективное понимание дизайн-процесса и разработчиков. Уже в качестве продуктового дизайнера в финтех-компаниях я увидела, что у каждого члена команды своя специфика обратной связи. Что у разработчиков много знаний по дизайну и ещё больше по техническим ограничениям. В итоге у нас сложилось эффективное взаимодействие. Но на первых ПБР в новой команде (встреча по оценке задач в спринте) вся коммуникация была пропитана недопониманием друг к другу. Меня не слушали, но задавали огромное количество вопросов:

• «А почему так сделала?»;

• «А вот так попробовала?»;

• «А почему тут кастомный элемент, а не дизайн-система?»;

• «А у нас в другой части системы по-другому сделано, почему тут иначе?».

Я пыталась защищать свои решения, спорила и тратила много энергии. Считала, что мои решения обесцениваются. Некоторая критика сводилась к субъективной истории по типу: «Это выглядит странно, не красиво». И мне сразу же безапелляционно предлагали собственные визуальные решения: «Здесь будет лучше работать так». При этом мы совершенно не слышали друг друга, и ПБР затягивался на полтора часа по одной задаче. Это был стресс для всех участников.

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

Решения

1 причина. Нет понимания дизайн-процесса, и что дизайнер делает

Чаще всего разработчики не задумываются над тем, что такое дизайн-процесс, и плохо представляют то, чем занимается дизайнер. Дизайн-процесс может меняться от компании к компании, от задачи к задаче. Но есть устоявшаяся методология Double Diamond — это визуализация процесса дизайн-мышления, которая помогает командам организовать свои усилия. Она делится на два этапа: Discovery (исследование) и Delivery (реализация). Обычно про Delivery у команды есть представление, но часть дизайнерской работы на этапе Discovery покрыто мраком. Если коротко о шагах на этапе Discovery:

1. Понимание поставленной задачи: сбор информации, изучение конкурентов, поиск проблем и идей, формирование бизнес-гипотез.

2. Понимание ментальных моделей пользователей и требований к интерфейсу: интервью с пользователями.

3. Фиксация продуктовых артефактов: отчет по исследованию, Jobs to be done, пользовательские пути.

4. Несколько итераций концептов.

5. Ревью сообществом дизайнеров.

6. Проверка концептов на работоспособность: юзабилити-тестирование.

7. Презентация макетов и результатов исследований Delivery team и стейкхолдерам.

Поэтому моим первым решением было взять небольшую функциональность и сделать ее по дизайн-процессу, как надо с Discovery этапом. А далее презентовать перед командой со всеми схемами и выводами, чтобы они увидели как всё происходит: от понимания задачи до появления макетов и их изменения на основе обратной связи.

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

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

1. Паттерны

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

2. Коммуникация

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

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

• Чек-лист критериев приемки в задаче Jira.

• Комментарии Figma дублируют или расширяют понимание Jira, а не противоречат ей.

• «Обоснование изменений» для всех задач, кроме тех, что написаны в формате User Story.

• Поведение элементов.

• Корнер-кейсы.

• Ссылка на полный вариант компонента с описанием, если в задаче реализуется только часть функционала элемента.

• Без указания состояний, если это компонент дизайн-системы.

• Без указания отступов, цветов, это указано в макетах.

• Информация от аналитика в Jira «Техническая реализация».

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

2 причина. Нет доверия к новому человеку и его аргументации

Но, несмотря на убедительную аргументацию и осведомленность разработчиков о дизайн-процессе, в команде ещё могут оставаться сомнения. К новому человеку в устоявшейся команде всегда относятся с осторожностью. Поэтому продолжаем погружать разработчиков и формировать доверие.

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

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

Тем самым вы покажите, что решения обоснованы и проведена тщательная аналитическая работа, а интерфейсные и бизнесовые гипотезы подтверждены исследованиями.

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

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

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

3 причина. Команда неравнодушна к продукту и хочет влиять на него через дизайн

Правда, оказалось, что командные договоренности по дизайну не гарантируют того, что в вашу работу перестанут вмешиваться. И дело было не в том, что «у нас так принято» и мы не смогли договориться. Просто команда радела за свой проект и хотела участвовать во всех процессах. В том числе влиять на продукт через дизайн.

В таком случае я предлагаю следующее решение. Попробуйте привлекать команду на более ранние этапы до исследования макетов на пользователях. Так у разработчиков можно запрашивать обратную связь на неидеальные макеты. Например, спрашивать: «Будет ли здесь так работать по дизайну и технике?».

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

4 причина. У команды свое восприятие дизайна, продиктованное прошлым опытом, они не знают как иначе

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

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

В результате вы получите более обоснованную обратную связь. Но могут быть побочные эффекты в виде перенятия вашего лексикона. Например, фразы: «Это не соответствует ментальной модели пользователя» ;)

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

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

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

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

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

Обязательно укажите не только, какую обратную связь вы ожидаете от команды, но и покажите свою зону ответственности, как дизайнера:

Вот несколько статей, на основе которых сформировались рекомендации к обратной связи разработчиков:

Искусство обратной связи: как правильно критиковать и хвалить дизайн

Как получать обратную связь в команде дизайнеров (открывается с впн)

Do’s and dont’s when giving Design Feedback (открывается с впн)

Третье решение — не забывайте про личное отношение к своей работе и критике. Это может стать самым трудным моментом. Тут может помочь психолог: смена отношения к критике с защиты на открытость, разрешение себе ошибаться, отделение себя от своей работы, чтобы не так ревностно относиться к комментариям.

В начале я уже рассказывала, что душные споры на ПБР изнуряли меня и команду.  Они строились на аргументации, а затем уходили от темы, и встречи затягивались. Со своей стороны я защищала решения иногда излишне и не слышала аргументов, ведь уже было проделано много работы, решение прошло проверку пользователями. Какие могут быть тут вопросы?

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

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

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

Хотя надо не забывать, что даже с помощью психолога такая внутренняя работа не быстрая. Нельзя сказать «относись проще и все», но попытаться упростить себе жизнь точно стоит.

Как это повлияло на атмосферу и работу в команде?

В итоге я закрыла все четыре причины с помощью приведенных решений, а команда получила неплохой профит. Если по фактам, то польза такая:

• ПБР сократились по времени, так как большинство вопросов закрывалось на встречах до него, а команда уже была погружена в пользовательские пути.

• Оптимизирована скорость передачи в разработку, уменьшилось количество вопросов по задачам.

• Стало проще коммуницировать, просить что-то поправить в моменте или переделать — явно выросла позиция дизайнера в команде.

• Комментарии стали эмпатичнее, так как мы понимаем, кто и как реагирует и как нужно формулировать обратную связь.

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

Но главный результат: я стала легче воспринимать критику и прислушиваться к обратной связи разработчиков, учиться у них и расширять кругозор.

Да, они всё ещё могут сказать на дизайн-решение: «Нет, так не будет работать, это технически сложно или костыльно, и тогда, возможно, стоит пересмотреть весь или часть флоу, чтобы это было максимально эффективно для системы».

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

Все эти действия шаг за шагом привели к потеплению климата в команде.