#product‑owner 04. Ключевой процесс продукта. Создание начальных макетов продукта

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

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

Блоки, соединенные линиями. Каждый блок — это пользовательская история по некой активности пользователя в системе.

Например, для CRM аренды недвижимости это может быть так:

• Вход менеджера CRM в систему
• Проверка наличия и бронь недвижимости по звонку от клиента
• Мониторинг панели основных показателей системы
• Завершение работы

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

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

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

Если система делается для внешнего потребителя, можно начать с самых дальних касаний (например, потребитель увидел ваше рекламное объявление где-то в Сети).

Описывать следует до того момента, как пользователь получил ощутимую пользу от использования сервиса: разместил объявление на площадке, получил некую информацию, настроил свой профиль в социальной сети (например, >90% заполненности профиля).

Если говорить о некой многопользовательской системе, то проект можно разделить на области:

• Неавторизованная область (пользователь не зарегистрирован в системе). Здесь будут общие текстовые страницы, каталог товаров/услуг, формы входа, регистрации.
• Кабинеты по типам пользователей. В системе могут работать Поставщики, Партнеры, Покупатели и другие типы внешних пользователей. На каждого из них будет свой вид кабинета со своим интерфейсом.
• Кабинеты для служебных ролей. Модераторы, операторы, администраторы, контент-менеджеры.

Определите список кабинетов в системе и для каждого кабинета опишите список доступных страниц.

Сначала опишите состав меню каждого кабинета, а затем список внутренних страниц. Пример - Страница заказа. Ее не будет в меню. В меню будет страница Заказы, а уже с нее идет ссылка на Страницу заказа.

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

Как создавать макеты:

• сначала вручную на бумаге (на А4 можно сделать 4 макета).
• визуализируем только ключевые детали (не нужно пока тратить внимание на мелкие несущественные детали)
• если есть время/деньги/желание, то даем задание перенести это в системы создания прототипов (Axure или др) с полной динамикой прохода по страницам
• описывайте только страницы ключевого процесса. Меньше страниц — меньше согласований, быстрее вносить правки, более точный фокус на основном.
• Не нужно сидеть долго над каждым макетом. На 1 версию макета 1 страницы - не более 10 мин.

Лучше быстро сделать, показать, понять, что это совсем не то, переделать заново, нежели потратить 2 недели на макеты, а затем за них держаться, т.к. мы в ним вложили столько сил и души. Человеку свойственно защищать то, во что он сильно вложился, даже если это полная ерунда. Поэтому не нужно слишком “прикипать” к своим макетам. Макеты — это просто способ общения с потребителями и разработчиками, не более того.

Примечание:

• Стремитесь к тому, чтобы функционал 1 версии был минимальный. Чем меньше объем первой версии, чем быстрее, проще и дешевле ее будет внедрить: меньше рисовать, меньше писать ТЗ, меньше кодировать, меньше в итоге переделывать.
• У вас есть лояльные заказчики/пользователи. Используйте это для верификации ваших макетов. В правильном ли мы направлении движемся? Понимают ли они эти макеты без пояснений? Есть ли у них интерес к системе(в ходе взаимодействия это будет видно)?
• Сразу настройтесь на то, что вы сделаете структуру и макеты за 1 день. В этом нет ничего сложного, можно подсматривать удачные решения из чужих систем (но не надо слепо копировать). Самые ужасные корявые макеты (но по смыслу правильные) лучше тех, которые сделают “в ближайшее время”.

Созданные макеты следует показать пользователям и доработать их по их обратной связи.

Зачем это нужно:

• интерфейс может быть непонятен им.
• возможно вы упустили важные для них особенности процессов
• возможно ваш интерфейс не решает важных задач пользователя

Все это вы сможете выявить в процессе беседы с представителями целевой аудитории.

Что необходимо сделать:

1. Выберите из вашего пула лояльных пользователей 2‑3, которые согласны на колл (звонок по скайпу) на 20 минут по вашей системе.

2. Заранее запланируйте колл по скайпу с ними (важно чтобы пользователь был с ПК, а не с мобильного).

В самом колле:

• Кратко напомните суть сервиса и поблагодарите за помощь в создании сервиса

• Покажите свои макеты, можно просто фото ваших набросков, и кратко опишите их
  

• Задавайте различные вопросы формата “А как сделать то-то”. Это даст возможность выявить, насколько человеку понятен интерфейс программы
  
• Дайте почувствовать пользователю себя экспертом и поощряйте его высказывать критическое мнение о системе и интерфейсе.

  Задайте вопрос - решает ли система начальную поставленную задачу?

  Спросите, какой макет он считает самым важным? Почему? Какие страницы ему кажется несущественными и ненужными? Чего не хватает? Как в идеале надо упростить процесс работы над системой?

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

Занесите результаты и инсайты в документ Excel. Этот документ вы потом сможете использовать для поиска идей по улучшению вашего продукта.

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

Шаблон сториборда в табличном виде, структуры проекта и сбор обратной связи вы сможете найти среди материалов на нашем сайте

Советы

• Прочитайте книгу Д. Кнапп Спринт Как создать и проверить продукт за 5 дней.
• Посмотрите книгу Р. Фитцпатрик Спроси маму. Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?
• Вы можете довольно быстро научиться делать макеты в Axure (их проще развивать, изменять + можно делать динамический интерактивный интерфейс).
• Для создания структур проектов вы можете попробовать использовать FreeMind или программы аналоги. Они позволяют строить древовидные карты.

Задание

• Создайте свой сториборд ключевого процесса
• Получите комментарии пользователей по вашему сториборду и улучшите его.
• Создайте структуру своего проекта (кабинеты и страницы для них)
• Создайте макеты страниц от руки на бумаге.
• Провести 2-3 опроса с пользователя и собрать обратную связь по созданным прототипам