Привет, Хабр! Это Павел Еременко, владелец продукта DAG в компании Avanpost.

Как часто я слышал в выступлениях и читал в блогах продуктовых менеджеров фразы о том, что «нужно делать персонажей» или «строить карты пути пользователей»? Наверное, столько же раз, сколько встречался со скепсисом со стороны других менеджеров, которые считают всё это лишь красивыми ритуалами, имеющими мало отношения к практике. С теми же сомнениями мы приступали к новому продукту, пока один такой «ритуал» не привёл нас к ключевой фиче в продукте, которая позволяет повысить эффективность пользователей в основном сценарии на 60%.

Когда мы только начинали работу над новым продуктом – Avanpost DAG, перед нами стояли достаточно очевидные задачи: реализовать функционал анализа и классификации данных на файловых шарах, предоставить пользователю возможности привести права доступа к критическим данным в соответствие политике безопасности, предоставить функционал аудита событий для обработки инцидентов и много чего еще. Работы по реализации даже базового функционала много, бэклог пух от «must have» фич, и на первых порах казалось – тут не до теорий.

В этой статье я на реальном кейсе покажу, как профилирование пользователей и построение карт пользовательского пути (User Journey Maps) помогают в генерации идей, реализация которых делает продукт по-настоящему полезным.

Зачем вообще думать о пользовательском опыте?

Владелец продукта (Product Owner) – это голос клиента внутри команды. Но как определить, какой именно функционал в продукте будет полезен клиенту? Лично мне очень часто приходилось сталкиваться с такими ответами: «интуиция Стива Джобса», «у нас достаточно собственного опыта и мы сами знаем, что надо клиенту», «делаем как у конкурентов, уж они-то точно знают». И хотя всё перечисленное имеет право на существование, достижение успешного результата всё же превращается в игру на удачу. Поэтому главная задача владельца продукта – это как можно глубже погрузиться в пользовательский контекст.

Кажется, что здесь начинается какая-то эзотерика и духовные практики, абсолютно неинтересные бизнесу. На самом деле это не так. Самый страшный сон для бизнеса – потратить ресурсы на разработку продукта, который окажется никому не нужен. Моя любимая метафора – кружка с ручкой внутри. Глубокое понимание пользователя, его потребностей и опыта взаимодействия с продуктом снижает этот риск до минимума. Кроме прочего, самым наглядным и практическим отражением такого подхода является рост ключевых метрик (LTV, конверсия, удержание).

С чего, а главное, как начать?

Конечно, исследовать пользовательские потребности надо начинать с ответа на вопрос: «кто наш пользователь?». Но на практике быстрый темп разработки приводит к конфликту с этим порядком. Нам уже нужны пользовательские истории в бэклог, то есть ответы на вопрос: «что делает пользователь?», а времени на полноценное исследование пользователей просто нет. Это то место, в котором хочется бросить едва начатое и поплыть по течению рутины.

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

Шаг 1: Персона. Профилирование пользователей без воды

Очень часто в ТЗ на разработку продукта в разделе «Сведения о пользователях системы» мы встречаем сведения о категориях пользователей, их функциях, правах и обязанностях, где в характеристиках можно прочитать что-то про умение пользоваться компьютером и браузером. Что ж, пожалуй, это хороший пример того, чем не является профиль персоны. Хотя такая информация может послужить отправной точкой для профилирования.

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

Целесообразно сконструировать несколько «Персон», для каждой из которых создать профиль. Один из очевидных подходов – сформировать персоны на основе пользовательских ролей, да хоть из ТЗ. Не во всех продуктах такая база подойдет, поскольку функционально роль может быть вообще одна, а архетипов поведения с разными сценариями – больше. Оставим на другой раз разговор о том, как быть в таком случае, а сегодня мы разбираем наш практический кейс.

Практика, а не теория

Поскольку на старте разработка уже требовала сценариев использования и апеллировала к тому, что «этот функционал и так очевиден», я ограничился тем, что взял за основу функциональные роли с одной стороны, но придал им немного человечности, чтобы сделать первый шаг к профилированию. Это просто. Достаточно дать каждой Персоне человеческое имя вместо технического названия. Такое предложение нашло быстрый отклик по всей команде. Говорят, что имена удобнее всего подбирать по первой букве названия роли, что-то вроде «Аналитик – Андрей», но нам повезло больше. У нас в компании были реальные пользователи продуктов, предоставляющих похожий функционал и персоны с именами быстро «ожили». Мы обсуждали истории, используя имена, и все понимали, кому именно предстоит работать с обсуждаемым функционалом.

На этом этапе «Персона» выглядела крайне скудно и немногим отличалась от просто роли. Вот пример:

