Как составить продуктовую гипотезу

Научитесь: Профессия UX/UI-дизайнер
Узнать больше

В этом лонгриде вы узнаете:

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

Продуктовая гипотеза — это предположение или догадка, как будет меняться продукт в зависимости от дальнейших действий.

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

Но как вы поймёте, что эта функция действительно нужна людям? Как определите, что она даст рост вашему продукту? Как измерите эффективность? Первое, что надо сделать, — сформулировать гипотезу. А далее ее проверить через эксперимент.

Или другая ситуация. Вы хотите выпустить на рынок новый продукт. Но есть много причин, почему он может не взлететь. Самая популярная — продукт просто не нужен рынку. Чтобы не тратить бюджет, продуктовые команды проверяют востребованность нового продукта ещё до написания кода, и для такой проверки тоже нужна гипотеза.

Для чего нужна продуктовая гипотеза?

Четко сформулированная гипотеза помогает структурировать процесс продуктовой разработки. Вы не просто говорите: “А давай добавим эту функция, мне кажется она понравится нашим пользователям”. Вы формулируете гипотезу и дальше проводите эксперимент и делаете вывод, исходя из результатов.

Как сформулировать гипотезу?

Гипотеза должна быть максимально четкой. Чем конкретнее гипотеза, тем результативнее будет её проверка.

Чтобы упростить создание гипотез, нужно ответить на несколько вопросов:

Формул формулирование гипотез много. Предлагаю использовать универсальную:

«Если я <описать изменение>, то это улучшит пользовательский опыт <сегмент пользователей> и <метрика> увеличится на X% за период Y».

Как видно из формулы, у правильно сформулированной гипотезы есть пять компонентов:

Вернемся к доставке цветов и шоколада.

Если я <предложу продуктовой команде добавить фичу шоколад к цветам>, то это улучшит пользовательский опыт <мужчин, у которых есть 2-я половинка и которые хотят порадовать свою женщину> и <выручка> увеличится на 15% за 3 месяца.

Виды продуктовых гипотез.

Верхнеуровнево гипотезы можно разделить на:

Детально, на гипотезы:

Какая польза от гипотез?

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

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

О том, как можно протестировать гипотезу, вы узнаете в следующем лонгриде!

Как мы работаем над продуктовыми гипотезами

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

В сегодняшнем материале UX-проектировщик Андрей Журавлёв расскажет о работе с продуктовыми гипотезами — принципиально важном этапе создания продукта. Мы подготовили компактный фреймворк, который позволит глубже погрузиться в тему и фундаментально подойти к процессу определения приоритетов той функциональности, которую вы будете внедрять.

Почему мы об этом говорим

Любой интегратор рано или поздно приходит к разработке собственных продуктов. Это — своего рода эволюционное изменение деятельности, когда организация дополняет привычные направления новыми. Как только мы накопили существенный опыт в проектировании и запуске CRM-систем для клиентов, подобные перемены начались и у нас. Подробнее об этом мы поговорим в одном из следующих материалов, а пока сфокусируем внимание на продуктовых гипотезах и работе с ними.

Генерация концепций подразумевает поиск оптимальных продуктовых решений. Для этого необходимо исследовать рынок, извлечь ценную информацию в ходе общения с потенциальными пользователями и задать правильные вопросы. В целом эксперты в области продуктового проектирования сходятся во мнении, что формулировать гипотезы можно в свободном формате. Главное, чтобы они были прозрачны для всех участников процесса и строились на фактах, полученных в ходе изучения рынка. В то же время важно помнить, что качество разрабатываемого решения сильно зависит от формулировок, поэтому имеет смысл опираться на лучше практики, определённые в Lean UX и даже ТРИЗ.

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

Компактный фреймворк

Подход команды T1 CRM состоит из нескольких этапов, каждый из которых представляет собой набор проверенных приемов и практик. От анализа существующих проблем и сложностей на стороне пользователей до оценки возможных решений.

Далее — расскажем о каждом из промежуточных шагов.

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

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

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

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

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

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

