Ценность и польза продукта

Когда-то очень давно я имел удачу погрузиться в инфобизнесовые проекты. Я быстро вышел из этого, но усвоил один очень важный урок: люди в большинстве своём покупают трансформацию. Т.е. кем человек был до и кем он стал после.

Перечитывая свои конспекты книг и лекций, нашёл вот такие 8 вопросов для целевой аудитории:

1. What does your prospect HAVE in the “Before” state?
2. What does your prospect HAVE in the “After” state?

3. How does your prospect FEEL in the “Before” state?
4. How does your prospect FEEL in the “After” state?

5. What is an AVERAGE DAY like for your prospect in the “Before” state?
6. What is an AVERAGE DAY like for your prospect in the “After” state?

7. What is your prospect’s STATUS in the “Before” state?
8. What is your prospect’s STATUS in the “After” state?

Огромная полезность вопросов в том, что люди будут говорить о том, что они получили в результате использования вашего продукта. Говорят же обычно о самом важном и/или болезненном. Это можно и нужно использовать в разработке продуктовых гипотез, а как следствие и а/б тестов.

Поговорите с пользователями

Однажды один опытный product owner сказал мне: «не надо делать прям исследование, просто поговори с 3 пользователями и этого будет достаточно».

Важный момент в том, что нет необходимости понимать какая часть аудитории отреагирует хорошо или плохо. Именно это и покажет А/Б тест. Важно понять, что подобный use case присутствует и ваше изменение (гипотеза) хорошо вписывается в этот use case.

А может надо понимать какая часть аудитории отреагирует хорошо или плохо?

Вчера написал «аудитории отреагирует хорошо или плохо». Так-то оно так, но не совсем...

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

Моей первой мыслью было переделать эту страницу. Эта страница действительно была самая ужасная из всего сайта и очевидно представляла собой узкое место.

Так как это был аудит под заказ, то каждую гипотезу я старался подкреплять данными. Я проверил в Google Analytics процент «брошенных корзин». Оказалось, что только около 10-15% бросают оформление заказа.

Как потом выяснилось, это было связано с уникальностью товара. В каком-то смысле это была монополия на определённый бренд. Очевидно, что оптимизация этой страницы потеряла всякий смысл и ценность.

Получается, некоторые гипотезы могут вообще не пройти проверку. Это очень хорошо работает, когда люди на интервью / usability тестах говорят об одном, но не демонстрируют это поведение (аналитика кликов / последовательностей просмотра страниц) на сайте.

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

Потребности пользователей

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

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

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

Один из вариантов обойти это на интервью - это всегда спрашивать зачем вам надо то, что вы утверждаете вам надо.

Привет!
Скоро будет "Usability party" 🙂 Plerdy организует 10.12.2020 бесплатную онлайн конференцию о UX & CRO сайтов. Среди спикеров:
- Oleg Slyusarchuk - Head of Product Design Eleks
- Влад Сиднев - Руководитель отдела CRO Web-promo
- Denis Studennikov - Head of UX/UI Department Турум-бурум
- Igor Sokolov - Co-founder ConversionrateStore
- Андрей Чорный - CEO Plerdy
... и я тоже расскажу полезность.

Конечно ссылка на конференцию https://www.plerdy.com/ru/usability-party/ и также есть UX-игра 🙂 Можно пощупать, что такое плохое юзабилити :) https://www.plerdy.com/ru/start-ux-game/

«Корректных А/Б тестов нет, есть недоанализированные»

А/Б тестирование на малом трафике

1. Математика не особо различает мало у вас трафика или много. Если стат. значимость достигнута, то для данного эффекта трафика достаточно.

2. Это приводит нас к утверждению, что тестировать можно на любом трафике, но гипотезы должны быть разные. Чем меньше трафика, тем более значимые изменения можно измерить, тем более "крутые" гипотезы должны быть.

Что реально делать, если трафика мало?

Ситуация А. Вы никогда ранее не занимались улучшением сайта

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

2. Второй вариант. Заняться этим самому или поручить продакту / маркетологу. 100% времени это не займёт, но станет хорошим начинанием, которое вырастет во что-то значимое.

