Кейс: как мы внедряли исследования в продуктовый процесс банка «Точка»

Почему это действительно важно, как обстоят дела с исследователями в других банках (и ИТ-компаниях в целом) и что делает человека хорошим исследователем, а не просто аналитиком.

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

Заказчиком здесь может выступать владелец продукта, которому нужно что-то исследовать, или UX-дизайнер, который не уверен, как воспримут те или иные новшества в дизайне. Поэтому никто не спорит с тем, что исследователи нужны и важны, но при этом никто не может нормально включить их в процесс.

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

Во-первых, к ним то обращаются, то нет. Во-вторых, когда к ним обращаются, то не очень тщательно рассчитывают время, которое понадобится на исследования.

И именно эту позицию удалось продвинуть в «Точке».

Тут надо сразу сделать небольшое отступление — когда ты внедряешь что-то совсем новое в любые процессы (а подход «исследователь = полноценный член команды» был, прямо скажем, в новинку), то важно это делать постепенно.

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

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

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

В «Точке» же главным плюсом было отсутствие когнитивного диссонанса между теми ценностями, которые компания объявляла, и тем, что компания делала. Говорят сотрудникам на встрече, что у нас в приоритете клиент, поэтому мы делаем всё для клиента, значит, так и есть.

Тут проблема в том, что говорят так вообще все, от крупнейших банков до подмосковных парикмахерских. Но на деле оказывается, что когда у клиента возникает какая-то проблема, его нужды сразу откидываются на второй план: «У нас сотрудник в отпуске, подождёт клиент, ничего страшного»; «Рабочий день кончился, завтра подумаем, чего там у него срочного».

В общем, количество вариантов «Вас много, а я одна» тут зашкаливает.

А когда твой персонал знает, что то, что ты говоришь — это правда, и ты на самом деле имеешь это в виду и делаешь это, то все твои решения и инициативы встречаются совсем по-другому. Тут стоит сказать спасибо Борису Дьяконову и Яне Ганник, основателям «Точки», которые не только придерживаются такого майндсета, но и учат этому сотрудников.

Они же и продвигали команду исследователей и изменение процессов внутри. Поэтому эта философия без искажения спускается от руководящего лица до каждого сотрудника, который работает с клиентами. Без этого было бы сложнее.

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

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

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

А они всегда заточены просто на получение каких-то метрик или ответов «Да» или «Нет» — как быстро был сделан тот или иной шаг в сервисе, как быстро удалось достигнуть поставленной цели и прочее. И людей, работающих чисто на метрики и поверхностные ответы, довольно много. А вот людей, которые умеют делать качественные глубинные исследования, почти нет.

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

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

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

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

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

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

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

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

Как это обычно работает — у бизнеса появляется какая-то идея сервиса, которую можно оперативно набросать в прототипе. Потом мы (исследователи) вместе с продуктологом собираем различные гипотезы, набираем пользователей и проводим исследование на предмет того, нужен ли им такой продукт. Когда ты понимаешь саму потребность в продукте, можно начинать представлять, как именно он должен выглядеть.

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

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

Кроме этого, концептуальные исследования помогают нормально определиться с ценой продукта для конечного пользователя. Достаточно найти поведенческие портреты и провести исследования, чтобы понять, какая сумма за ежемесячную подписку или разовую плату будет приемлемой для всех. И, кстати, это не всегда «чем дешевле, тем лучше». Есть интервалы цены: слишком мало, слишком много и что-то среднее – интервал приемлемой цены за предложенную пользу.

Например, люди отвечали, что если такой сервис обходится им в 200 рублей, то он воспринимается как не несущий какой-то пользы. Ну не может что-то полезное и хорошее для бизнеса стоить так мало, такое вот восприятие у людей. Если же дороже 2000 рублей, то это уже повод подумать, что дорого. Поэтому интервал приемлемой цены данного продукта был в вилке 500–1000 рублей, чтобы не отталкивать ни один из поведенческих портретов.

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

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

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

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

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

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

Выход — наращивать количество исследователей, чтобы в каждой продуктовой команде был свой. На крайний случай — 0,5. Продуктологи смогли сами посчитать по своим объёмам работ, что, например, команде, которая занимается расчётным счётом, с их загрузкой нужно 1,5 исследователя, а команде мобилок — 0,5.

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

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

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

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

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

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

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

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

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

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

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

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

А ещё критично важным остаётся обычное общение в рамках команды. Причём не удалённое — потому что когда у тебя разработчики и продуктологи в Екатеринбурге, а исследователи в Москве, нельзя просто так взять и нарисовать вместе с ними что-то по-быстрому. Несмотря на множество сервисов для командной работы.

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