Если мы сами не можем объяснить проблему, возникает вопрос: существует ли она на практике или в конкретном случае речь идет о чем-то ином.

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

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

Решение. Обычно наши решения на 90% состоят из проработанных пользовательских сценариев в виде макетов и кликабельных прототипов, однако здесь есть нюансы. В частности, создание интерфейса для какой-либо функции, инициированное [КОА1] бизнесом или владельцем проекта, проработанное аналитиками и разработчиками, отличается от работы над гипотезой. Это — два принципиально разных процесса.

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

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

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

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

Презентация. Мы обсуждаем гипотезы и решения каждый месяц. На встречах кроме дизайнеров присутствуют руководители проекта и представители R&D-команды, с которыми мы выполняем общие и пересекающиеся функции, направленные на стратегическое развитие продукта и поиск точек роста. Процесс напоминает защиту проекта, когда выступающий кратко описывает проблему и свое видение решения.

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

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

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

Для этого мы проводим «коридорные» usability-тестирования, пользовательские интервью, клик-тесты и прочие виды качественных и количественных исследований. У нас в T1 есть отличная возможность проводить исследования прямо внутри группы компаний, большинство из которых, так или иначе, пользуется CRM-системами.

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

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

Итог

Дедлайны и постоянные обязательства перед клиентами могут дать нам повод проигнорировать этапы начального проектирования и исследования продукта. Но не стоит поддаваться соблазну. Разница между хорошими и плохими продуктами заключается не столько в качестве идеи, сколько в продуманности ее реализации. А высокий уровень usability позволяет нам выстраивать с пользователями доверительные и долгосрочные отношения, решать проблемы и задачи клиентов. Поэтому наша цель — добиться наилучшего результата на каждом из этапов разработки сервиса.

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

• «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели» (Эрик Рис)

• «Четыре шага к озарению. Стратегии создания успешных стартапов» (Стив Бланк)

• «Jobs to be Done: Theory to Practice» (Anthony W. Ulwick)

• «Дизайн пользовательского опыта. Как создать продукт, который ждут» (Джон Уэлен)

• «Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?» (Роб Фитцпатрик)

• «Как создать продукт, который купят. Метод Lean Customer Development» (Синди Альварес)

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

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

От требований к гипотезам

Эволюция процессов разработки программных продуктов привела к смене подходов. Старые модели с большим объемом документирования оказались не приспособлены к современности. Вместо этого пришли методы, связанные с непрерывной разработкой и пониманием того, что системы должны развиваться и меняться. Гипотезы стали хорошим инструментом, чтобы формулировать задачи к изменениям. 

О важности формулировок

С одной стороны, гипотезу можно сформулировать как угодно: нет правил и законов, которые запретили бы нам любой подход. Здравый смысл подсказывает, что хорошо бы ее сформулировать понятно, чтобы другие люди поняли ее смысл. Но я вспоминаю ТРИЗ (теорию решения изобретательских задач), где очень важное место уделяется качеству постановки задачи, потому что эффективность решения сильно зависит от формулировки. 

Из чего состоит Product Hypothesis Canvas

1. Мы полагаем, что…

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

3. Чтобы добиться… 
Важно определить, какой результат мы ожидаем от эксперимента. Желательно, чтобы он выражался в чем-то конкретном. Не надо писать: «Должно стать лучше…» Нужно сформулировать свои ожидания так: «Улучшить [продукт] на 5%…»

Этот блок введен, чтобы мы могли размышлять о гипотезе шире, чем только об одной задаче. Его необязательно заполнять. 

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

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

Его можно скачать в PNG или в PDF. Тут есть онлайн-шаблон на Miro.

Как достичь максимума

1. Помните: чем точнее ваша гипотеза, тем лучший результат она даст.
2. Не забывайте, для кого вы тестируете гипотезу.
3. Конкретизируйте ожидаемый результат.
4. Не забывайте про долгосрочные цели.

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

Фото на обложке: Shutterstock/Washdog
Изображение в тексте предоставлено автором