Кажется, что исследовать собственные продукты очень легко. Но это утверждение верно только для относительно простых b2c-продуктов. В исследовании использования b2b-продуктов много неочевидных сложностей и подводных камней. Рассказываем, как это происходит у нас в MANGO OFFICE.

Что нужно знать

Для изучения использования любого b2b-продукта исследователям необходимо разбираться, как он работает, какие сценарии важны для клиентов, какие тарифы установила компания. Глубина погружения во многом зависит от особенностей применения и сложности продукта. Бывает, что достаточно разбираться в нём верхнеуровнево.

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

К тому же клиенты часто считают — и вполне обоснованно — что исследователь должен досконально знать собственный продукт.

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

У нас в компании есть внутренний сленг департаментов продаж и клиентского обслуживания. Он отличается от терминов в технической и пользовательской документации. Однажды из-за этого произошел курьёзный случай. В одном из исследований респонденты называли элемент интерфейса «чек-лист». Но это выражение не упоминалось в документации. Долго пытались понять, что это такое. И наконец выяснили, что выражение «чек-лист» пошло от менеджеров по продажам, которым оно показалось удобнее официального.

Процессы

Если руководство готово выделить достаточный бюджет на исследования, провести их будет гораздо легче и быстрее. К сожалению, не всегда удаётся получить нужные суммы. Это затягивает поиск респондентов. Поэтому длительность проведения исследования у нас в среднем 1-2 месяца. Из-за этого не всегда удаётся реализовать быстрые программы. В этом отношении мы выглядим лучше многих банков, но уступаем компаниям с высокой исследовательской культурой (Контур, Авито, VK).

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

Подготовка к исследованию

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

Пример брифа: 

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

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

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

Бэклог

После брифинга мы составляем бэклог — список практических задач для исследователей и отмечаем их статусы:

• «В работе»

• «В процессе исследования»

• «Анализ собранных данных»

• «Сделано»

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

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

Гайд

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

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

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

Прототип для исследования

Бывает, что для исследования нужно создать прототип. Есть разные варианты:

1. Макет в Figma или другой программе прототипирования.

2. Рабочий прототип продукта в тестовой среде.

3. Рабочее решение в проде.

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

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

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

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

Привлечение респондентов к исследованиям

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

Внутренние сотрудники

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

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

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

Клиенты MANGO OFFICE

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

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

Потенциальные клиенты

Для нас это самая редкая и сложная категория респондентов. Эти люди — и компании, в которых они работают, — не связаны с нами какими-либо взаимоотношениями. Поэтому нужно иметь бюджет на их привлечение и вознаграждение. Никто не захочет тратить своё время на участие в наших исследованиях за «спасибо» или шоколадку. В среднем по рынку стоимость привлечения одного респондента — 4-5 тыс. рублей, а размер вознаграждения — около 5 тыс. То есть 9-10 тыс. на человека. В b2b-сегменте удельная сумма может оказаться выше в зависимости от должностей респондентов.

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

Проведение исследований

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

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

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

Отчёты

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

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

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

Все фичи мы собираем в единый бэклог. Это упрощает работу владельцев продуктов: им не нужно самостоятельно проводить кастдевы. В бэклоге уже есть готовый список потребностей клиентов.

Резюме

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

И не забывайте о структурированном и централизованном хранении результатов исследования. Это упростит принятие решений для команд.

Над статьёй работали: Анастасия Стрельникова, Дмитрий Волков, Дмитрий Мелентьев.