Назвать проблему за столом, из головы, можно — но это будет твоя проблема, не пользователя. Между «мне кажется, ему тяжело заводить каталог» и «я видел, как он это делает» лежит пропасть, в которую проваливается большинство ненужных фич. Закрывается она одним способом: контактом с тем, для кого делаешь.
Звучит банально, и именно поэтому этот шаг чаще всего пропускают. Кажется, что и так всё понятно. Продукт-инженер относится к этому ощущению с подозрением: «и так понятно» — это сигнал, что ты опираешься на догадку, которую не проверял.
Ты не пользователь
Главная причина говорить с людьми в том, что ты на них не похож. Ты знаешь продукт изнутри, ты технически грамотен, ты помнишь, где какая кнопка. Пользователь — нет. То, что тебе очевидно, его останавливает; то, что тебе кажется важным, он не замечает. Свои привычки ты бессознательно приписываешь ему — и проектируешь для воображаемого человека, похожего на себя.
Это не лечится умом и опытом. Даже сильная интуиция — это сжатый прошлый контакт; когда контакт устаревает или его не было, интуиция уверенно врёт. Поэтому вопрос не в том, умный ли ты, а в том, давно ли ты в последний раз смотрел, как реальный человек делает свою работу.
Три формы контакта
Контакт не обязан быть исследованием на месяц. Достаточно трёх простых форм, и все доступны одному человеку.
Первая — короткий разговор. Десять-пятнадцать минут с тем, у кого есть та самая задача. Не презентация твоей идеи, а расспрос про его работу: как он сейчас это делает, что в последний раз пошло не так, сколько это заняло.
Вторая, самая сильная, — наблюдение. Попросить показать, как человек выполняет задачу прямо сейчас, на своих данных, и молчать, пока он делает. За пять минут наблюдения видно больше, чем за час рассказов: где он спотыкается, что обходит, какой костыль уже изобрёл. Люди не рассказывают про обходные пути — они их просто делают, не считая чем-то заметным.
Третья — быстрая проверка гипотезы. Не дожидаясь готового продукта, показать набросок, черновой экран, даже текстовое описание потока и посмотреть на реакцию. Цель — не понравиться, а найти, где человек не понял или где это решает не его задачу.
О чём спрашивать, а о чём бесполезно
Есть надёжное правило: спрашивай о прошлом поведении, а не о будущих желаниях. «Стали бы вы пользоваться функцией X?» — вопрос, на который почти все вежливо отвечают «да», и это «да» ничего не стоит. Человек плохо предсказывает себя и хочет тебя порадовать. А вот «расскажите, как вы делали это в прошлый раз» — про факт, который был; тут не приукрасишь так легко.
Отсюда же главные ловушки. Наводящий вопрос («удобно же, правда?») вытягивает подтверждение, которое ты сам и заложил. Рассказ о своей идее до того, как расспросил человека, сбивает его на оценку твоей задумки вместо описания своей боли. Усреднение — «обычно я…» — прячет реальные случаи; нужно тянуть к конкретике: «когда именно в последний раз, что тогда произошло». Продукт-инженер слушает в разы больше, чем говорит, и держит свои решения при себе, пока не услышал проблему.
Замкнуть петлю в работе одного
В большой команде контакт с пользователем часто отдают отдельной роли, и до инженера доходит уже пересказ — обесцвеченный, без деталей, которые и решают. Когда весь путь ведёт один человек, это превращается из проблемы в преимущество: тот, кто строит, сам видел, как ломается. Ничего не теряется в пересказе.
Но и ответственность та же — петлю обратной связи никто за тебя не замкнёт. Замкнуть — значит не только спросить до, но и посмотреть после: как пользуются тем, что выкатил, делают ли то, на что ты рассчитывал, ушла ли боль. Этот «после» — уже про метрику исхода: контакт говорит, что чинить, метрика — починилось ли. Без обоих ты гребёшь вслепую, как бы быстро ни грёб.
Минимум, который стоит сделать привычкой: ни одну заметную задачу не начинать, пока не поговорил или не посмотрел хотя бы на одного реального человека с этой задачей. Один живой контакт почти всегда меняет постановку — и экономит недели работы не в ту сторону.