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

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

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

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

Александр Ревенок
UX-дизайнер в Semrush

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

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

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

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

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

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

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

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

Что такое Fake Door

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

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

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

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

Кейс 1: измеряем спрос на новый инструмент и находим альфа-пользователей

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

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

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

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

<p>Триггер. Расположили баннер с призывом создать первого клиента</p>

Триггер. Расположили баннер с призывом создать первого клиента

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

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

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

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

Благодарность. Еще детальнее сегментируем лояльных пользователей.
Благодарность. Еще детальнее сегментируем лояльных пользователей.

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

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

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

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

Кейс 2: выявляем ожидания от нового продукта онлайн-отчетности

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

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

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

Триггер. Открыли набор для бета-пользователей.
Триггер. Открыли набор для бета-пользователей.

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

Действие. Опрос состоял из двух шагов, уточняющих ожидания и предпочтения аудитории.
Действие. Опрос состоял из двух шагов, уточняющих ожидания и предпочтения аудитории.

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

<p>Благодарность. Сокращенный Fake Door в один клик: от триггера к финальному состоянию.</p>

Благодарность. Сокращенный Fake Door в один клик: от триггера к финальному состоянию.

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

Другие кейсы

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

Пример опроса Fake Door в Intercom

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

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

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

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

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

<p>Простой чат вместо модальных окон и динамических форм.</p>

Простой чат вместо модальных окон и динамических форм.

Пример тестирования дизайна

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

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

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

Почему это работает

  • Пользователь в контексте продукта и своих задач. Ему не приходится что-то додумывать, вспоминать или совершать над собой усилия, заполняя опросы, которые присылают в неподходящее время.
  • Мы не спрашиваем абстрактное «если бы...» — все очень конкретно, функции уже есть в интерфейсе, можно сымитировать любой сценарий и взаимодействие. Поэтому отклик и реакция пользователей намного точнее.

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

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

Инструкция по применению Fake Door

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

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

3232
10 комментариев

Важное замечание: Fake Door — это не темные UX-паттерныЭто оооочень близко к темным паттернам!
Добавить своего первого клиента, заполнить новую форму из 4 полей (причем дропы явно лишние на этом шаге), а потом узнать, что "не, ты никого не добавил, это мы проверяли возможную фичу" - это писдец как негативный опыт.
Многократно такое даже самые лояльные пользователи не прощают.

9
Ответить

Как я понимаю, прикол в том, чтобы показать fake door на небольшой X% юзеров. Из них Y% кликнет, и из них Z% бомбанет и они уйдут или станут меньше пользоваться.
По сути, падение прибыли на X*Y*Z% пользовательской базы можно считать бюджетом на исследование. Как по другому проверить ту же гипотезу, ну хз. Всякие опросы, как известно, очень подвержены баясам.

Иногда попасть в этот % очень неприятно. К примеру, как-то надо было провести ряд перфоманс тестов на мощном железе. AWS в нужной зоне показал наличие нужных мощных машин. А после согласования бюджета, открытия доступов, согласования с безопасниками вдруг оказалось, что очередной шаг конфигурации ведёт к сообщению, что, по факту, таких машин в этом регионе ещё не завезли, но они учтут наш спрос при очередных закупках железа.

5
Ответить

темный паттерн – это все же более коварная уловка, когда пользователю подменяют результат его действий или даже скрывают реальный итог с целью получения выгоды (скрытие подписки, согласия и так далее). Мы кратковременно смотрим на отклик указывая “coming soon”.
Риски поймать негатив есть, поэтому о многократном и длительном злоупотреблении доверием пользователей речи не идет.
На скриншоте графиков можно увидеть, что большая часть аудитории предпочла ранний доступ. Эти пользователи попросили сохранить введенные данные, чтобы продолжить работу, когда продукт будет готов.
То есть, они понимают, что сейчас еще что-то делается, но их данные не потеряются, и их не придется вводить повторно.

2
Ответить

А что в таком случае происходит с удовлетворенностью пользователей, которые все таки попали в тест?
Меня жутко бесит, когда морковку показали, но не дали. Думаю, что так у очень многих.

2
Ответить

Елизавета, мы поэтому пришли к формату "feature is coming soon" как к более прозрачному и честному по отношению к пользователям.
Мы с пользователями ведем диалог, спрашиваем: "Если вы заинтересованы, то поделитесь деталями, чтобы продукт решал именно ваши задачи".
Пользователи, которым действительно нужно решение, рады указать детали, стать бета-тестерами и пообщаться.
Пользователи, которым это не нужно, проходят мимо.
Мы делаем такие эксперименты не часто и всегда тестируем значительные изменения функциональности.

1
Ответить

Очень понравилось, что привели примеры, да еще и со скринами. Спасибо, очень исчерпывающе

Ответить