Знакомая история. Команда три месяца делала новую функцию. На юзабилити-тесте все восемь респондентов прошли сценарий, никто не запутался, двое даже сказали «удобно». Релиз, дашборд, неделя ожидания. Функцией пользуется меньше процента аудитории, и график не растёт.

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

Что проверяет юзабилити-тест

На тесте мы даём человеку задачу: «Представьте, что вам нужно сделать X. Попробуйте». Он садится, концентрируется и делает. Тест честно отвечает на вопрос, может ли пользователь пройти сценарий.

В проде вопросов больше. Заметит ли человек функцию среди всего остального? Возникнет ли у него эта задача в реальной жизни? Вспомнит ли он про функцию в нужный момент? Окажется ли она лучше того, как он справляется сейчас? На тесте ответы на всё это заданы условием задачи. Поэтому хороший результат теста говорит только о том, что интерфейс не мешает.

Причина первая: функцию не находят

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

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

Причина вторая: у человека нет этой задачи

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

Здесь помогает разговор про прошлый опыт вместо гипотетического. Вопрос «когда в последний раз у вас была такая ситуация и что вы делали» даёт гораздо больше правды, чем «воспользовались бы вы такой функцией». Подробнее о таких интервью я писала в статье про Deep Discovery и JTBD.

Причина третья: старый способ достаточно хорош

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

Если выигрыш небольшой, человек не станет переучиваться. Полезно заранее спросить: чем мы лучше того, что пользователь делает сейчас, и насколько? «Немного удобнее» обычно не хватает, чтобы сменить привычку.

Причина четвёртая: мы неправильно считаем

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

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

Как разобраться, если уже зарелизили

Я бы разложила путь пользователя на три шага и посмотрела, где теряются люди:

  • увидели точку входа;
  • попробовали хотя бы раз;
  • вернулись второй раз.

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

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

Как не попадать в это до релиза

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

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

Больше разборов про продуктовое мышление и реальные кейсы — в моём телеграм-канале.