Мы все почаще перебегаем от проектирования по требованиям заказчика к построению работы с упором на продуктовые догадки. Обстоятельств этому несколько. С одной стороны, от нас ждут внедрение новейших функций, поэтому что конкурентность вырастает, мир движется резвее, а его изменчивость велика. С иной стороны, потребностей у юзеров больше.
Дмитрий Подлужный, управляющий направления проектирования интерфейсов Agima, ведает, как работать с догадками и научиться их формулировать.
Шаблон для формулирования гипотез: 5 пт, чтоб оформить идею
Дмитрий Подлужный
От требований к догадкам
Эволюция действий разработки программных товаров привела к смене подходов. Старенькые модели с огромным объемом документирования оказались не адаптированы к современности. Заместо этого пришли способы, связанные с непрерывной разработкой и осознанием того, что системы должны развиваться и изменяться. Догадки стали неплохим инвентарем, чтоб формулировать задачки к изменениям.
Если требования нуждаются в реализации, то догадки сначала нуждаются в проверке. Но перед сиим их нужно сконструировать. А это время от времени не так просто, как хотелось бы.
О значимости формулировок
С одной стороны, догадку можно сконструировать как угодно: нет правил и законов, которые воспретили бы нам хоть какой подход. Здравый смысл дает подсказку, что отлично бы ее сконструировать понятно, чтоб остальные люди сообразили ее смысл. Но я вспоминаю ТРИЗ (теорию решения изобретательских задач), где весьма принципиальное пространство уделяется качеству постановки задачки, поэтому что эффективность решения очень зависит от формулировки.
Мы считаем, что чем лучше сформулирована догадка, тем результативнее будет ее проверка. Под результатом понимается не только лишь проверка самой догадки, да и те вероятные инсайты, которые можно собрать по мере проверки. Для формализации и упрощения работы над созданием гипотез мы выделили последующие вопросцы, отвечать на которые можно поочередно.
Из что состоит Product Hypothesis Canvas
1. Мы полагаем, что…
Тут мы описываем то, что планируем создать.
2. Для (кого)…
В этом блоке определяем мотивированную аудиторию и, если нужно, даем оценку толики схожей аудитории в нашем проекте.
Это принципиальный шаг, поэтому что он дозволяет позже ранжировать догадки по степени их полезности для проекта. Участники команды могут весьма просто увлечься увлекательной мыслью и запамятовать, что она будет полезна в единичных вариантах.
Если создатель не в состоянии найти, для кого он определяет догадку, то высока возможность, что тут идет расчет на случайность.
Подобно тому как некие игроки в пул поначалу наносят мощный удар в надежде, что чего-нибудть да закатится. Так и продуктовые менеджеры и дизайнеры генерят догадки без привязки к юзерам, в надежде, что чего-нибудть да сыграет. С таковыми догадками нужно быть аккуратными, может быть, стоит издержать больше времени, чтоб их обмыслить детальнее.
3. Чтоб достигнуть…
Принципиально найти, какой итог мы ожидаем от опыта. Лучше, чтоб он выражался в чем либо определенном. Не нужно писать: «Обязано стать лучше…» Необходимо сконструировать свои ожидания так: «Сделать лучше [продукт] на 5%…»
Зависимо от догадки мы можем иметь различные ожидаемые результаты в короткосрочной и длительной перспективе. Почти все предпочитают концентрироваться на короткосрочных результатах и не принимать в работу догадки, направленные на длительные цели. Но нам при разработке гипотез необходимо осознавать, сколько времени займет ее проверка: один денек, недельку, месяц либо еще более. Зависимо от этого мы позже можем планировать бэклог проведения опыта.
4. Как измерим
Возможность измеримости результата — главный параметр проверки продуктовых гипотез. И если ранее мы обрисовали, что мы будем определять, то тут описываем, как и при помощи каких инструментов мы это создадим.
Какие сигналы будут указывать на то, что сделанная нами возможность эффективна? Какие главные характеристики (высококачественные либо количественные) мы будем определять, чтоб предоставить подтверждения того, что наш опыт был успешен?
5. Воздействие (положительное либо отрицательное)
Этот блок введен, чтоб мы могли размышлять о догадке обширнее, чем лишь о одной задачке. Его необязательно заполнять.
Бывают случаи, что внедрение 1-го функционала негативно влияет на остальные характеристики в системе. К примеру, мы внедряем на главную страничку веб-сайта огромную увлекательную презентацию, которая обязана повысить вовлеченность, но при всем этом презентация влияет на скорость загрузки странички, что наращивает количество отказов и может, напротив, понизить глубину просмотра.
В этом случае повышение количества отказов быть может не соединено с самим функционалом, а лишь с тем, что он большенный по размеру и безуспешно имплементирован в главную страничку.
Так смотрится наш шаблон для формулирования гипотез:
Его можно скачать в PNG либо в PDF. Здесь есть онлайн-шаблон на Miro.
Product Hypothesis Canvas поможет для вас лучше работать с догадками. Принципиально осознавать, что канвас не решает задачку сам по для себя, он лишь дозволяет сосредоточиться на решаемой задачке и повысить эффективность решения.
Как достигнуть максимума
Помните: чем поточнее ваша догадка, тем наилучший итог она даст.
Не запамятовывайте, для кого вы тестируете догадку.
Конкретизируйте ожидаемый итог.
Не запамятовывайте про длительные цели.
Прокрутите в голове, не даст ли внедрение вашей догадки в продукт плохой результат.
Источник: