Тест ложной двери
Fake Door Testing
Тест ложной двери (Fake Door Testing) проверяет интерес к идее до разработки. В интерфейс добавляют кнопку или пункт меню несуществующей функции и считают, сколько людей на них нажимает. После клика человек видит честное сообщение, что функции пока нет.
- Сроки
- 7–30 дней
- Респонденты
- 100+ человек
- Команда
- 1 человек
- Бюджет
- Бесплатно
- Сложность
- Лёгкий
- Популярность
- Иногда
Содержание
Когда использовать
Метод нужен, когда надо быстро понять, стоит ли строить функцию. Он измеряет действие, а не слова. Опросам доверять трудно, потому что люди не всегда знают, чего хотят. Лучше всего тест работает для отдельных функций, которые объясняет короткая подпись.
Клик говорит, что идея заинтересовала, но не объясняет почему. Не показывает он и того, понравится ли функция в использовании. Причины выясняют отдельно, например на интервью с теми, кто оставил контакт. Нужен достаточный поток людей, чтобы результат стал статистически надёжным. Если команда уже видит интерес в аналитике или опросе, ложная дверь подтверждает его действием.
От обычного A/B-теста метод отличается тем, что рабочей функции за кнопкой нет. Для проверки понятности идеи на макетах ближе тестирование концепции.
Что нужно для старта
- Гипотеза с порогом, который задан до запуска. Например, «не меньше 15 % людей, открывших меню экспорта, нажмут на “Экспорт в Excel”»
- Продукт с аудиторией, в котором можно разместить кнопку или баннер
- Возможность показать дверь части пользователей и оставить контрольную группу без неё
- Страница или окно с честным ответом на клик и предложением оставить контакт
- Аналитика, которая считает показы и нажатия
Как провести
-
Гипотеза и порог
Запишите, какая доля нажавших оправдает разработку, до запуска. Тогда результат нельзя истолковать в удобную сторону. Общего порога нет, команда решает, какой процент достаточен для её идеи.
-
Одна идея
Проверяйте одну функцию одной дверью. Идея должна объясняться короткой подписью, иначе человек не поймёт, на что нажимает.
-
Сама дверь
Кнопка выглядит как настоящий элемент интерфейса и стоит там, где человек ожидает увидеть функцию. Название берите то, под которым функция будет жить в продукте. Подпись можно сделать исследовательской, например «Нужен экспорт в PDF?». Это смягчает разочарование.
-
Аудитория
Показывайте дверь тем, кому функция действительно может пригодиться, а не всем. Возьмите ограниченную часть пользователей и оставьте контрольную группу без двери. Заранее задайте дату окончания теста.
-
Ответ на клик
Скажите прямо, что функции пока нет и вы проверяете интерес. Предложите что-то взамен, например сообщить о запуске или ответить на короткий опрос. Контакт оставлять необязательно. Нельзя вести человека в тупик или показывать пустую страницу.
-
Метрики
Считайте долю нажавших от показов, а не число кликов. Смотрите, сколько нажавших оставили контакт, сколько кликов уникальных, через какое время после показа нажали, что человек делал дальше и чем отличаются сегменты. Тест идёт, пока результат не станет статистически надёжным.
-
Решение
Сравните долю с порогом. Выше порога функцию можно проектировать или собирать из неё минимальную версию. Ниже порога идею отбрасывают или переформулируют. Тех, кто оставил контакт, зовут на интервью, чтобы понять мотивы.
Результат
Отчёт с воронкой. Сколько человек увидели дверь, нажали, оставили контакт, как это различается по сегментам и как соотносится с порогом. К нему прикладывают решение и список людей для интервью.
Типичные ошибки
-
Не сказать, что функции нет
Если человек нажал и ничего не произошло или попал на страницу, не совпадающую с обещанием, он чувствует обман. Всегда объясняйте, что происходит, и давайте возможность оставить контакт.
-
Слишком много дверей
Много ложных элементов подряд портят впечатление от продукта и доверие к нему. Один человек не должен видеть их слишком часто.
-
Дверь в критический момент
Если человек решает срочную задачу, например хочет скачать квитанцию сразу после платежа, а получает «спасибо за интерес», он раздражается.
-
Показ всем подряд
Дверь нужна тем, кому функция релевантна. Остальным она мешает и искажает результат.
-
Порог после теста
Когда критерий придумывают по итогам, любой результат можно объявить успехом.
Кто использует
Dropbox перед разработкой выпустил трёхминутное демонстрационное видео и форму записи в бета-версию. По словам основателя, лист ожидания вырос с 5 000 до 75 000 человек за ночь. Рассказ есть в статье автора The Lean Startup. Buffer вместо работающего сервиса сделал страницу с тарифами. Выбравший план видел, что сервис в разработке, и мог оставить контакт, а собранные адреса потом использовали для интервью, как описано в статье на Хабре.
Место в процессе
- Анализ продуктовой аналитикиАнализ продуктовой аналитики (product analytics) показывает, что люди делают в продукте. Какие страницы открывают, где уходят, какими функциями пользуются, а какие обходят. Данные собираются автоматически, поэтому метод отвечает на вопрос «где и сколько». Объяснить, почему так происходит, он не может.
- Опросы и анкетированиеОпросы (surveys) собирают ответы большого числа людей сразу. Они не объяснят, почему что-то происходит, но покажут, насколько это распространено и как мнения распределены по аудитории.
- A/B-тестированиеA/B-тестирование (A/B testing) показывает, какой из двух вариантов интерфейса лучше достигает заданной метрики, например конверсии или кликов. Пользователей случайно делят на группы, каждая видит свой вариант, а результаты сравнивают статистически.
- Проверка концепцииПроверка концепции (Concept Testing) показывает, как аудитория реагирует на идею продукта или функции до того, как её начали делать. Людям показывают описание, скетч, макет или лендинг и выясняют, понимают ли они идею, нужна ли она им и решает ли их задачу.
- Юзабилити-тестированиеЮзабилити-тестирование (usability testing) показывает, где люди спотыкаются о продукт. Участнику дают реалистичную задачу, например оформить заказ или найти настройку, и наблюдают, как он её выполняет. Исследователь фиксирует, где человек буксует, ошибается или теряет ориентацию.