User Journey Map на практике: как из карты пути пользователя рождаются ключевые фичи
2025-12-11
Это Павел Еременко, владелец продукта DAG в компании Avanpost.
Как часто я слышал в выступлениях и читал в блогах продуктовых менеджеров фразы о том, что «нужно делать персонажей» или «строить карты пути пользователей»? Наверное, столько же раз, сколько встречался со скепсисом со стороны других менеджеров, которые считают всё это лишь красивыми ритуалами, имеющими мало отношения к практике. С теми же сомнениями мы приступали к новому продукту, пока один такой «ритуал» не привёл нас к ключевой фиче в продукте, которая позволяет повысить эффективность пользователей в основном сценарии на 60%.
Когда мы только начинали работу над новым продуктом — Avanpost DAG, перед нами стояли достаточно очевидные задачи: реализовать функционал анализа и классификации данных на файловых шарах, предоставить пользователю возможности привести права доступа к критическим данным в соответствие политике безопасности, предоставить функционал аудита событий для обработки инцидентов и много чего еще. Работы по реализации даже базового функционала много, бэклог пух от «must have» фич, и на первых порах казалось — тут не до теорий.
В этой статье я на реальном кейсе покажу, как профилирование пользователей и построение карт пользовательского пути (User Journey Maps) помогают в генерации идей, реализация которых делает продукт по-настоящему полезным.
Как часто я слышал в выступлениях и читал в блогах продуктовых менеджеров фразы о том, что «нужно делать персонажей» или «строить карты пути пользователей»? Наверное, столько же раз, сколько встречался со скепсисом со стороны других менеджеров, которые считают всё это лишь красивыми ритуалами, имеющими мало отношения к практике. С теми же сомнениями мы приступали к новому продукту, пока один такой «ритуал» не привёл нас к ключевой фиче в продукте, которая позволяет повысить эффективность пользователей в основном сценарии на 60%.
Когда мы только начинали работу над новым продуктом — Avanpost DAG, перед нами стояли достаточно очевидные задачи: реализовать функционал анализа и классификации данных на файловых шарах, предоставить пользователю возможности привести права доступа к критическим данным в соответствие политике безопасности, предоставить функционал аудита событий для обработки инцидентов и много чего еще. Работы по реализации даже базового функционала много, бэклог пух от «must have» фич, и на первых порах казалось — тут не до теорий.
В этой статье я на реальном кейсе покажу, как профилирование пользователей и построение карт пользовательского пути (User Journey Maps) помогают в генерации идей, реализация которых делает продукт по-настоящему полезным.
Зачем вообще думать о пользовательском опыте?
Владелец продукта (Product Owner) — это голос клиента внутри команды. Но как определить, какой именно функционал в продукте будет полезен клиенту? Лично мне очень часто приходилось сталкиваться с такими ответами: «интуиция Стива Джобса», «у нас достаточно собственного опыта и мы сами знаем, что надо клиенту», «делаем как у конкурентов, уж они-то точно знают». И хотя всё перечисленное имеет право на существование, достижение успешного результата всё же превращается в игру на удачу. Поэтому главная задача владельца продукта — это как можно глубже погрузиться в пользовательский контекст.
Кажется, что здесь начинается какая-то эзотерика и духовные практики, абсолютно неинтересные бизнесу. На самом деле это не так. Самый страшный сон для бизнеса — потратить ресурсы на разработку продукта, который окажется никому не нужен. Моя любимая метафора — кружка с ручкой внутри. Глубокое понимание пользователя, его потребностей и опыта взаимодействия с продуктом снижает этот риск до минимума. Кроме прочего, самым наглядным и практическим отражением такого подхода является рост ключевых метрик (LTV, конверсия, удержание).
Кажется, что здесь начинается какая-то эзотерика и духовные практики, абсолютно неинтересные бизнесу. На самом деле это не так. Самый страшный сон для бизнеса — потратить ресурсы на разработку продукта, который окажется никому не нужен. Моя любимая метафора — кружка с ручкой внутри. Глубокое понимание пользователя, его потребностей и опыта взаимодействия с продуктом снижает этот риск до минимума. Кроме прочего, самым наглядным и практическим отражением такого подхода является рост ключевых метрик (LTV, конверсия, удержание).
С чего, а главное, как начать?
Конечно, исследовать пользовательские потребности надо начинать с ответа на вопрос: «кто наш пользователь?». Но на практике быстрый темп разработки приводит к конфликту с этим порядком. Нам уже нужны пользовательские истории в бэклог, то есть ответы на вопрос: «что делает пользователь?», а времени на полноценное исследование пользователей просто нет. Это то место, в котором хочется бросить едва начатое и поплыть по течению рутины.
Выходом, как это часто бывает, является компромисс и итеративный подход к решению большой задачи. В нашем продукте мы поступили именно так: начиная с достаточно общего представления о пользователях, методично углубляем наши знания.
Выходом, как это часто бывает, является компромисс и итеративный подход к решению большой задачи. В нашем продукте мы поступили именно так: начиная с достаточно общего представления о пользователях, методично углубляем наши знания.
Шаг 1: Персона. Профилирование пользователей без воды
Очень часто в ТЗ на разработку продукта в разделе «Сведения о пользователях системы» мы встречаем сведения о категориях пользователей, их функциях, правах и обязанностях, где в характеристиках можно прочитать что-то про умение пользоваться компьютером и браузером. Что ж, пожалуй, это хороший пример того, чем не является профиль персоны. Хотя такая информация может послужить отправной точкой для профилирования.
Персона — это обобщенный собирательный образ целевого пользователя продукта, созданный на основе исследований и отражающий ключевые характеристики, потребности, цели, боли, мотивы и типовое поведение реальных пользователей.
Целесообразно сконструировать несколько «Персон», для каждой из которых создать профиль. Один из очевидных подходов — сформировать персоны на основе пользовательских ролей, да хоть из ТЗ. Не во всех продуктах такая база подойдет, поскольку функционально роль может быть вообще одна, а архетипов поведения с разными сценариями — больше. Оставим на другой раз разговор о том, как быть в таком случае, а сегодня мы разбираем наш практический кейс.
Читайте продолжение на habr.com
Персона — это обобщенный собирательный образ целевого пользователя продукта, созданный на основе исследований и отражающий ключевые характеристики, потребности, цели, боли, мотивы и типовое поведение реальных пользователей.
Целесообразно сконструировать несколько «Персон», для каждой из которых создать профиль. Один из очевидных подходов — сформировать персоны на основе пользовательских ролей, да хоть из ТЗ. Не во всех продуктах такая база подойдет, поскольку функционально роль может быть вообще одна, а архетипов поведения с разными сценариями — больше. Оставим на другой раз разговор о том, как быть в таком случае, а сегодня мы разбираем наш практический кейс.
Читайте продолжение на habr.com
О компании AVANPOST:
Avanpost — российский вендор-новатор в области безопасности идентификационных данных, развивает свою экспертизу с 2007 г.
Avanpost предлагает как комплексное решение безопасности Identity Security Platform для защиты цифровых идентичностей пользователей, устройств и приложений от различных угроз для крупных предприятий и нагруженных инфраструктур, так и более легкие стандартизированные продукты для среднего бизнеса:
Экосистема решений по управлению доступом построена на базе полностью собственного ПО, лучшего в своем классе, не зависящего от сторонних решений и Open Source компонентов.
Архитектура продуктов предполагает использование в отказоустойчивых, геораспределенных, высоконагруженных инфраструктурах.
Avanpost придерживается идеологии максимальной открытости. Технологически совместимы с отечественным ПО, интегрируются и объединяются с программными компонентами различных вендоров.
Avanpost предлагает как комплексное решение безопасности Identity Security Platform для защиты цифровых идентичностей пользователей, устройств и приложений от различных угроз для крупных предприятий и нагруженных инфраструктур, так и более легкие стандартизированные продукты для среднего бизнеса:
- Avanpost IDM/IGA — система управления учетными записями и доступом к корпоративным ресурсам предприятия;
- Avanpost SmartPAM для контроля привилегированного доступа;
- Avanpost DS — российская служба каталогов, предназначенная для управления Linux-инфраструктурами и замены MS AD, каталог для промышленных нагрузок, протестированный на 30 млн объектах);
- Avanpost CA (российский доменный сервис сертификации, универсальный для различных доменов, включая MS);
- Avanpost PKI (управление жизненным циклом объектов инфраструктуры открытых ключей из единого центра);
- Продукты линейки аутентификации Avanpost Access: FAM, MFA+, USSO, WSSO, Device Control.
Экосистема решений по управлению доступом построена на базе полностью собственного ПО, лучшего в своем классе, не зависящего от сторонних решений и Open Source компонентов.
Архитектура продуктов предполагает использование в отказоустойчивых, геораспределенных, высоконагруженных инфраструктурах.
Avanpost придерживается идеологии максимальной открытости. Технологически совместимы с отечественным ПО, интегрируются и объединяются с программными компонентами различных вендоров.
Другие новости
Получайте свежие новости первыми!
