Как мы работаем над продуктовыми гипотезами
Проектирование любого ИТ-продукта включает в себя множество шагов: от идеи и концепции до разработки и передачи в эксплуатацию. На каждом этапе необходимо искать наилучшие решения, анализировать наработки коллег, развивать собственное видение ситуации и изучать потребности пользователей.
В сегодняшнем материале мы обобщили опыт работы над одним из участков продуктовой разработки. Речь идет о формировании и проверке гипотез. Мы подготовили компактный фреймворк, который позволит глубже погрузиться в проектирование продукта и фундаментально подойти к процессу определения приоритетов той функциональности, которую вы будете проектировать и внедрять.
/ Unsplash.com / Sascha Bosshard
Почему мы об этом говорим
Любой интегратор рано или поздно приходит к разработке собственных продуктов. Это — своего рода эволюционное изменение деятельности, когда организация дополняет привычные направления новыми. Как только мы накопили существенный опыт в проектировании и запуске CRM-систем для клиентов, подобные перемены начались и у нас. Подробнее об этом мы поговорим в одном из следующих материалов, а пока сфокусируем внимание на продуктовых гипотезах и работе с ними.
Генерация концепций подразумевает поиск оптимальных продуктовых решений. Для этого необходимо исследовать рынок, извлечь ценную информацию в ходе общения с потенциальными пользователями и задать правильные вопросы. В целом эксперты в области продуктового проектирования сходятся во мнении, что формулировать гипотезы можно в свободном формате. Главное, чтобы они были прозрачны для всех участников процесса и строились на фактах, полученных в ходе изучения рынка. В то же время важно помнить, что качество разрабатываемого решения сильно зависит от формулировок, поэтому имеет смысл опираться на лучше практики, определённые в Lean UX и даже ТРИЗ.
В любом случае многие компании упускают из виду этот шаг, считая проверку гипотез пустой тратой времени и ресурсов. Однако изучение задач и проблем пользователей с высокой вероятностью даст более существенные выгоды, включая снижение когнитивной нагрузки при взаимодействии с интерфейсом продукта, и, конечно же, пресловутую экономию средств. Для всего этого, безусловно, необходим системный подход.
Компактный фреймворк
Подход команды T1 CRM состоит из нескольких этапов, каждый из которых представляет собой набор проверенных приемов и практик. От анализа существующих проблем и сложностей на стороне пользователей до оценки возможных решений.
Далее — расскажем о каждом из промежуточных шагов.
Есть проблема. В широком смысле слова проблемой может быть как задача по внедрению новой фичи, так и практически любое обновление продукта. Ей может быть все, что подразумевает качественное и количественное исследование и улучшение.
Составлять список проблем, которые предстоит решать с помощью тех или иных концепций, нужно в ходе аудита продукта, custdev-сессий и анализа рынка. Список может включать в себя слабые места в текущей версии продукта, результаты пользовательских исследований, лучшие практики в вашем сегменте, плюс — идеи по развитию функциональности и поиску новых векторов роста.
Проблемы являются отправной точкой для поиска и выбора ключевых решений, которые могут быть применены — последние и есть гипотезы.
Будут гипотезы. Наши проектировщики самостоятельно выбирают (из общего списка) проблемы и обсуждают варианты их решения на еженедельных встречах с командой. Они презентуют гипотезы и вместе формулируют новые концепции.
Работа над гипотезой состоит из ее описания, поиска материалов и исследований, выработки решения, определения участников для его реализации и презентация внутри команды. Мы используем шаблон, содержащий все эти моменты.
Описание. Далее мы детализируем проблему: перечисляем возможные источники и причины ее возникновения, формируем сценарии воспроизведения на стороне пользователя и гипотезу, при помощи которой мы предлагаем её решить. Описать суть проблематики нужно простыми словами, чтобы любой участник команды, инвестор или заказчик могли сразу понять, что происходит и заложено внутри.
Если мы сами не можем объяснить проблему, возникает вопрос: существует ли она на практике или в конкретном случае речь идет о чем-то ином.
Поиск материалов и исследований. Подавляющее большинство проблем, с которыми мы сталкиваемся при проектировании продукта, не являются уникальными. Ранее их — в том или ином виде — изучали и прорабатывали. Уметь находить такую информацию, конечно же, нужно, чтобы не «изобретать велосипед» и экономить время на разработку продукта. Насмотренность, умение находить полезные источники и понимание их качества невероятно ускорят процесс работы над гипотезами.
Даже когда от вас ждут кастомное решение, лучше иметь на руках несколько материалов с близкими подходами, нежели проектировать что-то с нуля.
Решение. Обычно наши решения на 90% состоят из проработанных пользовательских сценариев в виде макетов и кликабельных прототипов, однако здесь есть нюансы. В частности, создание интерфейса для какой-либо функции, инициированное [КОА1] бизнесом или владельцем проекта, проработанное аналитиками и разработчиками, отличается от работы над гипотезой. Это — два принципиально разных процесса.
В случае продуктовой концепции проектировщикам важно как можно скорее предложить решение конкретной проблемы. Нам не нужно следовать руководствам или принципам, на которых строится текущая разработка. Нам важно попытаться изучить задачу с нескольких сторон, зачастую отходя от уже принятых паттернов, и предложить целостное решение — сделать это помогает насмотренность, опыт и качественный алгоритм исследования проблемы.
Если в процессе мы смотрим на такой черновик или прототип и понимаем, что предложенное решение действительно имеет высокую важность, однако противоречит тому, что уже реализовано сейчас, мы можем оценить переработку и возможные преференции, которые получим в случае реализации нового подхода. В подобных вопросах следует быть максимально гибкими и смелыми. Мы позволяем себе ошибаться, не пытаемся защищать текущие решения только потому, что они «уже как-то работают». Это особенно важно отметить в контексте тематики статьи.
Команда. На этом этапе мы описываем состав участников для реализации гипотезы. Однако мы не подсчитываем расходы и не ставим задачи для аналитиков, бэкенд- или фронтенд-разработчиков. Наша цель — определить тех, с кем нужно будет продолжить обсуждение, когда гипотеза перейдет в статус задачи и попадет в бэклог разработки.
Очень важно сказать о том, что на этом этапе мы часто обращаемся к нашим коллегам из отдела разработки и аналитики. Некоторые хард-скиллы и компетенции у нас отсутствуют, но этот пробел мы восполняем путем общения и консультаций.
Презентация. Мы обсуждаем гипотезы и решения каждый месяц. На встречах кроме дизайнеров присутствуют руководители проекта и представители R&D-команды, с которыми мы выполняем общие и пересекающиеся функции, направленные на стратегическое развитие продукта и поиск точек роста. Процесс напоминает защиту проекта, когда выступающий кратко описывает проблему и свое видение решения.
На встречах мы учимся за ограниченное время четко и емко объяснять суть проблемы, результаты исследований, гипотезу и найденное решение. По итогу — определяем, над чем стоит продолжить работу. Конечно же, причинами отсева могут быть высокая сложность разработки, необходимость более глубокой оценки решения и низкий приоритет предложенной функциональности.
Однако наличие большого количества проработанных гипотез абсолютно разного рода не теряет ценности. Мы можем переиспользовать материалы для презентации потенциальным клиентам, чтобы продемонстрировать экспертизу и глубокую проработку, а также готовность реализовать тот или иной функционал.
Оценка решений. Имея список проработанных гипотез с готовыми решениями, мы зачастую не можем просто взять и передать их в бэклог разработки продукта. Очень важно добиться валидации и понять, что проблема действительно будет решена.
Для этого мы проводим «коридорные» usability-тестирования, пользовательские интервью, клик-тесты и прочие виды качественных и количественных исследований. У нас в T1 есть отличная возможность проводить исследования прямо внутри группы компаний, большинство из которых, так или иначе, пользуется CRM-системами.
Первыми пользователями нашего продукта стали коллеги. У нас не было преференций и «баллов» перед ними, даже учитывая факт «родства». Мы серьезно прорабатывали всю критику и проблемные моменты, исходящие от пользователей. Однако преимуществом в нашем случае является то, что рядом друг с другом мы можем оперативно исследовать и оценивать гипотезы.
Однако не все решения и гипотезы необходимо валидировать до передачи в разработку и выхода в продакшн. Часть из них может быть представлена смелыми и экспериментальными решениями, эффективность и ценность которых можно измерить только при широком использовании и измерении метрик в заданной временной перспективе. Ведь «проблема» означает не только конкретную трудность и сложность, с которой сталкивается пользователь, но и любую идею или функцию, позволяющую улучшить продукт или вообще образовать какую-либо новую пользовательскую практику в будущем.
Итог
Дедлайны и постоянные обязательства перед клиентами могут дать нам повод проигнорировать этапы начального проектирования и исследования продукта. Но не стоит поддаваться соблазну. Разница между хорошими и плохими продуктами заключается не столько в качестве идеи, сколько в продуманности ее реализации. А высокий уровень usability позволяет нам выстраивать с пользователями доверительные и долгосрочные отношения, решать проблемы и задачи клиентов. Поэтому наша цель — добиться наилучшего результата на каждом из этапов разработки сервиса.
Давайте же создавать решения, которые полюбят клиенты. Если вы хотите погрузиться в тонкости продуктовой разработки и самостоятельно изучить нюансы формирования гипотез — начать поможет тематическая литература. Вот несколько релевантных книг, которые рекомендуем мы и другие эксперты индустрии.
