Управление продуктом для UX-специалистов. От дизайна интерфейсов к успешному развитию в мире продуктов — страница 23 из 40

• Оптимизация воронок может стать отличным дополнением к UX и другим способам улучшения взаимодействия, чтобы больше людей могли удовлетворить свои потребности.

• Не вся аналитика продуктов, но бóльшая ее часть фокусируется на росте.

• Рост на самом деле определяется многими различными компонентами, и все они способствуют увеличению базы пользователей, которые платят или нет. К этим компонентам относятся осведомленность, привлечение, активация (или вовлечение), удержание, рекомендации и выручка (сокращенно AAARRR).

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

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

Глава 7Проверка гипотез с помощью экспериментов

Помните, что менеджер продукта должен быть своего рода ученым? Возможно, если вы мечтаете по-крупному, иногда даже безумным ученым, но всегда опирающимся на доказательства и заботящимся о точных измерениях. Ученые изучают о предмете всё, что могут, и задаются вопросом, четкого ответа на который пока ни у кого нет. Они разрабатывают гипотезы. Это творческая работа!

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

! СВЕРХСПОСОБНОСТИ UX-ПРАКТИКОВ

ГИПОТЕЗЫ – ЭТО ПРОСТО ИДЕИ, КОТОРЫЕ МЫ ИССЛЕДУЕМ

«Создание гипотез» может звучать так, будто вы сидите и придумываете их в башне из слоновой кости или в лаборатории, но это просто замысловатый образ создания теорий и идей, которые вы можете проверить. Любое дизайн-исследование, которым вы когда-либо занимались, было способом проверки гипотез. Сценарии пользовательских исследований основаны на гипотезах, которые вы хотите исследовать. Поэтому не позволяйте научным терминам напугать вас. Вы уже всё знаете!

Экспериментирование как образ жизни

Во многих командах по продукту экспериментирование отделяют от других работ по разработке программного обеспечения (в первую очередь от написания кода и исправления ошибок) и либо сосредоточивают небольшую команду разработчиков на экспериментах (возможно, в паре с менеджером продукта, ориентированным на рост, или даже с «хакером» роста), либо проводят эксперименты циклично, например каждый третий спринт.

Но такой подход к экспериментам может оказаться упрощенным, и он почти всегда опирается на популярный метод группового тестирования (его также называют сплит-тестированием, A/B-тестированием и многовариантным тестированием).

Правда в том, что при управлении продуктом всегда приходится делать бесконечную серию «ставок», которые нужно протестировать и разыграть. Некоторые касаются запуска чего-то нового, а другие – способов улучшить что-либо (как обсуждалось в главе 5 «Продуктовый бизнес – это бизнес»). Но все они подразумевают создание рабочих гипотез о том, что происходит и что препятствует прогрессу, что даст лучшие результаты и на чем сосредоточиться дальше.

Лучше признать, что экспериментирование – это образ жизни, и оно пронизывает все ваши решения.

Создание, исправление или настройка

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

На всех этих этапах разработки экспериментирование играет важную роль.

• Оно определяет, что создавать, для какой аудитории, какие у потенциальных потребителей есть актуальные болевые точки и для какой «работы» они захотят «нанять» ваше программное обеспечение.

• Исправление ошибок не является чем-то особенно экспериментальным, но определение приоритетных среди них (потому что ошибки в некотором роде фрактальны, и вы действительно никогда не сможете исправить их все для каждого сценария на каждой платформе и устройстве) – это проверка гипотезы о том, что для вашего клиента должно работать максимально без сбоев, а что сгодится, если работает достаточно стабильно.

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

Выдвигаем гипотезы

Один мудрый человек однажды сказал: «Гипотезы – это идеи о том, почему вещи таковы, какие они есть». Для менеджера продукта гипотезы часто – это более конкретные попытки объяснить сбивающие с толку или непредсказуемые результаты, заметные в данных. Вы уже узнали об аналитике продуктов, метриках и анализе данных в главе 6 «Анализ продукта: рост, вовлечение, удержание». Помните, что менеджеры обычно постоянно думают об определенных ключевых метриках Полярной звезды, и часто заходят так далеко, что организуют ежедневную утреннюю рассылку по электронной почте или сообщение в Slack и обдумывают текущие отчеты и графики всякий раз, когда появляется время.

