Как и почему надо общаться с пользователями

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

История эта, как ни странно, про стетоскоп. Вплоть до начала 19 века у врачей практически не было возможности понять, что происходит в организме больного. Следствием этого стало то, что симптомы принимались за саму болезнь: то есть, если сейчас у человека жар, это может быть признаком десятка болезней, в те же времена болезнь была одна — жар, и лечили ее одним и тем же способом (что, конечно, далеко не всегда давало хороший результат). Но в один прекрасный день французский врач Рене Лэннек свернул в трубку свою тетрадь и приложил к груди пациента — вместо того, чтобы простучать ее пальцами, как делали раньше. Лэннек не только изобрел стетоскоп и улучшил качество диагностики: новый уровень слышимости позволил различить множество разных болезней и, соответственно, предложить новые способы лечения.

Со временем стетоскоп стал неотъемлемым атрибутом любого терапевта, но сейчас, когда появился ультразвук, рентген и прочие, более точные способы исследований, в медицинском сообществе начал возникать вопрос — а нужен ли стетоскоп?

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

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

Что я понимаю под “базовым общением с пользователями”

Дисклеймер: я пишу исключительно о своем опыте и о том, что работает/не работает для меня. Если вы успешно пользуетесь каким-то методом и делаете крутой продукт, вам не нужна эта статья 😉

Начну с того, что им не является:

• опросы типа “Как вы относитесь к X?”, “Какая картинка вам нравится больше — зеленая или красная?”.

Даже если вы попросите пользователя написать абзац текста (а не выбрать из несколько вариантов):

1) вы можете некорректно сформулировать вопрос и повлиять на ответ пользователя
2) вы можете выбрать неправильную последовательность вопросов, которая повлияет на ответ пользователя
3) пользователь может неправильно понять вопрос
4) пользователь может ответить коротко и не раскрыть тему до конца
5) вы можете неправильно понять ответ пользователя

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

Почитайте вот эту статью, например, про то, как легко “сместить” восприятие пользователя. Ну или кейс из моей практики: мы хотели посчитать NPS и спрашивали у пользователей по шкале от 0 до 10, насколько они готовы порекомендовать продукт. Группа А видела просто шкалу; в ней средний результат был 7.5. В группе Б на шкале уже стоял преселект на отметке 6. Средний результат — 8.9.

• customer development

Product development answers the question “When (and what) can they buy?”
Customer development answers the question “Will they buy it?”
(из книги Cindy Alvarez)

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

Во-первых, вам очень повезло, что аудитория вашего продукта потенциально такая широкая, что вам подойдет первый же прохожий.
Во-вторых, вы застаете людей врасплох. Это значит, что ваше время общения будет сильно ограничено (и до истинных проблем вы не успеете докопаться), да и откровенность респондентов тоже (вот честно, будете ли вы вываливать всю подноготную на, пусть и обаятельного, незнакомца?).
В-третьих, что самое главное, вы тестируете не сам продукт, а его маркетинговую часть (в частности, позиционирование и ценообразование). Если вы классный сейлз, то продадите любую идею. Но лично для меня показатель качества не ответ на вопрос “купят ли?” (сколько людей покупает кучу треша, который им совершенно не нужен; да и достигается увеличение этой метрики во многом не через улучшение качества продукта), а “будут ли регулярно пользоваться” (ну и платить, если уж на то пошло).
В общем, я использую этот метод примерно так же, как 5 seconds test, — могут ли люди, никогда не видевшие продукт, за короткое время четко понять его value proposition. Но это точно не относится к регулярному общению.

• сложные usability исследования, для подготовки которых требуются человекоресурсы, деньги и время

Этнографические исследования, diary studies, UX исследования в лаборатории и так далее — все то, что вы будете делать, скорее, ad hoc, чем на регулярной основе, потому что это дорого и долго. Вот здесь хороший чеклист для определения хорошего исследования.

Какие же тогда критерии для базового общения с пользователем?

• случается регулярно
• может быть организовано кем угодно в команде (PMом, дизайнером, разработчиком)
• основано на поведении пользователя
• ну да, и продукт уже существует. Когда вы на стадии прототипа, это другой тип исследований

Примеры:

• разбор и ответы на тикеты в саппорте. В Intercom с ними работает весь R&D и особенно PMы
• сбор фидбэка после запуска беты/фичи
• разговор с пользователем, который делает что-то в вашем продукте не так, как другие пользователи.

Зачем нужно общаться с пользователем

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

