Привет! Я Лера Черепанова, руковожу UX-лабораторией в Контуре. 

Большинство UX-исследователей Контура находятся внутри конкретных продуктов. Но в UX-лаборатории всё по-другому. По сути, мы внутреннее агентство — подключаемся к разным командам на 1—1.5 месяца, проводим исследование и идём в следующую команду. 

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

  • Как внедрить результаты исследования?

  • Как повлиять на изменения в продукте?

  • Как развивать пользовательский опыт?

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

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

  • Команда никогда не работала с исследователем.

  • В команде есть свой исследователь.

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

Команда никогда не работала с исследователем

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

Как это выглядит:

Команда никогда не работала с UX-исследователями, но есть один «энтузиаст», который имел такой опыт раньше или просто что-то слышал о UX-исследованиях и обратился к нам.

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

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

И вот ты:

  • не знаешь продукта,

  • не знаешь людей.

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

Как же влиять в таком случае?

Мы нашли несколько работающих принципов:

1. Не вставать в позицию эксперта

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

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

2. Говорить на языке заказчика

Если команда не работала с исследователем, то выводы в духе «пользователям неудобно проходить этот сценарий» не работают. Как только появляются более осязаемые для бизнеса формулировки вроде «из-за этой сложности конверсия в прохождение сценария падает на 20%», команда уже более вовлечена в исправление проблемы. 

3. Показывать быстрые и видимые инсайты

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

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

4. Дать команде возможность поучаствовать

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

А для нас это ещё и некая подстраховка: мы не знаем продукт досконально и не на все вопросы пользователей можем ответить. Или можем не знать какой-то смежный кусок сценария и не задать нужный вопрос. Команда про свой продукт знает всё, поэтому всегда на подхвате. 

5. Пусть команда сама формулирует дальнейшие шаги 

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

6. Не пропадать из жизни команды после завершения работы 

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

7. Оценивать применимость работы

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

И вот какую обратную связь мы получаем от заказчиков благодаря опросу:

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

В команде есть свой исследователь

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

Здесь надо понимать, что команда прокачана, отлично воспринимает исследовательские выводы и инсайты, готова меняться. Но влиять в таком случае тоже непросто: есть свой исследователь — эксперт, отлично знающий продукт. Команда часто отказывается воспринимать «чужака», который мало знаком с продуктом, но пытается влиять на решения. 

И здесь включается другая роль: внешний наблюдатель.

Когда живёшь в продукте долго, у тебя появляется «профессиональная любовь» — ты защищаешь свой продукт, свои решения.

Мы же приходим без этой любви. И можем быть чуть более безжалостными.

Наша сила — в объективности. Мы можем показать то, что команда уже не замечает.

И при этом не вмешиваться в процессы, а наоборот — помочь принять решение самостоятельно.

Мы не пытаемся внедрить своё решение «в лоб», мы понемногу расшатываем команду и тем самым влияем.

Один из моих любимых кейсов как раз связан с объективностью и «безжалостностью». Мы проводили юзабилити-тестирование большого разветвлённого сценария: тестировали два режима работы для разных пользовательских ролей. И по результатам тестирования оказалось, что один режим закрывает все сценарии, и разработка может сэкономить целых 8 месяцев работы (!). 

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

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

Несколько часов сессий мозгоштурмов с модерацией исследователя всё-таки привели команду к лучшему решению — в разработку ушёл один макет.

Вывод

Если подводить итог, то можно сказать, что задача UX-исследователя — не просто добывать данные, а быть катализатором изменений. Мы не приходим, чтобы «выдать отчёт, забыть и идти дальше». Мы приходим, чтобы научить команду мыслить доказательно и с оглядкой на пользователей. И эмпатии к пользователю, конечно, тоже учим.

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

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

Больше про UX-исследования — в телеграм-канале Сдоба.