Контакт с пользователем

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

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

Ты не пользователь

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

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

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

Три разговора: что на самом деле узнаёшь

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

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

Разговор с менеджером. Говорит, что хочет видеть, кто работает в выходные. Просишь показать, как делает это сейчас. Открывает Excel с вкладками по неделям — создан три месяца назад, заполнены только последние две недели, остальное пусто. Спрашиваешь: «А почему остальные недели пустые?» Молчание, потом: «Наверное, дело не в этом. Я просто не хочу заполнять это вручную каждую неделю». Настоящая задача — автоматически формировать расписание по правилам ротации, не поддерживать таблицу руками.

Разговор с курьером. «Как ты узнаёшь о своей смене?» — «Менеджер пишет в общий чат за день, иногда забывает». — «Бывало, что вышел не в ту смену или узнал слишком поздно?» — «Два раза так было». Это отдельная проблема: расписание не доходит до исполнителя надёжно и вовремя.

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

Что делать с тем, что услышал: не пытаться реализовать всё сразу. Записать три проблемы и выбрать одну. Если одна и та же боль всплыла у двоих из троих — берут её: повтор сам по себе сигнал, что она реальная. Здесь так не вышло: задачи у всех троих разные, и тогда выбирают по остроте. Самую острую дал первый разговор — невыход без сигнала. Именно её и брать первой: она конкретная, измеримая и явно болит. Остальные — зафиксировать и вернуться позже.

Кого спрашивать

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

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

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

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

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

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

Четвёртое: ответы будут противоречить друг другу, и это нормально. Один говорит «главное — скорость», другой — «главное — чтобы не терялось». Разбирают это тремя ходами, по порядку:

• Проверить, не разные ли это роли. Чаще всего противоречия нет: это два разных человека с двумя разными работами, и каждый прав внутри своей. Тогда вы нашли не противоречие, а два сегмента.
• Вернуться к фактам. Мнения противоречат, поведение — редко. «Расскажи, как было в последний раз» у обоих: если один два раза за месяц терял данные, а другой ни разу не ждал дольше секунды, спор решён без спора.
• Взять третий разговор как голос. Если после трёх картина всё ещё расходится, это сигнал, что вопрос требует не разговора, а замера: выкатить маленький срез и посмотреть на поведение.

Чего делать не стоит: усреднять противоречащие ответы в «компромиссное» требование. Среднее из «быстро» и «надёжно» обычно не нужно никому; выбор одного из двух с записанной причиной — рабочее решение.

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

Три формы контакта

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

Первая — короткий разговор. Десять-пятнадцать минут с тем, у кого есть та самая задача. Не презентация твоей идеи, а расспрос про его работу: как он сейчас это делает, что в последний раз пошло не так, сколько это заняло. Найти человека проще, чем кажется: написать напрямую с коротким объяснением («делаю инструмент для X, хочу понять, как вы сейчас это делаете — 15 минут?») работает лучше, чем ждать «правильного момента».

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

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

Третья форма стоит подробнее, потому что она единственная работает до того, как что-то написано, — и именно поэтому её чаще всего пропускают.

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

Описание словами. Пишете диспетчеру три предложения: «Представь: за 20 минут до начала смены курьер не отметился, и тебе приходит сообщение — „Петров не отметился, смена в 10:00, свободны Иванов и Сидоров“. Что бы ты сделал дальше?» Стоит пять минут. Ответ проверяет главное — понятен ли сценарий и попадает ли он в работу. Здесь чаще всего и выясняется недостающее: «а мне надо знать, он совсем не выйдет или опаздывает — это разные действия».

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

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

О чём спрашивать при такой проверке — три вопроса, и ни один из них не про красоту:

• «Что ты сделаешь дальше?» проверяет понятность.
• «Когда это тебе пригодилось бы в последний раз?» проверяет попадание в работу: если человек не может вспомнить случай, сценарий решает воображаемую проблему.
• «Что здесь лишнее?» проверяет объём. На этот вопрос отвечают охотно и точно, а на «чего не хватает» — фантазиями.

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

Когда пользователей нет под рукой

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

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

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

• Просить не выводы, а случаи. Не «чего хотят клиенты», а «расскажи про последние три обращения по этой теме — что именно писали». Формулировки клиента доходят почти без искажений.
• Читать первоисточник. Обращения в поддержку, переписка с клиентами, записи звонков продаж — это готовый материал, который уже есть и который почти никто не читает. Час чтения обращений по теме заменяет разговор.

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

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

И то, что остаётся всегда доступным — четыре источника без единого разговора:

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

О чём спрашивать, а о чём бесполезно

Есть надёжное правило: спрашивай о прошлом поведении, а не о будущих желаниях. «Стали бы вы пользоваться функцией X?» — вопрос, на который почти все вежливо отвечают «да», и это «да» ничего не стоит. Человек плохо предсказывает себя и хочет тебя порадовать. А вот «расскажите, как вы делали это в прошлый раз» — про факт, который был; тут не приукрасишь так легко.

Отсюда же главные ловушки. Наводящий вопрос («удобно же, правда?») вытягивает подтверждение, которое ты сам и заложил. Рассказ о своей идее до того, как расспросил человека, сбивает его на оценку твоей задумки вместо описания своей боли. Усреднение — «обычно я…» — прячет реальные случаи; нужно тянуть к конкретике: «когда именно в последний раз, что тогда произошло». Продукт-инженер слушает в разы больше, чем говорит, и держит свои решения при себе, пока не услышал проблему.

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

Замкнуть петлю в работе одного

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