Но и для компаний с другой бизнес-моделью это необходимый инструмент. Если вы смотрите исключительно на цифры и во всем полагаетесь на результаты A/B экспериментов, то рискуете решать не проблему, а ее последствия. Как ни странно, это приводит в итоге к замедлению разработки — потому что вы лечите не болезнь, а ее симптомы.

Уже лучше, если у вас в команде (или на аутсорсе) есть исследователь; но, как мы уже говорили, подобные тесты требуют больших ресурсных затрат и потому проводятся не так часто (раз в месяц уже хороший показатель). Как следствие, теряется связь с пользователем, “чутье”, которое позволяет продакту принимать решения. Если держать постоянный контакт, то, на самом деле, и масштабные юзабилити тестирования будут требоваться не так часто.

Расскажу чуть подробнее про то, что я делаю на регулярной основе:

• анализ запросов в поддержку. В Intercom вообще есть традиция делать Customer Support Day и идти на день работать в саппорт. Но здесь речь не совсем про то, чтобы отвечать на вопросы пользователей (хотя это тоже супер полезно).

Мы используем Idiomatic — тулзу, которая позволяет группировать запросы по темам, и проводить базовый анализ: например, на этой неделе возросло количество жалоб на фичу x, но стали меньше писать про фичу z.

Также у наших саппортов есть система тегов непосредственно в Intercom, чтобы продактам было легче категоризировать запросы; плюс, если пользователь просит новую фичу, саппорты просят подробнее рассказать про use case.

Я стараюсь каждую неделю “нырять” в самую “громкую” группу: беседую (либо прямо в нашем же чате, либо по телефону) с пользователями, чтобы докопаться до проблемы. Все инсайты я заношу в ProductBoard как центральное место для сбора фидбэка: меня покорило расширение для браузера (выделяю кусок чата, нажимаю кнопку, отправляю фидбэк с комментарием — огненно!) и привязка фидбэка к фичам. Дизайнеры/разработчики, которые в данный момент работают над реализацией, могут посмотреть на пользовательские кейсы; если же фича новая, эта информация затем помогает в приоритезации и подготовке роадмапа на следующий квартал.

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

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

Еще нельзя забывать, что запросы в поддержку — это все же vocal minority. Не поддавайтесь на провокации и обязательно валидируйте гипотезы количественно ;)

• фидбэк на бету/новую фичу. Нам опять повезло: мы активно используем для этого собственный продукт — к примеру, тегируем кастомеров в эксперименте и затем отправляем им сообщения с “разогревающим” вопросом (что-то простое, вроде — вот наша фича, так она работает, что думаете). Сообщение должно быть максимально короткое и простое, чтобы пользователь захотел черкануть хоть строчку, а там уже продакт может подхватить разговор и договориться о созвоне. Пользователю хорошо, потому что мы рассказали ему о новой функциональности (еще круче, если он о ней когда-то просил, и тут вдруг мы ;); нам хорошо, потому что есть предлог еще раз пообщаться с людьми, — сплошной win-win. Для нас это важно еще и потому, что наши два принципа ship to learn и start small, think big предполагают несколько итераций — и как раз фидбэк помогает понять, какой шаг должен быть следующим.

Что важно: делать это по горячим следам — зарелизили, собрали фидбэк.
Дальше, если что-то по цифрам не сходится, пошли собирать фидбэк еще раз (но это, конечно, неприменимо к фичам, где требуется долгий период адаптации/обучения).

• “в режиме чтения” (а не общения): разговоры потенциальных пользователей с сейлзами. Вот тут как раз много можно узнать о конкурентах, о их текущих проблемах, о киллер-фичах, которые могут повлиять на решение о покупке. Это работает для b2b; для b2c должно быть регулярное полномасштабное исследование на уровне компании (а не только разработки): у нас оно информирует стратегию или запуски новых продуктов (как раз, например, Live Chat for Sales, над которым я работаю).

Регулярное общение с пользователем очень важно, но о трех вещах нельзя забывать:

1. Любой фидбэк — это симптом. Вам же нужно докопаться до «болезни». Тулзы, где пользователи видят запросы друг друга и голосуют, относительно бесполезны: очень часто за похожими формулировками скрываются абсолютно разные проблемы. Поэтому если тупо брать за основу любой фидбек, ни к чему хорошему это не приведёт. Надо смотреть глубже :)
2. Фидбэк, который вы используете, должен быть основан на поведении пользователей: либо у них не получается что-то сделать в продукте, либо они как-то по-новому с ним работают, либо решают задачу с помощью конкурентов.
3. Любой качественный фидбэк должен быть затем валидирован на данных.