$ sudo teach IT

Введение

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

Задача продакта — не просто “спросить”, а понять. Пользователь не всегда осознаёт свои желания. И уж точно не обязан формулировать за вас правильное решение.

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

Что вы узнаете из статьи

✅ Почему пользователь не всегда говорит то, что думает

✅ Как отделять реальные потребности от мнений

✅ Какие методы помогают понять поведение пользователя

✅ Как комбинировать данные, интервью и тесты

✅ Почему действия важнее слов

Ключевые термины

📌 Потребность — реальная задача или мотивация пользователя (часто неявная).
Допустим,  пользователь заходит в приложение в 23:55. Он не говорит «хочу тёмную тему», но его потребность — не слепнуть от белого экрана ночью.

📌 Гипотеза — предполагаемая проблема, потребность или решение, которое можно проверить.
Например, продакт предполагает «Если упростить регистрацию до одного шага, увеличится количество завершённых онбордингов».

📌 Сигналы поведения — действия, которые указывают на ценность или боль.
Пример: пользователь пытается нажать кнопку «скачать PDF», которой пока нет — это сигнал, что ему нужен экспорт.

📌 А/Б-тестирование — метод проверки двух версий одного элемента.
Пример: сравниваем кнопку “Зарегистрироваться” и “Попробовать бесплатно” — и смотрим, где выше конверсия.

📌 Смоук-тест — проверка интереса без полной реализации.
Пример: добавляем кнопку “Премиум-режим” с заглушкой “Скоро появится”. Если на неё кликают — проверка прошла, интерес есть.

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

Пользователь — не исследователь. Он не обязан формулировать проблемы точно, логично и в терминах JTBD. Более того — он часто не говорит то, что на самом деле думает или делает.

Как с этим быть? Разберем ниже

Почему нельзя просто спросить

Пользователь:

  • Хочет быть вежливым (скажет «нравится», чтобы не обидеть)

  • Не знает, чего хочет, но узнаёт, когда видит

  • Думает как человек, а не как продакт (не формулирует фичи, он формулирует боль)

  • Может говорить одно, но делать другое

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

Что на самом деле говорит пользователь:

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

📌 Лучше спросить:

«Что вы пытались сделать в тот момент?»
«Что вам было непонятно?»
«Почему вы перестали использовать сервис?»

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

👉 Ниже — основные методы, которые помогают сложить цельное представление о мотивации, барьерах и потребностях пользователя.

Методы, которые помогают понять, чего хочет пользователь

1. Интервью

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

Совет: спрашивайте не «нравится ли вам идея», а «вспомните, как вы последний раз…».

2. Аналитика

Когда применять: после запуска, чтобы понять масштаб проблемы.
Что даёт: количественные данные: что делают, где отваливаются, сколько времени тратят.
Пример: 72% пользователей бросают регистрацию на третьем шаге. Это сигнал: может, шаг перегружен или вызывает недоверие?

3. A/B-тестирование

Когда применять: когда есть гипотеза о влиянии интерфейса, текста или механики.
Что даёт: подтверждённые различия в поведении.
Пример:
Гипотеза: «Текст “Попробовать бесплатно” увеличит конверсию по сравнению с “Регистрация”».
Результат: версия с «бесплатой пробой» показывает +12% к регистрации.

Важно: Без гипотезы A/B превращается в угадайку. Чёткая цель — обязательна.

4. Смоук-тест

Когда применять: до разработки функционала, чтобы проверить интерес.
Что даёт: быстрый сигнал о востребованности идеи.
Пример: кнопка “Оформить подписку” без логики. Если кликают — начинаем разработку.

5. Дневники и наблюдение

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

6. Обратная связь и support

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

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

Как отличить мнение от потребности

  • «Мне не нравится экран регистрации» → мнение

  • «Я не понял, как начать пользоваться» → сигнал о проблеме

  • «Я не закончил регистрацию» → поведение

🎯 Задача продакта — копать глубже. За любой фразой скрывается опыт.

📌 Спросите:

  • «Почему?»

  • «Что вы хотели сделать?»

  • «Что стало неожиданным?»

  • «А если бы этого не было — что бы вы сделали?»

Комбинируй методы: сила в сочетании

Настоящее понимание появляется на пересечении данных, поведения и слов.

Что использовать Когда
Интервью Чтобы найти инсайты, сценарии, барьеры
Аналитику Чтобы подтвердить масштаб или узкие места
A/B и смоук-тесты Чтобы проверить гипотезу быстро и без полной реализации
Support и отзывы Чтобы слышать громкие боли и частые фрустрации

🔍 Пример 1:

Ситуация: Пользователи жалуются в support: «Слишком сложно начать пользоваться».
Что делаем:
— Интервью показывают, что люди путаются на экране выбора тарифа
— Аналитика подтверждает — 60% теряются именно там
— Смоук-тестируем новый упрощённый флоу — +20% конверсии

🔍 Пример 2:

Ситуация: Есть гипотеза, что пользователям важна возможность делиться результатами.
Что делаем:
— Добавляем “пустую” кнопку «Поделиться» → 25% кликают
— Интервью: “Я хотел бы показать коллеге, но не нашёл как”
— Запускаем A/B с разными вариантами кнопки → рост удержания +5%

Итоги

📌 Пользователь не обязан объяснять, чего он хочет — это задача продакта
📌 Слова важны, но поведение — честнее
📌 Комбинируйте методы: интервью + аналитика + эксперименты
📌 Слушайте не только то, что говорят, но и что не говорят
📌 Не всё, что звучит громко, важно. И не всё важное — сказано вслух.

🎯 Настоящее понимание начинается тогда, когда вы перестаёте угадывать — и начинаете смотреть, слушать и проверять.


Шаблон: фиксация сигналов и гипотез

1. Сигналы (что мы наблюдаем)

№ Цитата / поведение / наблюдение пользователя Контекст Эмоция Частота
1 «Я не понял, как начать пользоваться» Первый вход Фрустрация 3 из 5 интервью
2 60% пользователей не доходят до 2-го шага Воронка онбординга — Web-аналитика
3 «Было бы круто сохранять товары на потом» Выбор подарка Интерес / идея 2 упоминания

 

2. Интерпретация потребности

Что стоит за сигналом? Какая реальная задача / боль пользователя?
Хочет простоты на старте Нужен чёткий и понятный первый шаг
Не хватает контекста Нужно объяснить, что делает каждый элемент
Хочет возвращаться к выбору позже Нужна функция “избранное”

 

 3. Гипотеза (продуктовая формулировка)

Если мы сделаем …
То пользователь сможет …
Потому что это решит его …

Пример:

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

4. Как проверим?

Гипотеза Метод проверки Метрика успеха
Добавить онбординг A/B тест / флоу-аналитика Увеличение перехода ко 2-му шагу на 20%
Кнопка “Избранное” Смоук-тест: кнопка без функционала >25% пользователей кликают

 

5. Решение / Следующее действие

Что делать дальше? Кто отвечает? До когда?
Подготовить смоук-тест для “Избранного” Дизайнер + фронт до 10 сент
Обновить первый экран по результатам интервью Продакт + UX до конца спринта

 

Как использовать шаблон

  • После каждого интервью — фиксируйте не только цитаты, но что они значат

  • На командных созвонах — сравнивайте, какие паттерны повторяются

  • При формулировке гипотез — сразу думайте о метрике и способе проверки

На следующий урок