Честно говоря, уже на этом уровне детализации мы идентифицировали ключевых, с точки зрения функциональности продукта, Персон, вполне живых и понятных, и перешли к следующему шагу – построению карт пользовательского опыта (это шаг 2 далее по тексту). Вернулись к более детальному профилированию мы несколько позже. Однако, чтобы не разрушать структуру повествования, опишу дальнейшую работу с Персонами здесь.

Профиль

Профиль должен быть хорошо структурирован, удобно читаться самыми разными участниками команды, поэтому 20-ти страничные документы описаний профиля нам точно не годятся. Нужен компактный и наглядный документ или табличка. В сети есть немало красивых шаблонов пользовательских профилей в удобной для вас системе (Miro, Notion, etc). В моём случае, в компании принят Confluence, поэтому я создал шаблон там.

Как заполнить профиль?

Крайне важно, чтобы профиль наполнялся на основе реальных данных. Ваш личный опыт и интуиция – штука хорошая, и, возможно, помогут сделать некоторый набросок, но реальные факты могут оказаться для вас сюрпризом. В зависимости от продукта и стадии его жизненного цикла, в вашем арсенале могут быть самые разные источники информации: продуктовые метрики, данные из служб поддержки или внедрения, опросы, публикации в СМИ, интервью с пользователями. На практике в силу ограничений, прежде всего, во времени, не всегда есть возможность провести полноценные глубинные исследования. Выход, как и ранее, – в итеративном подходе. Опирайтесь на те данные, которые можете собрать прямо сейчас и улучшайте профили по мере накопления данных. Реальные данные и интуиция лучше, чем просто интуиция.

В нашем случае источником данных была серия пользовательских интервью. Как я и сказал ранее, нам повезло с тем, что пользователи оказались, что называется, под рукой. И, поскольку я уже забегал вперед, не будет лишним сказать, что профили персон заполнялись и улучшались совместно с улучшением User Journey Map. Другими словами, часто одно и то же интервью являлось источником данных и для профиля, и для UJM.

Важно отметить, что интервью – это качественное исследование. Оно не позволит взвесить распространенность тех или иных утверждений среди всех представителей группы. Поэтому для полной картины могут потребоваться дополнительные исследования. Однако именно интервью  позволяет собрать информацию из первых уст и самое главное – у вас будет идеальная возможность задать те самые тойотовские «5 почему» и докопаться до глубин пользовательской мотивации.

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

Шаг 2: User Journey Map – карта, которая открывает глаза

Теперь, когда мы разобрались с нашими Персонами, самое время подумать о том, как они взаимодействуют с продуктом на протяжении всего жизненного цикла. Другими словами, мы перешли от статического анализа к анализу динамическому. Для того, чтобы разложить все аспекты такого взаимодействия по полочкам, сделать результат наглядным и понятным для всех участников команды, нужен подходящий фреймворк. На сцену выходит User Journey Map (UJM) или Карта Пользовательского Опыта.

Простыми словами, User Journey Map – это визуализация пути пользователя из пункта «А» в пункт «Б». От осознания потребности к достижению значимого для него результата.

У такой карты есть две оси: по одной мы фиксируем этапы пользовательского пути, по другой – его аспекты или слои. Ну и, конечно, выглядит она как таблица.

Как мы строили наши UJM

Изначально, для каждой Персоны существует как минимум один сценарий взаимодействия с продуктом. В качестве отправной точки его можно вполне описать на интуитивном уровне или по итогам беглого общения с пользователями. Страшного в этом ничего нет, пока что это только набросок, который будет обретать более реальные очертания по ходу нашей дальнейшей работы.

В нашем случае для персоны «Антон» было несколько сценариев, для каждого из которых мы разработали UJM. Одну из карт мы рассмотрим сегодня. 

«Антон расследует инцидент с неструктурированными данными»

Мы описали сценарий в двух словах, цели и ожидания Антона, а также разбили путь на этапы: Осведомленность, Инициация расследования, Расследование, Завершение

По одной «оси» карты картина прояснилась. Перейдем к формированию и наполнению слоёв

Ключевые слои карты

Важная задача, которую решает наш UJM, – это погружение в пользовательский контекст, которое поможет всем участникам команды выполнять свои задачи, ясно понимая, зачем они это делают. Поэтому на карте должны присутствовать, как «рациональные» слои (например «Действия»), так и слои с «Эмоциями», «Мыслями и чувствами» и целый ряд других. Фреймворк – это не готовый шаблон, а набор рекомендаций, которые каждая команда может адаптировать под себя.

Для себя мы выбрали следующие слои карты:

Действия

Здесь описываем список или порядок действий на данном этапе, возможные альтернативы. Можно сказать, что это сценарий этапа.

Эмоции

Мы решили, что эмодзи достаточно хорошо передадут состояние пользователя на каждом этапе

Ожидания

То, как пользователь представляет себе то, что должен дать ему продукт на данном этапе. Откуда они берутся? Из прошлого опыта работы с чем-то похожим, маркетинговых обещаний, интуиции пользователя.