Но и ответственность та же — петлю обратной связи никто за тебя не замкнёт. Замкнуть — значит не только спросить до, но и посмотреть после: как пользуются тем, что выкатил, делают ли то, на что ты рассчитывал, ушла ли боль. Этот «после» — уже про бизнес-метрику: контакт говорит, что чинить, метрика — починилось ли. Без обоих ты гребёшь вслепую, как бы быстро ни грёб.

На практике «посмотреть после» — это не обязательно большое исследование. Часто достаточно написать тому же диспетчеру через две недели: «Как работает то, что мы запустили? Есть ситуации, где не помогает?» Пять минут разговора после выкатки стоят больше, чем пятьдесят минут теоретизирования до неё. И именно этот повторный контакт чаще всего открывает следующую реальную задачу — не ту, которую ты придумал сам.

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

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

Контакт — не этап перед разработкой. Это непрерывная часть самой разработки.

Разговор и замер читают вместе

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

Разница простая. Разговор отвечает на вопрос «почему»: что человек делает, где спотыкается, помогло ли ему. Замер отвечает на вопрос «сколько»: у скольких изменилось поведение и насколько. Каждый в одиночку врёт предсказуемым образом:

• Разговор врёт в сторону вежливости и выборки. Тот, с кем вы говорите, обычно самый лояльный и самый вовлечённый; он скажет «стало лучше», потому что это правда для него и потому что ему приятно вам это сказать. Двое довольных не означают, что сработало у всех.
• Замер врёт в сторону отсутствия смысла. Цифра сдвинулась — а почему, неизвестно; не сдвинулась — а причина может быть в том, что люди не нашли новую функцию, а не в том, что она не нужна.

Поэтому их читают вместе, и интереснее всего именно случаи расхождения:

Вторая строка — самая коварная и самая частая. «Диспетчер сказал, что стало удобнее» — отличная новость, которая ничего не говорит о том, изменилось ли что-то у остальных. Именно здесь разговор и подменяет замер: приятная обратная связь создаёт ощущение результата, а проверить его никто не идёт.

Практическое правило: после выката делают и то и другое, и записывают отдельно. Замер даёт число, разговор — объяснение к числу. Как выбирать, что мерить, и какие сроки считать разумными — в статье про бизнес-результат.

Что это значит на практике

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

Ошибки, которые повторяются чаще всего:

• Рассказать идею до расспроса. Как только ты объяснил свою задумку, человек переключается с описания своей боли на оценку твоей задумки. Сначала — слушаешь, потом — говоришь. Всегда.
• Спрашивать о будущем поведении. «Стали бы вы пользоваться?» даёт вежливое «да», которое ничего не значит. Работает только вопрос про прошлое: «Расскажи, как делал это в последний раз».
• Поговорить с одним и считать, что картина ясна. Один человек — один угол зрения. Нужно два-три контакта, чтобы понять, что повторяется, а что случайность. Три разговора укладываются в один рабочий день.
• Пропустить контакт после выкатки. Поговорить до — хорошо. Но без взгляда после — только половина петли. Видишь ли ты, как пользуются тем, что сделал? Ушла ли боль или люди просто нашли другой обходной путь?
• Провести контакт и ничего не поменять в задаче. Разговор должен влиять на то, что ты строишь. Если после каждого контакта задача остаётся ровно такой же — значит, ты слышишь, но не слушаешь.

Глубже: что можно записывать: персональные данные и согласиерасширенное

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

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

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

Клиенты-компании. Разговор с сотрудником заказчика проходит по правилам договора: соглашение о неразглашении, разрешение представителя заказчика на интервью, никаких данных заказчика в ваших заметках. Правила короткие, и их записывают на одну страницу вместе со сценарием разговора; продукт-инженер, который узнал о них от юриста после инцидента, теряет доступ к пользователям надолго. Подробнее о требованиях закона в статье про 152-ФЗ в разделе безопасности.

Коротко

• Разработчик не пользователь: картину дают два-три разговора о прошлом поведении, а не вопросы о будущем.
• Сначала слушать, потом говорить; контакт до задачи и после выкатки, и каждый контакт меняет задачу.
• Запись разговора и экрана только с согласия и минимумом, цитаты обезличены, события без персональных данных с основанием и сроком хранения, у заказчиков по договору; правила на одной странице до первого разговора.
• Три формы контакта, интервью, наблюдение и обратная связь после выкатки, укладываются в один рабочий день и повторяются как ритм, а не как исследование раз в квартал.
• Собеседника выбирают по роли: у исполнителя спрашивают про препятствия, у ответственного за результат — про цель, отдельно берут получателя результата дальше по цепочке, новичка и того, кто перестал пользоваться.
• Самый громкий жалобщик — лучший вход в тему, но не типичный носитель проблемы: следующие два разговора обязательно с теми, кто не жаловался; противоречия чаще означают два сегмента, и усреднять их нельзя.
• Проверка на наброске работает до написания кода: описание словами, макет с вопросом «что сделаешь первым» и ручная имитация сценария; ищут не одобрение, а место, где собеседник запнулся.
• Когда пользователей нет под рукой, остаются наблюдение за текущим способом работы, случаи из поддержки и продаж вместо их выводов, поведение в продукте и люди с той же работой вне продукта; непроверенная проблема остаётся помеченной гипотезой.
• Разговор после выката не заменяет замер: разговор отвечает «почему» и врёт в сторону вежливости, замер отвечает «сколько» и не объясняет причин; самый коварный случай — хвалят, а число не сдвинулось.

Что почитать дальше

Контакт даёт картину проблемы — дальше нужно выбрать, что строить первым, и договориться с собой, как понять, что сработало. Об этом — «Наименьший ценный срез» и «Бизнес-метрики». А о том, как устроена роль продукт-инженера в целом — кто это, что он делает и почему один человек с агентом может больше, чем раньше могла команда, — в обзоре «Продукт-инженер».