Ситуация Б. Вы уже занимались улучшениями сайта

1. Нет смысла нанимать подрядчика или специалиста. Основные ошибки уже исправлены. Нетривиальные вещи подрядчики скорее не найдут, а на 100% заниматься проектом кроме вас никто не будет.

2. Есть смысл тестировать новые направления продукта / предложения, что-то кардинально нового. Это может дать хороший рост, который можно будет увидеть в А/Б тесте. Всем остальным заниматься смысла нет, т.к. просто не будет значимости в А/Б тестах.

Сколько стоит А/Б тестирование?

Ставлю на то, что вы подумали о команде, зарплатах, платных инструментах и, возможно, о бонусах клиентам за участие в опросах. Но... есть и тёмная сторона Луны.

Тёмная сторона Луны
- 10% успешных А/Б тестов считается ОК по отрасли
- Значит 90% будут «негативны» или «не положительны»
- «Не положительны» - не хватило трафика измерить рост или падение
- Значит, что какая-то часть «никаких» тестов отрицательна, но падение не достаточно сильное, чтобы на нашем трафике это измерить

Это всё значит, что запустив 100 тестов, часть из них навредят бизнесу. Да, мы не будем их оставлять на сайте и убьём по завершении теста... Но...

Но! Пока тесты бегут, 50% трафика подвергается негативному влиянию и снижает показатели бизнеса.

p.s. для самых отчаянных есть задача со звёздочкой: умножьте это влияние на LTV.

Разработка продуктов не происходит в вакууме. Чтобы создать крутой продукт, который будет приносить пользу и клиенту, и бизнесу, нужно использовать комплексный подход. Поэтому строить ожидаемый User Experience надо с учетом трендов в индустрии, цифровых инструментов и хорошей UX-экспертизы.

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

Из полезного и интересного:
1. Дайджесты по бизнес-экосистемам: FinTech, логистика, ритейл, e-commerce.
2. Тренды в ритейле – дарксторы, роботизированные магазины и другое.
3. 5 уровней цифровизации на примере Х5 Retail Group – насколько цифровизирован русский бизнес и куда нам стремиться.
4. Запланированное устаревание вещей – почему вечную лампочку так и не изобрели.
5. Запрет на дарк паттерны – что такое дарк паттерны и почему их запрещают.
6. Разборы российских и иностранных экосистем – Сбер, Airbnb, Amazon… you name it.

Рекомендуем подписаться!
#реклама

Ваше безумие или «сколько надо трафика, чтобы провести А/Б тест?»

Все задаются этим вопросом и в сети есть куча калькуляторов, которые с радостью посчитают для вас тот самый объём трафика, только всё это... эм... иллюзия контроля.

Для расчёта объёма трафика необходимо задать два значения:
1. Базовая конверсия (это то, что у вас есть сейчас) aka baseline.
2. Рост, который вы хотите измерить aka minimum detectable effect. (MDE)

Первое вы можете посмотреть у себя в аналитике. Второе вы посмотреть не можете.

Что же вы можете? Это зависит от уровня вашей осознанности: от спрогнозировать (для любителей контроля и заблуждений) до угадать (для любителей безжалостной реальности).

Если один из двух параметров для расчёта нужного объёма трафика является просто напросто догадкой, то и результат будет уровня догадки.

Что реально делать? Считать трафик не нужно, вы его и так знаете. Формулу надо вывернуть на изнанку и просто посчитать MDE.

MDE может получится 2%, может получится 10%, или даже 50%, а то и 150%... Стоит ли запускать тест, где минимальный рост должен быть 2.5 раза чтобы математика сработала? Вот здесь и проверяется на сколько вы безумны...

Конверсия или продукт?

CRO редко трогают продукт. Часто это только оптимизация UI и уловки аля urgency & social proof. Улучшение продукта может сильно повлиять на привлечение (добавили «тортики без глютена» и привлекли новых клиентов), но CRO не диктует продукту что делать и не строит product road map.

Оптимизация UI и уловки, как правило, не дают огромного роста. Люди всё же покупают продукт, а не это вот всё...

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

