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

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

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

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

• Годовая стратегия, где запланированы большие части продукта, новые функции, увеличение определенных метрик.
• Квартальный план — более детальная карта части стратегии.
• Обратная связь от пользователей, регулярно поступающая от специалистов поддержки и отдела продаж.
• Маркетинговые исследования: интервью, buyer persona, оптимизация воронки привлечения.
• UX-исследования и аналитика: интервью-сессии, UX-тестирование, количественный анализ поведения пользователей.
• Бэклог продуктовых задач от владельцев продуктов (PO) — в основном с новыми фичами и экспериментами.
• Дизайн-задачи: эстетика, юзабилити, оптимизация пользовательского пути.
• Предложения от коллег: каждый специалист, исходя из своего понимания слабых мест продукта, предлагает, что улучшить.

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

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

• Анализируем решения конкурентов.
• Общаемся с пользователями, выясняем, как они решают задачи сейчас и чего им не хватает.
• Тестируем решения.
• Учитываем предыдущий опыт и best practices, UX-паттерны.
• Большие задачи декомпозируем на более мелкие, двигаясь короткими MVP-релизами.

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

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

Поэтому мы используем метод 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. При необходимости мы сегментируем аудиторию, чтобы в эксперимент попали только максимально релевантные пользователи для проверки гипотезы.

1. Определить цель
   На какие вопросы или гипотезы хочется получить ответы?
   
2. Продумать охват
   На скольких пользователях будет достаточно понять исход эксперимента? На каких сегментах пользователей можно получить максимально точные результаты (новые, платные, мобильные, по региону)?
   
3. Ограничить по времени
   Сколько времени нужно на исследование? Плохо, если пользователи постоянно будут натыкаться на неработающие инструменты.
   
4. Сделать просто и недорого
   Помним про три составляющие «триггер > действие > благодарность», но также заботимся о том, чтобы эксперимент был простым.
   
5. Собрать больше данных (опционально)
   Если это уместно, после действия пользователя попросить его оставить отзыв, ответить на вопрос, почему ему это интересно, спросить, готов ли он к интервью, предложить оставить почту для связи.
   

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