Принятие, торг, диалог. Опыт коммуникаций между командами от дизайнеров «СберЗдоровья»

Привет! Меня зовут Олеся Кириллова, я — продуктовый дизайнер и отвечаю за wellness-направление.

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

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

Миры разработчиков и дизайнеров очень разные.

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

Дизайнер больше живёт в «завтра» и даже в «послезавтра», и постоянно думает о пользователе и метриках.

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

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

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

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

Часто, когда дизайнер описывает свою проблему, в которой для него всё логично и понятно, а бизнес воспринимает эти слова как милое чириканье.

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

Бизнес, хочет получить результат «уже завтра». Деньги для этого заказчика — весомый аргумент.

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

Уверена, что каждый дизайнер хоть раз в своей жизни получал задачу с формулировкой: «А сделай кнопку побольше и покраснее?».

Мне, да и всем, кто сталкивался с этим, в таких случаях всегда хочется плакать, потому что чаще всего проблема далеко не в кнопке. Даже в самой маленькой задаче важно знать контекст, понимать, почему она вообще возникла, какие ожидания от выполнения и ещё много всего.

Поэтому мы используем стандартизированную схему постановки задач:

Задача не появляется из ниоткуда — у неё всегда есть причина. Например: «Пользователи не нажимают на нашу кнопку».

На этом этапе определяемся с тем, что хотим получить в итоге. Это поможет понять, как решать задачу — через стандартную механику или есть простор для полёта фантазии и можно принести много вариантов и провести исследования.

Как измерим, насколько хорошо выполнена задача?

Важен ли текст в этой задаче? Нужно ли экспериментировать и подключать команду контента? Или уже есть утверждённый текст, который нельзя менять?

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

Помогают дизайнеру расставить приоритеты.

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

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

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

Поэтому на этапе описания наши РО и РМ дают почитать ТЗ дизайнеру, который будет его делать. Скорее всего сразу же появятся вопросы и начнётся обсуждение.

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

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

Супер, идём дальше.

Предположим, что вы настроили процесс передачи тасок дизайнеру, а что дальше?

Минимум 50 первых презентаций дизайнера — абсолютная боль. Чем-то напоминает подростковый период, когда ранит любая критика (даже самая дружелюбная!).

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

• сложно
• непонятно
• дорого
• на каких данных основано?
• покрути еще
• ну сам реши
• а это тестили?
• мне не нравится дизайн
• так не будет работать
• это не по дизайн-системе
• кажется, здесь можно придумать что-нибудь покруче…

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

Делись с командой тем, как ты принимаешь то или иное решение. Начни презентацию с обозначения проблемы: «На нашу серую кнопку не нажимают».

Затем расскажи про кнопку поподробнее, а после — поделись своей идеей решения, например: «Мы хотим сделать её синей, потому что предполагаем, что серая кнопка выглядит неактивной. Синюю кнопку люди посчитают доступной и будут нажимать».

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

Старайся приносить несколько решений за раз.

Будет совсем хорошо, если рядом с каждым вариантом ты напишешь, что в нём смущает, а что, наоборот, очень нравится.

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

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

Поэтому один из моих любимых этапов, когда мы передаем гипотезы UX-исследователям. Ребята отлично помогают нам всем синхронизироваться. Они зададут всем множество важных вопросов, уточнят детали и, собрав всю информацию, расставят приоритеты и упростят рабочие процессы.

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

Бизнес хочет увидеть жизнеспособный продукт, чтобы скорее получить ресурс на этот квартал.

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

Вот он — момент столкновения интересов.

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

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

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

Эта ситуация ещё больнее. Гонки с дедлайнами презентаций — совсем не то, за чем продуктовый дизайнер устраивается на работу. Но иногда нужно быть готовым и к таким задачам.

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

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

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

При таком подходе все только выиграют.

Разумеется, если речь идёт о единичных случаях.

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

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

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

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

Как понять, что пришло время выстраивать процессы? Всё просто: если какое-то обсуждение возникает больше трёх раз, значит, пора.

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

Контроль и корректировка того, как ты получаешь и отдаёшь задачи — исключительно твоя война, и не стоит пытаться переложить её на РМ — лучше помоги.

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

Всем мира, любви и эффективной коммуникации!