Одна из причин, по которой вы каждое утро смотрите на одни и те же ключевые метрики Полярной звезды, заключается в том, что так вы вовремя замечаете, когда они становятся неустойчивыми. Почему продажи упали до нуля в середине прошлой ночи? Почему сегодня количество загрузок в 4 раза превышает обычное число? Почему вы в тренде в X (Twitter)?

ИСТОРИИ ИЗ ЖИЗНИ

НАЙТИ ЯСНОСТЬ И ПОНИМАНИЕ

Когда я работал в 7 Cups, наша служба полагалась на волонтеров, обученных живому выслушиванию людей, ищущих бесплатную эмоциональную поддержку онлайн. Мы называли этих добровольцев Слушателями (Listener). В какой-то момент в нашем меню верхнего уровня появилась кнопка с надписью Become a Listener («Стать Слушателем»), и мы почувствовали, что надо улучшить ее возможности по набору добровольцев.

Дизайнер диалоговых интерфейсов в моей команде Хизер Корнелл выдвинула гипотезу: «Новые посетители нашего сайта не знают, кто такой Слушатель, не говоря уже о том, что они должны захотеть им стать». Предположение показалось довольно убедительным, но как мы могли его проверить?

Корнелл предложила нам попробовать другое название для кнопки, например Volunteer as a Listener («Стать волонтером-слушателем») или Become a Volunteer («Стать волонтером»). Оба этих варианта сработали лучше, чем первоначальный, а Volunteer as a Listener показал самые лучшие результаты. Вы все еще можете увидеть эту опцию в верхнем меню сайта 7 Cups, потому что она там была[38], когда я недавно заходил на него (рис. 7.1).

Рис. 7.1. В меню верхнего уровня сайта 7 Cups по-прежнему присутствует функция Volunteer as a Listener («Стать волонтером-слушателем»)

Гипотеза и эксперимент привели нас к осознанию того, что существует гораздо больше людей, которые ищут возможности стать волонтерами, чем желающих взять на себя роль с определенным названием в одной конкретной волонтерской организации, как видно из меню верхнего уровня по адресу 7cups.com.

Интересно то, что скромная гипотеза («люди не знали, что мы подразумеваем под „слушателем“») привела к значительному улучшению, а последующие эксперименты[39] привели нас к еще одному выводу: есть люди, которые специально ищут возможности стать волонтерами.

Когда вы пытаетесь ответить на эти вопросы, то идеи, которые приходят вам в голову в качестве объяснений, являются вашими гипотезами. Но, конечно, не все догадки одинаково хороши, поэтому гипотезы стоит сделать четкими и проверяемыми, а также общаться с коллегами, с которыми вы могли бы обсудить или набросать идеи в общих чертах и которые могут быть вашими «партнерами в обдумывании», чтобы доработать, переосмыслить или выявить последствия.

Потому что, когда у вас появится гипотеза, которая вам понравится, придется придумать один или несколько экспериментов для ее проверки.

Эксперименты и определение их приоритетности

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

Если вы отобрали гипотезу, которая, по вашему мнению, решает достаточно серьезную задачу с высоким приоритетом, то следующий шаг – провести эксперименты для проверки этой гипотезы. Отчасти это вопрос логики. Если ваша гипотеза заключается в том, что на экране входящих писем вашего приложения для электронной почты появляется слишком много рекламы и это приводит к тому, что ваш пользователь игнорирует все объявления, то для проверки этого предположения можно провести эксперимент – уменьшить количество рекламы. Если гипотеза верна, то это должно привести к увеличению вовлеченности в рекламу. Если нет, то, вероятно, здесь влияют другие факторы.

Но не все гипотезы настолько прямолинейны, чтобы предлагать очевидные эксперименты, а неудачная проверка не всегда опровергает вашу гипотезу. (Возможно также, что эксперимент не смог эффективно проверить гипотезу.) Поэтому в проведении экспериментов, которые успешно и элегантно нацеливаются на «ось» гипотезы и выявляют влияние изменений, должен присутствовать также элемент искусства или творчества.