Хорошо, не получилось добавить в тортики глютен, но:
- давайте продавать не торты по 0.5 кг / 1кг, а нарежем мелкими кусками и назовём это пироженки
- давайте продадим пироженки в кофейни
- давайте нарежем торт в форме сердца, положим в красную короку и напишем «для пар»
- а пироженки нарежем в виде животных и напишем «детские»
- а у нас точно только один вариант торта делается? несколько? о, а давайте бахнем «ассорти»...

Улучшайте продукт, не трогая продукт... А двигать кнопки каждый может...

Как убить время и ресурсы на «fake door» тесты

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

Надо быстро проверить на сколько это нужно. Делаем крыльцо и фальшивую дверь, а потом считаем сколько людей пытались через неё войти. Ура!

Фигня, ура... На практике fake door тест - это новая ссылка, кнопка, баннер... Задача посчитать сколько людей кликнули, т.к. после клика ничего не работает.

Почему я уверен, что это фигня?
- вы получили CTR X% - это хорошо или плохо?
- как CTR X% отвечает на вопрос «а покупать будут?»

А самое важное что? Верно - принятие решения: будем продолжать или закроем инициативу? О принятии решений в следующий раз...

Как оценивать «fake door» тесты?

Результатом теста является CTR fake ссылки или кнопки, что мы там разместили. От этого и будем отталкиваться.

Получается наш вопрос «Будем продолжать или закроем инициативу?» Вопрос трансформируется в:
1. «CTR является достаточным, чтобы целевая метрика полноценного теста достигла стат значимости?»
2. «Рост целевого показателя является достаточным, чтобы полноценный тест имел смысл?»

Что делать с вопросами?
1. Первое - это достаточно простая задача аналитику покрутить воронку и посчитать MDE.
2. Второе - это менеджерская задача по оценке стоимости полноценного теста и сравнению с ожидаемой выгодой.

И чуть следующий уровень...
1. По хорошему, MDE надо посчитать даже до fake door теста и даже высчитать минимальный CTR, который надо достичь, и задать себе вопрос «а имеет ли fake door тест смысл?». Очевидно, что зависит от ресурсов. Если много разработчиков и нет аналитика, то проще протестировать...

2. Выгода может быть больше цены тестирования, но сравните ожидаемую выгоду с необходимым ростом, заложенным в ваш бизнес план и спросите себя «а не фигнёй ли мы собираемся заняться?»

​​Лучший пример false-positive и false-negative, что я когда-либо видел :)

Идея vs Гипотеза

Самая частая проблема, которую приходится встречать среди junior/middle специалистов - это непонимание отличия между идеей и гипотезой.

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

Пример 🍻
Идея - «А давайте начнём пить пиво уже сейчас?»
Гипотезы - «Если мы сейчас начнём на пиво, то фиг мы запустим этот А/Б тест до 6 вечера»

Пример 2 🍀
Идея - «А давайте все идеи формулировать как гипотезы?»
Гипотезы - «Если мы будем все идеи формулировать как гипотезы, то это значительно улучшит качество запускаемых тестов и рост целевых показателей будет больше»

И шо?
- идеи как правило звучат классно и интригующе, хочется попробовать
- гипотезы звучат более реалистично и приводят к вопросу «а надо ли нам это проверять?»

«Продакт придумывает гипотезы»

Можно заменить продакт на CRO или на маркетолога, это всё не важно. Важно, что ожидаем самые лучшие и мощные гипотезы от одного (единственного) человека.

Это ошибка. И встречаю я её очень часто. Почти все консультации, почти вся помощь в найме, почти все собеседования...

Почему это ошибка?
1. Над продуктом / проектом работает команда. Если только один человек может генерировать самые сильные гипотезы, то вопрос в квалификации продуктового дизайнера, аналитиков и исследователей. Допустим, что тоже крайне странно, разработчики не будут генерировать гипотезы.

2. Если мы ожидаем, что один человек магическим образом «знает», какая гипотеза лучше и надёжнее, то зачем нам А/Б тест? Просто берём и внедряем... Стрёмно, нет? Мне стрёмно :)

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

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

