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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И вот ты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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