Барьеры

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

Возможные улучшения

Это место для идей. В сущности, то самое, где в ответ на барьеры рождаются полезные фичи. То самое, которое может подарить вашему продукту ключевые преимущества.

Связанные истории

Мы решили, что нам будет удобно, если мы сразу будем видеть связь между барьерами, возможностями и фактическими историями из нашего бэклога. Так картина становится полной и мы можем оценить, на сколько мы ...готовы идти к пользователю за новым откликом и переосмыслить карту.

Другие слои

Вам могут быть полезны и другие слои, которые можно легко нагуглить и рассмотреть. Например, в своей практике я также использовал слои с пользовательскими интерфейсами или связанными сущностями предметной области, но это уже совсем другая история.

Вот пример того, что получилось у нас:

Шаг 3: Инсайт. На стыке барьера и возможности

UJM – это живой инструмент. Его формирование начинается с набросков, детализируется в ходе пользовательских интервью, совместных тестовых сессий, на основе анализа обращений в поддержку и т.д. В дальнейшем карта регулярно пересматривается по мере развития вашего продукта.

В нашем случае, на начальном этапе вместе с Антоном нам удалось сформировать примерный скетч. «Действия» описывали поведение пользователя в достаточно комплексном окружении. Другими словами, проводя расследование, он пользовался не одним инструментом, а целым арсеналом. Использовал разные представления, переключал фильтры данных, подбирал найденные куски логов в условный «блокнот» и т.д. Я посчитал нужным фиксировать опыт именно так как есть, хотя, казалось бы, он выходит за рамки конкретного продукта.

В этот момент и удалось выявить первые противоречия. Описанное поведение звучало как ожидаемое, но что-то было здесь не так. Всё это выглядит, скорее, как привычка. А таковы ли ожидания Антона на самом деле? Мы пофантазировали вместе об идеальном продукте и его супервозможностях. Таким образом вышли на более честные ожидания. Конечно же, Антону хотелось бы, чтобы вся фактура по расследованию находилась и «подшивалась к делу» максимально быстро и просто, а лучше – автоматически.

А что на деле? Капитальный барьер под названием «всё вручную».

Поиск идей

К определенному моменту в нашем продукте уже было разработано достаточное количество базового функционала, который технически позволял Антону найти всю необходимую для расследования информацию в интерфейсе продукта. И мы решили устроить сессию, которую назвали «User testing workshop». Мы собрались всей командой, чтобы посмотреть за тем, как Антон будет страдать проводить расследование, увидеть проблемные места, а заодно в формате мозгового штурма предложить идеи решений.

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

И результат превзошел все ожидания. Мы воочию убедились в том, как долго и сложно приходится возиться с расследованием, и идеи «как помочь Антону» посыпались как из рога изобилия.

Шаг 4: От инсайта к фиче

В результате идей хватило на целый Эпик «расследование», который требовал валидации. В разных продуктах и на разных стадиях развития этот процесс может быть довольно громоздким и формализованным. В нашем случае была предложена идея функционального прототипа, который мы назвали «контекст расследования». Его суть заключается в том, что Антон, инициируя расследование, наполняет его известными ему фактами и обстоятельствами, а продукт использует их при формировании фильтров в разных интерфейсах. Реализация функционала в таком виде не слишком трудоемка, но уже даёт пользователю ощутимую ценность, избавляя от рутины в расследовании.

Уже через неделю мы провели контрольный замер и убедились, что Антон потратил на 60% меньше времени на поиск фактов по инциденту, а эмодзи в графе «Эмоции» на этапе «Расследование» стал немного веселее.

Впереди еще много важного функционала в рамках нового эпика, но мы смогли быстро обнаружить и подтвердить важную пользовательскую потребность и найти путь к её удовлетворению.

Заключение

Итак, мы прошли путь по цепочке «Скептицизм -> Создание Персон вместо ролей -> Построение UJM -> Выявление барьеров -> Поиск возможностей -> Идея фичи -> Реализация -> Измеряемый результат»

Мы убедились, что профилирование пользователей и UJM – это не ритуалы и не что-то для галочки, а мощные инструменты принятия решений для владельца продукта и повышения вовлеченности команды в создание ценности. Эти инструменты смещают фокус с «что Мы хотим сделать» на «какую проблему Пользователя мы решаем».

Надеюсь, наш опыт вдохновит и вас на превращение пользовательских болей в киллер-фичи ваших продуктов. <3

PS. Ну и, конечно, рассказ про исследования был бы неполным без самого исследования. Если вам близка тема ИБ и защиты неструктурированных данных (файловые серверы, СХД, облака) — буду очень благодарен, если уделите 2 минуты нашему анонимному опросу:

https://forms.yandex.ru/cloud/6937e43e6d2d73ea42c50de8