В общем всё было известно давно до нас, никаких переизобретений велосипедов: «Одна голова хорошо, а две — лучше!»

Лучший инструмент для А/Б тестов и знание математики

У меня есть два тезиса, за которые меня время от времени пытаются гнобить:
1. Если вы не знаете какой инструмент выбрать, то выбирайте любой. А это скорее всего Google Optimize.
2. Вам не надо знать подкапотную математику А/Б тестирования. Смотрите на сообщения инструмента «Выиграл / Проиграл»

Почему же я так считаю?

1. Если вы не знаете какой инструмент выбрать, то скорее всего у вас нет или очень мало опыта в А/Б тестировании. Чтобы получить тот самый опыт, важно начать как можно быстрее.
2. Если вы не знаете какой инструмент выбрать, то это означает отсутствие требований к инструменту. Были бы реальные требования, простое сравнение функционала быстро бы решило вопрос. А если нет требований, значит подойдёт любое.
3. Знание подкапотной математики помогут, если вы будете писать свой инструмент с нуля. В других случаях - это практически бесполезно: вы не можете изменить алгоритм(ы) Google Optimize и/или других инструментов.

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

Запускайте эксперименты, о победе которых вам будет сообщать бухгалтерия, а не система аналитики.

С вашей гипотезой точно что-то не так

Вспомните последний а/б тест, который вы запускали. Какова была ваша цель? Проверить гипотезу?

То есть вы проверяли, что вариант Б в чём-то (конкретная метрика) лучше варианта А? Угадал?

С точки зрения проверки гипотезы это верно. Но с точки зрения бизнеса это верно лишь частично.

На сколько бизнес должен вырасти? На 5%, 50%, 2х, 5х, 10х?

Получается, что вариант Б не просто должен быть лучше варианта А, а ещё лучше на столько, чтобы обеспечить необходимый рост. Или по крайней мере сделать значимый вклад в такой рост, верно?

С такой формулировкой часть бэклога моментально теряет смысл. Все исследования, которые вы проводите начинают играть другими красками. Да и MDE в 30% уже не выглядит как нечто из области фантастики.

Дизайн экспериментов

За первые семь месяцев этого года мы с командой запустили 74 продуктовых эксперимента разной степени сложности. Это почти 2.5 эксперимента в неделю. Очень хороший темп я считаю. Главное для нас, и для меня как для продакта в частности, не спотыкаться, удерживая такой темп.

Дизайн эксперимента - критическая часть. Плохой дизайн эксперимента приводит к двум очень дорогим ошибкам:
1. Результаты не достоверны и не могут быть засчитаны, потому что ошиблись. То есть мы тут ждали два месяца результата, а его нет. Надо исправлять ошибку, перезапускать и ждать ещё.
2. Значимые результаты для конкретной гипотезы получить в принципе не получится. Значит вся разработка и время ожидания были потрачены впустую.

К сожалению, подавляющее большинство таких ошибок мы находим на этапе анализа экспериментов. У нас даже есть такая шутка «Корректных А/Б тестов нет, есть недоанализированные». От того у нас и ретроспективы, и разного рода сессии «как избежать».

Делиться опытом, давать практику и рассказывать детально о том, как делать дизайн экспериментов максимально «правильно», я буду на курсе «A/B testing». Курс для тех, кто хочет качественно запускать A/B тесты и анализировать их результаты для собственного продукта.

P.s. если есть вопросы по курсы, можете написать лично мне, с радостью расскажу и подскажу подойдёт ли это вам.

Почему я не люблю следить за конкурентами

1. Мы не знаем, что работает (приносит пользу), а что нет. Мы не знаем на сколько та или иная фича или продукт работает.
2. Мы не знаем, что было причиной разработки фичи. Вполне возможно это вообще антревольт.
3. Мы не знаем, это тестируется или финальный релиз. Очень даже вероятно, что фича будет удалена в скором времени.

Но я всё же смотрю конкурентов. Для этого у меня должна быть задача, которую я хочу решить. Тогда изучение конкурентов из "бессмысленного шатания" превращается в целевое исследование.