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

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

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

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

Такие разные, и всё-таки вместе

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

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

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

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

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

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

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

Гораздо лучше друг друга понимают дизайнеры и менеджеры, но это скорее заслуга последних. Как говорит один из наших РО (product owner): «Менеджер — это любопытный сгусток энергии»

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

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

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

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

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

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

Получение задач на дизайн

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

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

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

1. Описание проблемы

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

2. Ожидания

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

3. Метрика успеха

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

4. Контент

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

5. Исследования

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

6. Сроки

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

7. Референсы и документация

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

8. Гипотезы

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

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

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

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

Мы сформировали ритуал — груминг дизайн бэклога раз в неделю

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

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

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

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

Презентация дизайн-решения

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

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

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

Помни, что не всегда реакция на презентацию будет дружелюбной, однако ни у кого нет цели тебя «завалить». Просто главная задача разработки и аналитиков — всё досконально изучить и понять, будет ли это работать или нет.

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

Первый подход

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

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

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

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

Подход второй

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

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

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

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

А после дизайна — исследования

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

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

Со слезами на глазах…

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

Кейс 1

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

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

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

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

Кейс 2

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

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

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

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

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

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

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

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

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

Кейс 3

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

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

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

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

Диалоги как процесс

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

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

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

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

Вместо выводов

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

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

77
1 комментарий

И ни слова о ЦА. Бросают мячик внутри команды и ничего не слышат от конечного пользователя.
Бизнес правильно хочет MVP и выйти сразу на прод с бетой - чтобы снять живую метрику и получить фитбек "таргет" достигнут или нет.

Хотелось бы узнать у Олеси - какой опыт работы в сфере (дней\годков\лет).
И какое профильное образование получено (не курсы).
И сдавала ли Олеся аттестацию по профилю в CUA хотя бы.