Ревью с клиентами до и во время пандемии

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

Ревью с клиентами, или, как мы иногда называем такие неформальные встречи, Pizza Testing, нужны для того, чтобы понять, насколько вашим продуктом или сервисом удобно пользоваться в текущий момент времени. Исследования, которые запускаются под конкретную задачу, обычно проводятся не так часто – раз в квартал, полгода, год. Однако для команды, которая постоянно делает новое, выпускает релизы, ищет баги и исправляет их, этого мало. Ей нужно постоянно быть на связи с конечными пользователями. Один из инструментов для этого – ревью с клиентами. Как любое другое ревью, оно проводятся часто – один-полтора раза в месяц. Pizza Testing выявляет даже самые мелкие нюансы опыта взаимодействия с продуктом и дает команде возможность быстро проверить гипотезы потребностей и решений.

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

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

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

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

Третий этап – валидация гипотез. Команда заранее готовит список гипотез на проверку, а также вопросы, которые помогут их подтвердить или опровергнуть. К примеру, мы предположили, что клиенты не хотят менять банк, так как им придется вручную переносить данные всех контрагентов. Вопросы будут строиться вокруг этой гипотезы. К примеру: «Что может подтолкнуть вас к решению сменить банк?», «Как вы переносите данные партнеров из одного банка в другой?». Обычно на ответы достаточно 20-30 минут.

Наконец, если есть, что показать клиентам, вы проводите UX Test. Пользователям предлагается в течение 20-30 минут решить ряд задач, а команда наблюдает, как у них это получается: какие сложности возникают в процессе, сколько времени уходит на решение и так далее. Задачи для тестирования интернет-банка могут выглядеть, например, так: 1. войти в интернет-банк; 2. скачать выписку для налоговой; 3. перейти в раздел «Контрагенты»; 4. импортировать контрагентов; 5. посмотреть операции по контрагенту.

После интервью с клиентами команда вносит найденные инсайты и баги в сводный документ для приоритезации – ICE (Impact, Confidence, Ease). Веса могут распределяться по-разному в зависимости от целей команды, различных обстоятельств. Помимо стандартных критериев, таких как продажи, UX, сложность реализации, мы учитываем повторяемость – насколько часто клиенты упоминали эту проблему. Такой документ удобно передать другой команде, если в ходе исследования вы обнаружили инсайты, которые могут заинтересовать и ее.

Основные выводы исследования входят в отчеты, доступные всем сотрудникам банка на внутреннем портале.

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

Проведите как минимум три встречи с командой перед ревью с клиентами. Первую, установочную – в начале спринта (в нашем случае -- за 2,5 недели), чтобы все участники точно зафиксировали время в календарях и не вышло ситуации, что все респонденты придут уже завтра, а половина команды не сможет. Вторую – для проработки скрипта интервью с респондентами. Ее лучше провести за неделю до исследования, чтобы было время на получение обратной связи от команды и владельца продукта. Третью, статусную – за один-два дня до ревью. На ней команде нужно сообщить, что реcпонденты найдены, все в силе, ответить на вопросы, если такие будут. На первую и последнюю обычно уходит не более 15-30 минут.

Вовлекайте в общение с клиентами всю команду, а не только исследователей и дизайнеров. Это повышает уровень эмпатии команды к клиенту и понимание какие проблемы у клиентов есть при взаимодействии с продуктом и сервисом не по наслышке.

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

В подавляющем большинстве случаев достаточно 5 респондентов. Ребята из Nielsen Norman Group еще в 2012 году доказали, что тестирование 5 человек позволит найти почти столько же проблем с юзабилити, сколько вы нашли бы с гораздо большим количеством участников, при этом соотношение выгоды-затраты будет оптимальным. Наш опыт это подтверждает, поэтому на свои ревью мы приглашаем 5 основных респондентов и 2 запасных – на случай, если кто-то не сможет.

Поручите подбор респондентов опытному сотруднику. Очень важно, чтобы профиль респондента четко соответствовал гипотезам, которые вы хотите проверить, иначе команда потратит деньги и время впустую. К примеру, нам важно, чтобы в выборку попадали люди в возрасте 25-50 лет обоих полов, которые активно пользуются мобильным или интернет-банком (в зависимости от того, что проверяем), то есть самостоятельно совершают не менее трех платежей в неделю – это константа, отражающая профиль нашего клиента. Но если у команды есть гипотезы, например, связанные с переходом клиентов в другой банк, то среди респондентов должны быть люди с релевантным опытом. Работать над профилем и брифовать агентство на поиск участников (в случае, если вы поручаете это не штатному рекруту) должен опытный сотрудник, иначе вы рискуете не получить ничего ценного по итогам Pizza Testing.

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

Что изменилось на удаленке, помимо того, что встречи «переехали» из переговорок в Zoom и всем стало удобнее: клиентам не нужно тратить время на дорогу, а команда может проводить интервью с респондентами более эффективно и меньше уставать? Проводя исследование удаленно, нельзя показать клиентам новые возможности в тестовой среде банка, потому что доступ к ней есть только с корпоративных устройств. Выхода два: выводить функциональность в прод на тестовых пользователях или отправлять респондентам ссылку на прототип в сервисах для разработки интерфейсов, в нашем случае – Figma.

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

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

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

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

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

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

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

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

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

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