Прежде, чем простраивать коммуникацию с РО, важно понять в каком ландшафте разворачивается действие. Есть несколько базовых искажений в восприятии UX экспертизы, с которыми вы можете сталкнутся в компании и их важно знать в лицо. Будьте осторожны, ведь вероятно вы имеете дело с командой, в которой цветет буйным цветом Токсичный UX. Посмотрим на эти кейсы. Не важно один вы диссантировались в кросс-функциональную команду, или же в компании есть отдельная исследовательская лаборатория. Если ответственной за UX в компании является только UX эксперт, то весьма вероятно, что в представлении всех остальных вы просто:  Мешаете нормальным ребятам делать “настоящую” работу; Замедляете процесс ИТ-производства; Мешаете бизнесу зарабатывать деньги; Только и делаете, что клеете новые стикеры на макбук и пьете смузи. Когда вы принимаете решение о выборе работодателя, если речь идет не о самостоятельной дизайн-студии, конечно, не лишним будет узнать:  Какое место в продуктовом ИТ-производстве занимает UX?  Является ли бизнес компании на всех уровнях заинтересованным в развитии UX практик и как конкретно этот интерес каскадируется до линейного менеджмента? Запросите контакты уже работающих в компании UX исследователей, узнайте о том не придется ли вам бороться с ветряными мельницами? Итеративный процесс UX дизайна закладывается в дорожную карту продукта с большим скрипом. Но хуже всего его цели порой совсем далеки от нужд клиента. Вариантов несколько, а иногда они пересекаются: Формальный UX. Когда надо как-то пройти дизайн ревью и UX нужен исключительно чтобы в пром выпустили. Он уже ни на что не влияет, его делают не по любви, а просто чтобы был. Так точно UX. Когда идея уже цветет бурным цветом в головах руководства и надо подтвердить ее, во что бы то ни стало. Такой UX тоже ни на что не влияет, его единственная задача - подстроить показания под уже готовое решение и не дай Бог гонцу принести плохую весть. Запоздалый UX. Когда продукт уже на ПСИ, но UX вдруг потребовался. Причины могут быть совершенно разные от внезапного просветления сверху, до того, что все слишком сфокусировались на вопросе “как?”, вместо вопроса “зачем?” Оборонительный UX. Сделаем на всякий случай, чтобы можно было защитить свою точку зрения дополнительным аргументом. Когда бизнес знает, что у него есть оппоненты. Модный UX. Мы вообще не понимаем зачем это нужно, но наняли полк UX дизайнеров и пехотный взвод CJE Бежать. Или проявить чудеса коммуникации во взаимодействии с бизнесом и доказать преимущества качественной UX практики для продукта. Дальше поговорим об этом подробнее. Оборотная сторона медали - это когда прям вот всем-при-всем остервенело нравится UX. В этом случае невольно мы сталкиваемся с дублированием ролей, задач и становится решительно не понятно кта и шта тут делает. Действительно, кто отвечает за UX в команде? Разработчик, дизайнер интерфейсов, продакт, маркетинг, или только человек в названии должности которого содержится аббревиатура UX или что-то про пользователей? Когда функции дублируются, когда нет четко выделенной экспертизы или она есть, но при этом все считают возможным играться в исследования, UX-эксперт сталкивается со все теми же ветряными мельницами, но теперь уже приходится убеждать всех в своей собственной экспертизе и при этом так, чтобы не получить “не способен воспринимать критику” в квартальной оценке.   Конечно годные советы возможно получить и от вашей бабушки, и к критике нужно быть открытым, но если вы уверенны в своей экспертизе, доверяйте опыту и прежде всего исследованиям. При этом к экспертизе коллег важно прислушиваться, но преимущественно в том случае, если советы исходят из позиции рисков, которые эксперт видит в своей предметной области. Давайте резюмируем сказанное выше: 1. Узнайте, что вас ждет на новой работе. Какова культура UX в компании?  Как в конкретной команде выстроен процесс discovery?  Бывали ли кейсы, когда по итогам исследований продукт отказывался от изначального формата реализации или сильно модифицировался? Кто будет непосредственно отвечать за UX в команде?  Для самых смелых: что будет делать РО если его видение будет расходиться с результатами исследований?  2. Прежде чем принимать решение о найме, пообщайтесь с UX-дизайнерами которые уже работали или продолжают работать в компании. 3. Если вы уже сталкиваетесь с токсичным UX или полным отсутствием заинтересованности в UX в команде, подумайте, насколько для вас важно продолжать работу на текущем месте. Помните, сопротивление требует огромных усилий, которые вы могли бы потратить на собственный профессиональный рост и развитие экспертизы.  4. Если вы все же решили перевернуть игру или просто хотите укрепить свои позиции как эксперта в команде, давайте разберем несколько ключевых вещей, о которых надо помнить при коммуникации с бизнесом и командой в целом.  Есть штука, поняв которую вы сможете действительно стать, простите за пошлость, лучшей версией себя, как UX дизайнера. Майндсет о котором я хочу с вами поговорить, поможет вам выстроить здоровые отношения с РО, повысить свой авторитет в команде, а главное, реально доказать важность своей роли для продукта.  Это сложно, но можно. Вместо, того, чтобы позволять РО приходить к вам с готовым решением, и говорять, что ему нужна вот эта конкретная кнопка, вот эта конкретная фича, вот это что-то еще, вам нужно: Взять себя в руки; Побороть соблазн схватиться за реализацию этого решения сломя голову; Не спрашивать, когда вашему РО нужно предоставить результат. Нет! Забудьте! Хватит это терпеть!   Вместо этого попытайтесь действительно понять вашего РО и проблему, которую он пытается решить, задавая ему правильные вопросы: Попытайтесь понять, что заставило РО попросить вас реализовать именно это решение? Почему он решил, что в первую очередь нужно реализовать именно это? Каких результатов он ожидает от реализации функционала? На что именно РО опирался при формировании решения? Может быть есть какие-то исследования, которые подтвердили необходимость в реализации этой фичи? Соответствует ли этот продукт рынку?  Пользователи эту фичу хотят вообще? А если речь о чем-то супер-инновационном, какую проблему пользователя фича решает? На самом деле, вопросы могут быть любыми, но они должны привести вас к пониманию проблемы, которую вы решаете. Все это должно привести вас к ответу на вопрос “Зачем?” вы решили делать что-то. Помимо всего прочего в подобных вопросах очень важна эмпатия.  Чтобы подготовить почву для нее задайте себе вопрос - если бы это был мой продукт, что бы я делал? Дайте понять с самого начала взаимодействия с РО, что вы не пытаетесь поставить под сомнение его экспертизу или видение, вы хотите принести максимальную пользу продукту и бизнесу и для этого, вам как исследователю, нужно максимально полно понимать проблему и цели, чтобы предложить оптимальное решение. Смена восприятия себя с человека который исполняет задачу, на человека, который думает и задает вопросы, прежде, чем начать делать что-то - это очевидный, но трудный и очень важный шаг для исследователя.  Если мы посмотрим на пересечение функций РО и UX/UI дизайнера, мы увидим, что вы оба ответственны за ряд крайне важных для продукта задач. Вы оба работаете в паре и отвечаете за результат, когда речь касается: Исследования пользователей. Формулирование use case и пользовательских сценариев. Проведении воркшопов. И ряда других стадий дизайн процесса. Таким образом очень важно, чтобы вы и ваш РО работали сообща, для получения качественных и нужных для продукта результатов.  Вовлекайте РО в исследования на ранних стадиях. Начните с вопросов, которые мы обсудили ранее.  Представьте вашему РО понимание того, какие гипотезы вы собираетесь проверять и позвольте ему дополнить их перечень своими. Кратко расскажите об инструментах исследований и если это требуется обзорно погрузите в дизайн самого исследования, чтобы РО понимал что именно вы будете делать. Привлекайте его во время самих исследований, позовите на одно из интервью, дайте понаблюдать за фокус группой, позовите на юзабилити. Презентуйте результат исследований всей команде. Все эти действия помогают сделать РО активной я бы даже сказала созидательной частью процесса исследований, прочувствовать их важность и собственную погруженность в них. Это как с феноменом Икеи (*покинувшая Россию, но не запрещенная организация), когда мы собираем шкаф вот этими вот ручками, нам сложнее от него отказаться, выкинуть. Тут работает так же, когда РО участвует в исследованиях, они с меньшей вероятностью лягут в стол и с большей вероятностью будут восприняты в серьез. А еще, то что вы вовлекаете в этот процесс РО сделает его чуточку счастливее и тронет сердечко пониманием, что его мнение для вас важно.  Вам не нужно отправлять РО на модерацию каждый пиксель, но когда у вас появляется сырой драфт, покажите его вашему РО. Запросите у него обратную связь. При этом избегайте абстрактных запросов в духе “Ну как тебе?”. Это обычно раздражает и возлагает на отвечающего дополнительную нагрузку в виде дум о том, с чего начать, что именно я должен сказать, что конкретно от меня хотят услышать.  Вместо этого запрашивая обратную связь структурируйте ее заранее: скажите, что сначала вы пройдетесь по флоу в целом. А после, зададите вашему РО именно те вопросы, которые лично у вас вызывают сложности при проектировании этого интерфейса. Работа в таком ключе может быть действительно полезной, ведь погружаясь в отрисовку, вы можете не заметить замыленным взглядом важных деталей, так что фидбэк со стороны, может помочь избежать ошибок на ранней стадии. Для РО очень важно понимать что вы будете делать дальше. И если вы не договоритесь и не зафиксируете с ним следующие шаги, ему либо придется сделать это за вас, либо в какой-то момент он поймет, что не понимает, что вы там делаете. А поскольку мы РО, между нами девочками, немножко контрол-фрики, то ваш продакт будет ерзать на стуле до тех пор пока, например не обушит на вас свои ожидания, о которых вы ничего не знали или чего доброго не устроит вам сессию живительного микроменеджмента. Делайте заметки после встреч, если ваш продакт этого не делает. Это позволит: Вам не упустить ничего. Снизить степень неопределенности и беспокойства продакта. Избежать столкновения с фантазиями на тему ваших задач, о которых кроме РО никто не знал. Нет, вам не нужно делать работу за РО и считать экономический эффект, рисовать дорожные карты и формулировать product-market-fit. Но дизайнер, не осознающий цели бизнеса, это самый распространенный кейс с которым сталкиваются РО и это основной барьер между нами. Вам нужно понимать цели и сроки, не только для того чтобы слепо обслуживать своими решениями KPI’s, а в том числе для того, чтобы уметь отстаивать позицию которая будет исходить из долгосрочных целей продукта. Например, мы можем конечно запилить всплывающий на весь экран рекламный баннер, который будет брать в заложники семью клиента и не отпускать до тех пор, пока он не оформит нашу супер-премиум-подписку за 3 рубля. Это в короткой перспективе может поднять продажи, но позволит ли такой подход в будущем продать клиенту еще что-то? Мы ориентированы на разовую продажу или на долгосрочное сотрудничество и рост LTV? Хотим ли мы уронить NPS? Хотим ли мы растить Retention? Признаюсь честно, я сталкивалась с такими вопросами от своего дизайнера, и это очень отрезвляет. Но вы не сможете дискутировать в таком ключе пока не будете хотя бы на базовом уровне понимать цели бизнеса. Забукайте регулярную встречу с вашим РО, если понимаете, что не имеете быстрого доступа к нему. Как я уже говорила выше, это спасет вас от микроменеджмента и поможет не только рассказать о том, что вы делаете, эти встречи скорее не статусные, на них  важно говорить о том, в каких аспектах работы вы можете улучшить ваши коммуникации и быть полезными друг другу, какой помощи от РО вы ожидаете, что вам нравится / не нравится во взаимодействии.  Тут как в любых отношениях, крайне важно говорить о том, что действительно беспокоит или напротив радует, без этого любая коммуникация развалится. А оно нам надо?  Senior Product owner