Передо мной стоит задача: нужно ввести новых продактов в курс дела.
Зачем нужен Discovery Flow? Этот документ поможет продакт-менеджеру на подготовительном этапе создания фичи. Документ носит рекомендательный характер и служит путеводной звездой по аналитике задач. :)
Пошаговая инструкция плохого Discovery Flow
Есть пошаговая инструкция, которая выглядит так:
Перед тем как начать, нужно определить список критических вопросов. Они пригодятся нам в конце.
1. Нужна ли эта функция пользователю?
2. Какую ценность эта функция несет? Какую проблему она решает?
3. Действительно ли клиенты испытывают проблему?
4. Если мы удалим эту функцию, что изменится?
5. Будет ли пользователь за это платить?
6. Есть ли у нас ресурсы для его создания?
7. Помогает ли это нам в достижении наших бизнес-целей?
...
Изучение – это все действия, касающиеся исследования продукта, коммуникации со стейкхолдерами, изучения существующих проблем клиентов, и поиска их решений. Этот этап включает в себя ресёч, разработку идей и анализ.
Валидация – это процесс проверки и тестирования гипотез, составленных в процессе изучения. Прежде чем проектировать что-то, нужно проверить, сможет ли наш продукт принести пользу нашей ЦА. Это делается с помощью прототипирования, тестирования и анализа результатов тестирования.
Фаза изучения
Ресёч
На этой стадии проводится общий обзор задачи. Рассматриваются такие аспекты, как: условия рынка, рыночный разрыв (gap), проблемы рынка, существующие решения, конкуренты / не конкуренты, ЦА, механизмы монетизации.
На этом этапе осуществляется сбор данных, сегментируется ЦА.
Разработка идей
После ресёча команда обсуждает идеи для будущего проекта. Идеи формируются с точки зрения пользователя и направлены на решение его проблем. По сути, формируется список необходимых функций.
Оценка
На этом этапе определяется приоритетность идей по важности, сложности реализации, ценности и риска.
Идеи можно разделить на три категории:
1. Скопированные идеи – это уже известные рынку идеи. Это чаще всего либо уже одобренные рынком решения, либо рабочий стандарт.
2. «Эволюционные» идеи» предлагают улучшенный вариант существующих решений.
3. Подрывные идеи описывают что-то совершенно новое для рынка.
На этом фаза изучения замыкается.
Фаза валидации
После составления идей и их оценки начинается этап проверки предлагаемых решений (как проверить, нужна ли пользователям эта функция?). Поскольку discovery продукта во многом зависит от фидбэка пользователей, на этом этапе важно с ними взаимодействовать.
Чтобы подойти к тестированию идеи, составляется карта идей (idea mapping), где обозначаются точки риска, которые и будут проверяться.
Далее идеи приоритезируются. После этого можно переходить к созданию прототипов.
Прототипирование
Создаются прототипы к идеям. Один и тот же прототип можно использовать для проверки нескольких идей.
Тестирование
Тестируются идеи. Тестирование зависит от случая и рисков. Здесь стоит упомянуть лишь несколько моментов:
1. Точность теста важнее скорости.
2. Используйте инструменты прототипирования (ручка и бумага либо известные инструменты Figma, UXPin, Balsamiq, Sketch).
Анализ
Анализируются результаты теста, чтобы ответить на вопросы, поставленные в начале. Как только идея подтверждена, она может быть преобразована в пользовательскую историю или фичу.
. . .
Почему это плохой флоу? Потому что это не практическое руководство, а сухая теория, которой скорее всего не сможет воспользоваться начинающий продакт.
Пошаговая инструкция хорошего Discovery Flow
Построение Vision
Цель: построить общий vision.
Мы рассматриваем наш конечный успех в…
На рынке представлены…
Наша целевая аудитория…
Конкуренты предлагают… мы отличаемся от конкурентов тем, что… мы лучше конкурентов в … мы хуже конкурентов в…
Разработка идей
Цель: формируется список необходимых функций, фиксируются их роли, модули и интеграции.
Продукт (функция) –> эпики продукта –> задача –> подзадача
Схема:
Например:
Продукт: расширить функционал приложения
Эпик 1: Подготовка Extension-приложения
Эпик 2: Подготовка Master-приложения
Можно подготовить в формате MindMap:
Оценка
Цель: оценить идеи (функции) на предмет их ценности с точки зрения пользовательской истории.
Моделирование бизнес-процесса и создание wireframes
Цель: с помощью BPMN (Business Process Modeling and Notation) определить и зафиксировать основные сценарии взаимодействия пользовательских ролей и системы.
C помощью wireframes показать основные группы содержимого, информационную структуру и как пользователь взаимодействует с интерфейсом.
Пример моделирования с помощью системы BPMN:
Либо с помощью wireframe:
Оценка и инвестигирование
Цель: оценить модель и прототип.
Пошаговое руководство:
1. Выбрать для теста наиболее важные задачи и группы пользователей.
2. Написать сценарии задач и подготовить исходные данные.
3. Написать инструкцию для пользователя, в которой сообщить, что пользователю нужно сделать, но не КАК это сделать.
4. Если возможно, пригласить разработчиков понаблюдать за тестом.
5. Составить список проблем с юзабилити, рассортировать его по степени важности.
6. Инвестигирование: поиск узких мест (проблем), возможных решений, инструментов и сценариев работы.
Презентация
Цель: рассказать про выгоды продукта стейкхолдерам.
План проекта и финальная оценка
Цель: оценить разработческие ресурсы, сроки реализации и затраты. Составить таблицу и заполнить данные по затратам.