Как улучшать продукт методом Fake Door

Быстро и без вреда пользовательскому опыту проверяем предпочтения и ожидания аудитории.

Меня зовут Александр Ревенок. Я UX-дизайнер в компании Semrush. Занимаюсь группой продуктов и решений для SEO и диджитал-агентств. В этой статье пойдет речь о методе исследования Fake Door. Мы используем его, чтобы выявлять потребности, проблемы, а также приоритизировать продуктовые планы.

Основные источники и драйверы развития продуктов в Semrush:

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

Как подходим к внедрению улучшений в продукте:

И тут мы сталкиваемся с проблемами:

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

Fake Door — это один из способов MVP-решения, симуляция набора функций для проверки отклика аудитории. Он применим для проверки практически любой продуктовой гипотезы (примеры разберем далее) и имеет простую структуру:

1. Триггер. Размещаем уловку внутри продукта, как будто фича уже готова для использования, но ничего не разрабатываем, либо разрабатываем минимальный набор функций.
2. Действие. От пользователя требуется что-то сделать, на основе чего мы понимаем актуальность потребности и можем даже выяснить детали с помощью мини-опроса.
3. Благодарность. Благодарим пользователя, сообщая, что фича еще в разработке, предлагаем стать бета-пользователем или поучаствовать в интервью.

Важное замечание: Fake Door — это не темные UX-паттерны (dark patterns), когда мы обманными методами вынуждаем пользователей неосознанно совершить покупку или на что-то подписаться.

Перейдем к разбору метода на примерах Semrush.

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

Как мы это сделали с помощью Fake Door и шагов «триггер > действие > благодарность».

Триггер. Проинформировали пользователей о выходе в скором будущем инструмента управления клиентами. Попросили добавить первого клиента для получения раннего доступа.

Действие. Нажимая на кнопку, пользователь видел модальное окно с пустой формой создания клиента (все поля обязательны, чтобы эксперимент был точнее).

Также мы просили указать, какие наиболее частые задачи решают агентства при работе со своими клиентами (чекбоксы уже опциональны).

Благодарность. При вводе и отправке данных показывали еще одно модальное окно с благодарностью, в котором предлагали стать ранним пользователем, пройти интервью и сохранить введенные по клиенту данные на предыдущем шаге (еще одно подтверждение того, что клиент ввел достоверные данные, и ему с ними важно работать).

За короткое время получили неплохие данные: около 30% открывших модальное окно заполнили форму, а более 70% заполнивших форму пожелали ранний доступ и были согласны на интервью.

Также, проанализировав вводимые данные, узнали ожидания пользователей и их рабочий процесс.

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

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

Потребность в новом инструменте подтверждались на интервью-сессиях, а также отделы технической поддержки и продаж регулярно сообщали пожелания пользователей. Но нам необходимо было сопоставить ожидания аудитории с нашим продуктовым бэклогом. Для такой задачи мы сделали Fake Door, добавив шаги с опросом.

Триггер. Анонсировали скорый выход нового инструмента именно там, где и предполагали его размещать после релиза. Рискнули конверсией, указав, что его разработка только ожидается, и мы просто набираем бета-пользователей.

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

Благодарность. При вводе и отправке данных начальное состояние экрана меняли на заполненное. Позже, собрав достаточно данных, сократили шаги до бета-пользователя: достаточно было просто нажать на кнопку “Apply for beta testing” (мини Fake Door в один клик).

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

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

Продукт, позволяющий клиентам найти агентства для SEO, SMM и других диджитал-услуг.

Была гипотеза, что пользователи не хотят искать агентства самостоятельно и воспользуются авто-подборкой.

Вместо реализации сложного динамического опроса в продукте сделали Intercom-чат, уточняя детали о проекте, бюджете и необходимых услугах.

Запуск занял минимальное время и ноль затрат команды, а при разработке даже MVP-функциональности были бы существенные затраты ресурсов.

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

Когда в продукте много таблиц, неизбежен и поиск вариантов замены на что-то более визуальное. Но нужно ли такое улучшение на самом деле? Тут может помочь Fake Door.

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

Несмотря на то что мы не получали негативных отзывов от пользователей, попавших в такие эксперименты, мы стараемся не злоупотреблять лояльностью и следуем ряду правил:
1. Мы не проводим такие эксперименты слишком часто.
2. Готовясь экспериментировать, мы следим, чтобы никакой другой подобный эксперимент не проводился где-то еще в продукте или продуктах, между которыми пользователи часто взаимодействуют.
3. Эксперимент длится недолго, иногда достаточно и пары дней, зависит от входящего трафика. Важно именно быстро подтвердить проблему или потребность.
4. При необходимости мы сегментируем аудиторию, чтобы в эксперимент попали только максимально релевантные пользователи для проверки гипотезы.

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