Как проверять продуктовые гипотезы без прототипов: 3 кейса от UX-исследователя Авито
Привет! Меня зовут Анастасия Хапалова, я работаю UX-исследователем в кластере доверия и безопасности Авито. Мы с командой работаем над тем, чтобы пользователи доверяли друг другу и нашему сервису, и часто придумываем новые продукты, которые нужно тестировать.
В статье расскажу о трёх ситуациях, когда мы успешно провели тесты без прототипов. Материал будет полезен всем, кто создаёт продукты и проверяет гипотезы: например, исследователям, разработчикам и дизайнерам.
Предисловие: в каких случаях прототип — не лучшее решение для тестов
Стандартный путь разработки продукта выглядит примерно так: исследуем → формулируем гипотезу → разрабатываем прототип → проводим тесты и собираем данные → анализируем их → выкатываем продукт или его новую версию.
Но стандартный путь — не всегда самый эффективный. Бывают ситуации, когда тестирование прототипа растягивает time to market продукта, не приносит важных данных или просто слишком дорого обходится бизнесу. Вот несколько примеров:
❌ Хотим проверить сразу несколько сложных гипотез. Если будем делать прототипы всех идей — потратим много времени на отрисовку и проверку гипотез, поэтому сильно увеличим time to market продукта.
❌ Хотим протестировать паттерн, который сложно перенести в прототипы. Некоторые идеи трудно проверить, потому что у прототипов есть технические ограничения. А если тестировать грубую версию продукта, мы не соберём нужные данные и не узнаем, всё ли понятно пользователям.
❌ Хотим оценить реакцию пользователей, а не удобство интерфейса. Например, иногда нам нужно добавить простые сценарии, которые вводят в продукт ограничения. В этом случае прототип может быть неэффективным: нам не нужно проверять, как пользователи проходят простые сценарии, а важно понять их реакцию на изменения.
❌ Хотим протестировать небольшое изменение. Например, выкатываем новый текст без изменений в дизайне. В этом случае отрисовывать новый прототип может быть избыточно.
Ниже я расскажу про три теста гипотез, в которых мы обошлись без прототипов. Объясню, какую альтернативу мы выбрали и почему она оказалась удачной.
1. Взяли стандартное рыночное решение, чтобы протестировать отзывы в Работе
В прошлом году мы с командой запускали новый продукт — отзывы и рейтинги в Авито Работе. Мы хотели, чтобы сотрудники оставляли обратную связь о работодателях, а соискатели могли учесть эти отзывы, когда смотрят вакансии.
Мы предположили, что нужно обобщать информацию из отзывов и сразу показывать соискателям всё самое важное для принятия решения. Например, задерживает ли работодатель зарплату, есть ли у него штрафы и совпадает ли зарплата с тем, что указано в вакансии.
Но мы не были уверены в том, что это действительно нужно и не хотели тратить время на подготовку разных вариантов дизайна, пока не узнаем реакцию пользователей на идею. Поэтому на этом этапе обошлись без прототипов и протестировали стандартное решение, которое уже используют другие компании на рынке.
Почему не делали прототип:
- Не были уверены, нужна ли вообще пользователям идея с выводом обобщённых тезисов из отзывов.
- Не могли определиться, что именно будем тестировать — вариантов вывода данных было очень много.
Что использовали вместо него. Мы решили проверить на пользователях стандартное визуальное решение — для примера взяли интерфейс другой площадки.
Там была механика, похожая на то, что планировали сделать мы. Сотрудники оставляют на сайте обратную связь о компаниях, и вверху страницы с отзывами отображаются самые важные характеристики работодателей. Например, там видно, как сотрудники оценивают руководство, зарплату и условия труда.
Важно: своё визуальное решение мы тестировали на прототипах
Когда проверка гипотезы показала, что пользователи хорошо реагируют на идею, мы приступили к проработке своей визуализации. Её уже тестировали на прототипах — и не один раз.
Какой профит получили:
- Собрали обратную связь от пользователей на нововведение в продукте.
- Проверили, понятны ли блоки для соискателей.
- Не тратили ресурс дизайнера.
2. Использовали tree testing, чтобы проверить тексты для формы сбора отзывов в Недвижимости
Отзывы уже давно работают в Авито Товарах, поэтому решения из этой вертикали мы адаптируем и для других — например, для Авито Недвижимости.
Чтобы оставить отзыв, пользователю нужно заполнить форму. Опросник в Товарах выглядел вот так:
Дизайн и логика формы в Недвижимости не менялись, но нужно было протестировать новый текст. Мы проанализировали, понятны ли новые вопросы и не провоцируют ли они ошибки — от этого зависело качество отзывов. Во время тестов обошлись без прототипов, и в итоге форма сбора отзывов выглядит вот так:
Почему не делали прототип. Форма простая, мы уже тестировали её раньше и знаем, как она работает. Поэтому мы хотели потратить как можно меньше ресурсов.
Что использовали вместо него. Для решения этой задачи выбрали tree testing — метод тестирования информационной архитектуры сайта. Такие исследования помогают структурировать контент, чтобы пользователи эффективно взаимодействовали с разными разделами и быстрее решали задачи.
Например, у нас есть интернет-магазин продуктов. Можно нарисовать схему разделов сайта с разными продуктами и задать пользователю вопрос: «где бы вы стали искать сгущёнку?» Это и есть tree testing: если человек правильно выберет категорию, значит, на сайте логичная разбивка по разделам. Такой метод подойдёт и для того, чтобы проверить, насколько удачные формулировки использованы в опросе.
Чтобы провести tree testing, можно использовать разные инструменты, мы взяли программу Optimal Workshop. Набросали там простую форму с нашими формулировками.
Затем запустили тестирование. Просили респондентов поставить себя на место людей, которые оставляют отзывы, и указать, какой из ответов они бы выбрали в разных ситуациях:
После мы собрали и проанализировали данные. В Optimal Workshop это особенно удобно: программа автоматически подсчитывает, сколько процентов людей справились или не справились с заданиями и показывает ошибки, которые допустили респонденты.
После первой итерации привлекли редактора, чтобы доработать формулировки и запустили ещё один тест. Так получилось довести текст формы до такого состояния, что он понятен абсолютному большинству респондентов.
Какой профит получили:
- Запустили две итерации тестов на большую аудиторию и смогли количественно проверить гипотезы.
- Убедились, что наши формулировки понятны большинству респондентов.
- Не тратили ресурс дизайнеров и разработчиков.
3. Подготовили текстовое описание, чтобы протестировать идею нового продукта со множеством сценариев
Недавно мы начали запускать большой продукт со множеством разных сценариев. Сейчас он на этапе разработки, и я не смогу делиться подробностями, поэтому будем рассматривать гипотетический пример.
Представим, что Авито запускает новый тариф. Это продукт со сложной внутренней логикой и большим количеством пользовательских сценариев: выбор, покупка, настройка. Чтобы протестировать подобную идею, мы обошлись без прототипов — это было бы просто неэффективно. Сейчас объясню, почему.
Почему не делали прототип:
- Чтобы пользователи понимали, что это за продукт и как им пользоваться, нужно проделать огромную работу: заранее продумать все сценарии, логику и сделать детализированный прототип.
- Ошибка обошлась бы нам очень дорого, если после отрисовки прототипа мы бы поняли, что глобально ошиблись на первых этапах разработки гипотезы.
Что использовали вместо него. Мы описали концепцию продукта текстом и собрали мнения пользователей.
В подробном описании мы рассказали, что это за продукт, зачем он нужен и как работает. Затем дали респондентам прочитать текст и попросили ответить на вопросы. Например, мы спрашивали: «как вы думаете, что это за продукт?», «как это будет работать?», «как вы оцениваете эту концепцию?».
На основе ответов респондентов мы сделали выводы о том, закрывает ли продукт их потребности, есть ли барьеры для его использования, нужен ли он людям.
Какой профит получили:
- Собрали обратную связь не по отдельным сценариям, а по продукту в целом.
- Узнали, что некоторые сценарии не нужны пользователям и отказались от них.
- Не тратили ресурс дизайнера и ускорили процесс запуска продукта.
Кратко: что не так с прототипами и что можно использовать вместо них
👉 UX-тест прототипа — это отличный способ проверить гипотезу, но он подходит не под каждую задачу.
👉 Помимо прототипов, есть альтернативные способы проверить интерфейсные гипотезы. Например, можно взять стандартное рыночное решение, провести тест интерфейса без дизайна или показать пользователям текстовое описание продукта.
👉 Выбирать разные методы тестирования гипотез может быть выгоднее для бизнеса, чем всегда идти по стандартному пути.
👉 Иногда альтернативные методы тестирования могут помочь собрать больше информации от пользователей, чем стандартные тесты с прототипами.