Сегодня в статье попробуем привести в порядок то, зачем мы используем разные инструменты для исследования пользователей. Что такое магический JTBD и зачем он вообще нужен?
Кому не подходит вариант статьи, то есть стрим https://youtu.be/mcX-qt9pkMg
Начало начал. Разберемся с терминологией
Как в любой истории у нас есть главный герой, давайте называть его Актор, от слова Акт. В просторечье Пользователь. Методологии так или иначе пытаются проработать что-то вокруг этого самого Пользователя/актора.
Небольшое отступление, чтобы лучше понять суть терминов:
Пользователь от слова польза. (В словаре правда говорится про использование, то есть нахождение во владении, но этот утилитарный смысл мы опустим)
Актор – человек, который совершает акт в рамках какого-то сценария. Нам это понадобится позднее.
Первый шаг в создании продукта – это понять, кто, как решает сейчас проблему. Для этого идеально подходит карта действий, описывающая то, как задача решается Актором.
Начнем с путешествия пользователя к решению своих задач: CJM
Вместе с переходом к информационному обществу, с изменением фактором производства понятие и инструменты маркетинга начали тоже меняться, все больше внимания надо уделять более узким сегментам, так и маркетинг перестал быть навязывающим существующий продукт, а стал изучающим проблемы пользователей, похожая мысль озвучена у Стива Бланка в 4 шагах к озарению.
Метод CJM появился в рамках классического маркетинга, ходят конечно слухи, что при проектировании первой мышки для apple был сформулирован термин представителями компании IDEO.
Основная задача метода показать как пользователь получает некий схематичный импульс и что он делает для утоления этого импульса. При этом еще желательно показать с какими проблемами он сталкивается, какие проблемы у него получается решать. Метод в целом подойдет как для существующего продукта, так и для продукта, над которым еще ведется работа.
Представим себе, что мы захотели купить себе кофе. Я очень люблю кофе и покупаю его каждое утро в кофейнях внизу дома. Все бы ничего, но меня бесит, что когда идешь утром за кофе, там очередь или кофейня закрыта или еще чего, я бы с удовольствием платил заранее и приходил за готовым кофе.
Customer Journey Map - это карта взаимодействия пользователя с продуктом, карта составленная с учётом конкретных действий пользователей, с учетом его эмоций, целей, мотивов, привязки его к конкретному этапу, препятствий, барьеру пользователя. Визуализация его опыта. Очень часто CJM путают с воронкой.
Вопросы, которые можно задавать для проектирования CJM
С чего начинается первоначально использование продукта, с каким триггером?
Как пользователь использует наш продукт?
Как он решает свою задачу? Как он обходит бесячие штуки?
Как бы мы не старались схема получается весьма условной, есть только 1 стрим для движения нашего клиента. Но при добавлении разных вариантов, ветвлений схема перестает работать. В частности я с этим столкнулся, когда работал над оффлайн/онлайн проектом с омниканальным продвижением. То есть, когда нет единого пути, а у каждого свой путь, при чем 1 клиент может каждый раз отличным образом пользоваться нашим продуктом.
Омниканальность — маркетинговый термин, обозначающий взаимную интеграцию разрозненных каналов коммуникации в единую систему, с целью обеспечения бесшовной и непрерывной коммуникации с клиентом.
Сложные пути и множественные сценарии требуют других инструментов
Переход от CJM к Service BluePrint
Карта сервиса или Service Blueprint — строится исходя из того, что каждый элемент компании: люди, процессы, системы и коммуникации, — привносит в процесс создания опыта клиента. Service Blueprint позволяет создать достаточно точную модель сервиса, которая не только отражает его составные части. Она также учитывает все процессы внутри организации, которые участвуют в создании клиентского опыта. Таким образом Service Blueprint позволяет оптимизировать работу компании и конкретные бизнес-процессы. Также с помощью такой карты можно с большой точностью проектировать новые услуги и элементы клиентского опыта благодаря наглядной визуализации.
Задачи пользователя? как и для чего?
Окей, мы закончили с путями пользователей и думаю расположили объекты по ходу дела. Теперь пришло время поработать с тем как представить себе нашего пользователя, особенно, когда нам еще не понятен путь получения пользы. Для этого мы берем все, что мы написали в CJM и пытаемся дополнив это вписать в другую схему. Мы создаем так называемую карту эмпатий. Карта эмпатии (англ. empathy map) — инструмент визуализации идей, разработанный компанией XPLANE, позволяющий поставить себя на место пользователя, взглянуть на проблему, которую решает ваш продукт, его глазами. Может быть использован как в качестве альтернативы персонажам, так и как дополнение к ним.
В карте эмпатий можно выделить 4 блока:
Думаю и чувствую: что беспокоит пользователя? Какими словами он думает о проблеме? Насчет чего сомневается? Эту информацию лучше искать там, где пользователи жалуются: например, на форумах. Если у продукта есть служба поддержки – идем и слушаем, как нам делают мозги, собираем данные!
Говорю и делаю: как пользователь ведет себя публично? Что говорит? Какими способами решает проблему? Как ищет информацию по ней? Эту информацию стоит искать в социальных сетях. Особенно в этом плане полезен Linkedin – впн и в путь, ну или подойдет habr карьера: там можно относительно легко найти представителей самых разных профессий и изучить, какие события/конференции/обучающие мероприятия они посещают, в каких сообществах состоят, какие вопросы в них поднимают, какими навыками обладают и т.д. и т.п.
Вижу: на что похожа среда, в которой находится пользователь? С какими предложениями и альтернативами вашему продукту он сталкивается? Источник информации для этого блока — сама система и системы-конкуренты, онлайн и оффлайн реклама, статьи в профессиональных сообществах, официальные обзоры иными словами, мы открываем желтые страницы и копаем инфу, ну или идем в гугл и вводим ключевой запрос, с которым работают наши пользователи.
Слышу: как среда, в которой находится пользователь, воздействует на него? Что говорят ему коллеги, знакомые, авторитетные для него источники? Какие медиаканалы имеют влияние на пользователя? В отличие от блока «вижу», информация здесь не обязательно соответствует действительности. Но пользователь ей доверяет. Где искать информацию для этого блока: слухи и мнения на форумах (а собственно из соц. сетей можно узнать, что это за форумы), истории успеха, стереотипы и даже городские легенды.
Чего-то не хватает, а что если дополнить карту эмпатий болями и другими триггерами?
Проблемы и болевые точки: что тревожит пользователя? Чего он опасается? Что может стать причиной того, что он откажется от вашего продукта? Часто источником информации для этого становится блок «Думаю и чувствую». Все эти страхи и сомнения нужно будет развеять, и сделать это можно кучей способов: от «правильного» текста в интерфейсе, до индивидуальных консультаций.
Ценности и достижения: что поможет пользователю избавиться от проблем и сомнений? За какие возможности продукта он готов платить? Какие ценности мы должны транслировать? Выводы из этого блока влияют на продукт с самых разных сторон: они могут повлечь как мелкие изменения в интерфейсе или в тексте, так и добавление/исключение определенных функциональных особенностей, и иногда – даже изменение в позиционировании продукта.
Итоговая картинка дает нам полное представление о нашем пользователе. Карта эмпатий может быть под каждую ЦА. Инструмент многофункциональный и подойдет для разных ситуаций, но важно, чтобы он имел реальные основания для создания – интервью, Кастдевы и другие качественные источники, а не просто фантазии авторов.
Цель персон – создать эмпатию у команды, особенно у тех, кто не общается с пользователями.
Окей, что-то много ресурсов для создания некой иконы нашего пользователя, как можно использовать карты эмпатий еще?
Что делать с Картой эмпатий? Как дальше адаптировать ее для бизнес задач?
Мы составили то, что называется пониманием пользователя, следующим шагом мы можем дополнить его нашей продуктовой гипотезой, тем как мы будем решать эти проблемы, как будем успокаивать пользователя. Этот инструмент называется Value proposition canvas – шаблон ценностного предложения. Шаблон ценностного предложения, или Value Proposition Canvas - это схема, отображающая ключевые преимущества продукта и факторы, которые влияют на его выбор пользователем. Как заполнять шаблон описано в статье, мы же отметим определенное сходство левой части с предыдущим блоком.
Окей, у нас появилось понимание, как можем выглядеть наш продукт или понимание того, как наш продукт закрывает определенную задачу.
Если будем делать еще один зум аут, то увидим, что подобная методология находит свою реализацию в том числе в моделях бизнеса, например lean canvas. Цифра 1 это про проблему и Потребителя, 2-3 – про то, как мы решаем проблему и какое у нас УТП (еще один способ сказать про ценностное предложение, но термин, конечно, не продуктовый). Про модель остервальдера, я когда-то писал статью, позже ее перепишу учитывая развитие мысли за почти 4 года.
Получается все эти инструменты, схемы – про уровень абстракции к задачам и болям пользователя и предположение про то, как мы можем эти проблемы решить или как пользователь их решает.
А что же с user srory, jobs story and JTBD?
User Story – краткое описание функции вашего продукта с точки зрения пользователя. Для этого вы проводите качественные исследования, анализируете данные и создаете несколько персон — собирательных образов пользователей — из ключевых сегментов вашей целевой аудитории. Формула:
- Как (тип пользователя)
- Я хочу (действие/цель)
- Чтобы (результат)
Пример:
Как модница Елена (образ пользователя), Я хочу купить на сайте новое платье в один клик (действие), Чтобы больше времени тратить на шопинг, а не оформление заказа (результат).
Но в других ситуациях это не работает:
Что если твоя аудитория слишком большая и сегментированная? У всех разные цели, разные профессии, разный бэкграунд. Еще интереснее, когда по персональным и социально-демографическим характеристикам аудитория примерно однородна. Тут обычно начинаются попытки все каким-то образом объединить в «Лену, юриста» или «Ваню, студента» — это значит, что вы начинаете делать предположения.
Что, если вы хотите привлечь новых пользователей? Ведь персоны основываются на данных текущих (а не потенциальных) пользователей.
Jobs story (без актора - действующее лицо)
User story (действующее лицо присутствует)
JTBD
На примере Uber
кажется, что здесь точно есть две конкретные персоны: водитель и пассажир. На самом же деле, эта характеристика — лишь часть контекста: в зависимости от ситуации водитель может оказаться на месте пассажира, и наоборот. Мы думаем не о том, что разнит наших пользователей, а что их объединяет. Таким образом, то, что мы делаем, получает больший охват.
В Intercom как раз и изобрели job stories и используют их вместо user stories.
В Job Story фокус с персональных характеристик смещается на контекст.
Формула Job Story:
Когда (описание ситуации), Я хочу (мотивация), Чтобы (результат).
Пример:
Когда у меня есть всего 2 минуты, чтобы перекусить между встречами (описание ситуации),
Я хочу съесть что-то, чтобы это было просто, быстро и подняло мой уровень сахара в крови (мотивация),
Чтобы продержаться до обеда и сохранить рабочее настроение (результат).
Персоны позволяют вам под лупой посмотреть на ваших пользователей, но не отвечают на вопрос, почему они продолжают пользоваться вашим продуктом — и почему придут новые.
Важно понимать, как выглядит ваша текущая аудитория — это приходит после регулярных исследований и интервью. Но конкретно перед разработкой нового сервиса и продуктовой стратегии нужна job story.
Пример от компании Intercom, которая занимается разработкой решений для взаимодействия бизнеса и пользователей. Несколько лет назад они сделали новую функциональность — карту, на которой клиенты могли видеть, где сосредоточены их пользователи. Фича пользовалась огромной популярностью, и менеджеры думали, как развивать ее дальше. Улучшить географическую точность? Добавить интерактивность?
В Intercom провели исследование
чтобы понять «работу» карты, и обнаружили, что ей пользовались преимущественно на выставках, презентациях и в социальных сетях — чтобы впечатлить пользователей или инвесторов. Поэтому в компании решили сосредоточиться на внешнем виде карты (что сделало ее менее точной) и добавить возможность легко делиться ей в соцсетях. Ухудшив саму карту, они улучшили user experience – пользовательский опыт.
Когда «работа» продукта начинается и заканчивается
Продукты решают не изолированные проблемы, а проблемы, которые происходят в потоке разных других действий и обстоятельств.
Если у вашего продукта мало функций, для пользователя он не стоит того, чтобы его устанавливать (тем более, платить). Если продукт делает слишком много, он вступит в конфликт с уже существующими сервисами, которые вполне устраивают пользователя.
Разберем на простом примере. Допустим, вы пишете приложение-будильник; в этом случае последовательность действий пользователя может выглядеть так:
Пользователь вечером листает инстаграм
Понимает, что уже поздно и пора спать
Ставит будильник на 7
Спит
Просыпается, идет на кухню выпить воды
Спит
Будильник звенит в 7, пользователь переставляет его на 7–30
Будильник звенит в 7–30, пользователь встает
Включает радио
Делает зарядку.
«Работа» вашего продукта начинается с момента, когда вы можете добавить какую-то ценность для пользователя.
В примере выше это шаг 3. Можно влезть и раньше: например, если пользователь обычно встает в 7 утра, а уже 12 вечера, и телефон активен, приложение отправит напоминание: «Не хотите ли поставить будильник и пойти спать?».
Можно развить эту мысль и дальше: предложить пользователю следить за пульсом и активностью, и на основе этих данных рекомендовать ему лучшее время, чтобы пойти спать (а заодно и будить его в лучшее время для подъема). Нужно ли это? Испытывает ли пользователь «боль», соответствующую масштабам исследований и разработки? Это должна понять и решить продуктовая команда.
Когда «работа» продукта заканчивается:
у следующего шага в последовательности действий есть однозначные лидеры рынка, и вы не хотите с ними конкурировать
следующий шаг в контексте вашего продукта (вспоминаем приложение-будильник) может быть решен миллионом разных способов и миллионом разных типов пользователей
на следующем шагу у вас радикально меняется аудитория
следующий шаг не добавит никакой ценности продукту.
Как расставлять приоритеты в JTBD
Допустим, вы определили ключевые «работы» своих пользователей. Как понять, над какой из них работать в первую очередь?
Есть несколько факторов, которые надо учитывать в процессе расстановки приоритетов:
Насколько важна сама «работа» (по оценке от 1 до 10)
Насколько пользователи довольны текущим решением (по оценке от 1 до 10)
Какой есть потенциал для развития лучшего решения
«Недообслуженные» JTBD
отличное поле для инновационной стратегии роста (сделать существующие решения лучше). «Переобслуженные» JTBD — возможности для инновации (переделать решение и привлечь новую аудиторию).
Классные компании думают о своих пользователях. Очень классные компании думают о проблемах и потребностях своих пользователей. Инновационные компании думают о проблемах и потребностях своих пользователей и тех, кто пока еще не использует продукт.
Какой бы путь вы ни выбрали, Jobs To Be Done — полезный фреймворк, который поможет не потеряться в данных и понять, чего действительно хотят люди.
Как писал Питер Друкер: «Клиент редко покупает то, что бизнес ему продает».
Не фокусируйтесь на своем продукте или на решении — фокусируйтесь на «работах» (проблемах пользователя) и помогайте пользователю переводить их из статуса «надо сделать» в «сделано» — и делать его жизнь немного проще и комфортнее.
_______
Подписывайтесь на мой блог в ТГ https://t.me/blackproduct
Если есть идеи о том, какие темы можно разобрать в стриме или статье – пишите в комментариях или мне в ТГ @tintobro
