CustDev|Customer Journey Map|eye-tracking|IT|UX-исследователь|UX исследования|Банковский UX|Интервью-метод|Проведение опроса|банкоматы/терминалы|госсайты|заметки|интервью|интернет-магазин|исследование пользователей|конференции|мобильные интерфейсы|проектирование|профессиональные интерфейсы|рейтинг банков|экспертная оценка|юзабилити тестирование

Построение Customer Journey Map

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

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

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

cjm

Построение CJM

Customer Journey Map

Практически каждый хотя бы раз заказывал что-то онлайн. Обычно эти шаги происходят так:

  1. Пользователь исследует рынок;
  2. Пользователь, отбирает компании, с которыми мог бы сотрудничать;
  3. Пользователь определяется и покупает то, что хотел и уже после совершения этого шага, он становится вашим клиентом.

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

customer journey map

Примеры карты

Ещё до того, как покупатель придёт к выбору компании, он проходит несколько этапов или другими словами шагов:

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

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

И здесь помощником для совершения продаж в вашей компании станет разработка Customer Journey Map: именно карта пути потенциального клиента поможет оценить потребности, боли, а также каналы, по которым люди попадают к вам.

Определение понятия

CJM (Customer Journey Map) — наглядная визуализация того, какой путь проделывает потенциальный покупатель, какие эмоции он при этом испытывает и с какими сложностями может столкнуться. Обычно создаётся в виде иллюстрации, диаграммы или даже таблицы и содержит все точки соприкосновения вашего бренда и представителя его аудитории.

Конечной целью такой карты необязательно должна быть покупка. Для вашей компании это также может быть:

карта пути клиента

CJM

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

Перед созданием пути для клиента или CJM учитываются следующие факторы:

Варианты CJM карт

Есть несколько вариантов содержаний Customer Journey Map, которые подходят для решения разных задач. Они могут использоваться самостоятельно или в комбинации и содержать в себе информацию:

Например, в одной карте часто совмещены UX и эмоциональные реакции или эмоциональные реакции и стадии принятия решения — это делает её более полезной. В то же время не стоит пытаться охватить всё сразу, иначе результат может выйти слишком запутанным.

Customer Journey Map примеры

Рассмотрим процесс создания CJM на наглядном примере. Гипотетическая компания продаёт товары в онлайн-магазине и в последние полгода начала сталкиваться с частыми отказами: пользователь проводит некоторое время на сайте, но уходит, ничего не купив.

customer journey map примеры

Путь клиента

Шаг 1: Определение этапов cjm
Чтобы понять, в чём кроется проблема этого шага, нужно определить поведенческие стадии, через которые проходит потенциальный покупатель — о них было сказано выше. В упрощённом варианте этот шаг выглядит как возникновение идеи, поиск и принятие решения.

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

Шаг 2: Цели проектирования CJM
Разобравшись с этапами, важно определить цели, которые человек преследует на каждом из них. Для составления карты, вы уже знаете, что:

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

Шаг 3: Взаимодействие с покупателем
Поиск точек соприкосновения. Если речь идёт о розничном онлайн-бизнесе, учитываются разделы с описанием товара, контактная форма, корзина и прочие важные места на сайте.

карта пути клиента пример

Путь клиента

Стандартный путь или шаги на сайте выглядит примерно так: каталог, просмотр описания и цены, добавление в корзину, оплата и выбор способа доставки. Чтобы точно понять, что посетитель делает на сайте, можно воспользоваться инструментами Google Analytics.

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

Шаг 5: Решение проблем пользователей при разработке CJM
Разработка методов решения проблем для клиентов. Совместно с командой предложите несколько путей, которые способны упростить пользовательский опыт: если посетитель не находит нужную кнопку, стоит сделать её более заметной.
cjm карта
Если от покупки отказались, потому что не нашли информацию о доставке, это тоже нужно исправить, возможно, даже добавить виджет с калькулятором стоимости и срока. Реализация данного шага, в вашей карте, значительно улучшит взаимодействие с вашим клиентом.

Шаг 6: Визуализация карты или CJM
На этом шаге все данные, полученные в процессе CJM анализа, иллюстрируются произвольным, удобным и понятным для всех членов команды способом. В результате вы подробно изучаете поведение клиента, находите слабые места и коллективно исправляете их — карта путешествия клиента справилась со своей задачей.
Дальше дело останется за малым: раздать задания подчинённым и улучшить свой сервис, для ваших клиентов.

Инструменты для разработки CJM

Нарисовать карту потенциального клиента можно в любом текстовом или графическом редакторе, при определённых стараниях — даже в Word. Есть и более популярные (и удобные) инструменты, которыми пользуются иллюстраторы и не только они:

Рекомендации для составления CJM

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

Создание команды
Если у вас большая компания, клиенты наверняка взаимодействуют с разными отделами: маркетологами, операторами службы поддержки, продавцами или консультантами. Чтобы карта была полной, привлекать нужно представителя каждого из уровней. Лучший результат достигается в команде.

Определение личности клиента
Ещё до составления Customer Journey Map нужно очертить личность клиента. И здесь компания может столкнуться с неоднородностью своей аудитории (или клиентов): если в магазине техники вы продаёте игровые ноутбуки и выпрямители для волос, возможно, покупатели этих товаров будут вести себя по-разному.
В таком случае следует создать карту для каждой целевой группы таких клиентов или предложить несколько поведенческих сценариев для одного макета.

Выбор вспомогательных инструментов для совершения шагов 
Для сбора и обработки информации для вашей карты, вам могут понадобиться дополнительные инструменты. Помимо упомянутого Google Analitycs, используются другие сервисы электронной коммерции, такие как Яндекс.Метрика и ручные методы: например, анкетирование, оценка отзывов и другие приёмы получения обратной связи.

Анкетирование для создания CJM клиента
Этот вспомогательный шаг можно проводить на сайте, в рассылке или даже через опросы в социальных сетях. Вопросы, которые нужно задать клиенту, зависят от ваших задач.
Вот некоторые примеры:

Независимо от количества предлагаемых продуктов задайте этот вопрос, чтобы:

Ответ поможет разобраться, на кого на самом деле ориентирован продукт и какие потребности он может удовлетворить.

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

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

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

Примеры Customer Journey Map

Существует несколько способов структурировать карту путешествия клиента, и иногда сложно разобраться с оптимальным форматом и показателями, которые стоит добавить. Это может быть линейная организация данных, простая таблица или сложная блок-схема.

Примеры карт пути клиента, которые могут быть полезны при разработке своего варианта, предложены ниже.

Таблица для гипотетической компании-разработчика мобильного приложения: она предлагает услугу крупным клиентам, работает по схеме B2B. Задача — оценить эмоциональный опыт потенциального партнёра, предупредить возможные тревоги и помочь принять правильное решение.

cjm клиента

Путь клиента cjm

Реализовывать этапы этапы CJM или карты путешествия клиента можно и в виде инфографики. В общих чертах карта для службы доставки продуктов и готовых блюд будет выглядеть так:
карта путешествия клиента
Некоторые компании предпочитают сложные блок-схемы путей клиента CJM, в которых прописывается несколько сценариев поведения пользователя. Такой макет можно создать в Miro, добавляя нужные блоки и создавая свою структуру карты:

cjm customer journey map

Путь клиента

Значимость карты пути клиента для бизнеса

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

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

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

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

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

 

Как сделать удобным сайт, если его целевая аудитория — «кто угодно»

Что происходит, когда ориентируются «на всех»

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

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

 

                             Главная страница сайта аэропорта Портланда: основной фокус сосредоточен на онлайн-табло

 

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

Часто информация распределяется по сайту в соответствии с тем, что разработчикам кажется важным. О чем-то они могут забыть, о каких-то вопросах, волнующих реальную аудиторию, просто не знать. Многое попадает в разные разделы сайта по остаточному принципу. Например, на сайте аэропорта «Внуково» информация для родителей, вылетающих с детьми разнесена между двумя разделами: «Пассажирам/ В аэропорту/ Пассажирам с детьми» и «Пассажирам / Безопасность и правила в аэропорту Внуково / Прохождение входного и предполетного досмотра / Путешествия с несовершеннолетними». Первый раздел содержит информацию о комнате матери и ребенка, и его, если быть внимательным, ещё можно найти. Второй содержит важную информацию о необходимых документах, но найти его можно, только если заранее знать, где он находится. Объяснить это можно только тем, что при наполнении сайта кто-то вспомнил, что информация для родителей с детьми должна быть, но о том, что этой информацией будет пользоваться живой человек, которому было бы удобно найти всё необходимое в одном разделе — не подумал.

 

                       Важная информация о пассажирах, путешествующих с детьми, спрятана глубоко в структуре сайта

 

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

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

 

Тогда возникает вопрос: как никого не забыть и при этом сделать так, чтобы всем было удобно? Никого не забыть помогут Персоны, а понять их потребности — CJM. Но обо всём по порядку.

Персоны

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

На начальном этапе вы можете провести мозговой штурм. Пусть все, кто связаны с вашим продуктом и с обслуживанием клиентов, соберутся вместе. Обсудите, какие люди и в каких жизненных ситуациях могут обратиться к вашему сервису. Запишите все полученные варианты на листочках. Скорее всего, вы увидите сходство между разными записями. Сгруппируйте их, а описание каждой из групп представьте как портрет живого человека. Так вы получите «Персону» или «Персонажа» — важный инструмент, который используют в своей работе и маркетологи, и специалисты по UX. Персоны помогают лучше понять, что нужно посетителям сайта, а ещё способствуют эмпатии. Помнить о потребностях «пассажира с лабрадором» проще, чем о потребностях «мужчин и женщин в возрасте 18-60 лет, путешествующих с домашним животным».

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

Для того, чтобы построить персонажей сайта аэропорта «Шереметьево» мы использовали:

  • информацию, собранную в интернете (отзывы пассажиров, обсуждения на форумах, справочные статьи, например, «Как развлечь ребенка в аэропорту»);
  • анализ конкурентных сервисов (других аэропортов, авиакомпаний и приложений для покупки билетов);
  • интервью с сотрудниками Шереметьево;
  • серию «коридорных» интервью с пользователями.

Обычно рекомендуется делать не больше 2-3 персонажей. Но, поскольку мы работали с сайтом, целевая аудитория которого — буквально все, персонажей получилось гораздо больше: восемь. Главным критерием для выделения персонажа стала жизненная ситуация, в которой он попадает в аэропорт.

 

                                                                              Примеры персонажей для аэропорта «Шереметьево»

 

После того, как персоны собраны, а их ключевые потребности определены, становится уже легче: понятно, что сайт надо делать надо делать именно для них, а не для «всех вообще». А чтобы сформулировать требования каждой персоны к функциональности, интерфейсу и информационному наполнению сайта, используют карту пути пользователя — CJM.

CJM — карта пути пользователя

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

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

Мы строили CJM для пассажиров, которые собираются улететь. Процесс вылета мы разделили на шесть шагов:

  1. подготовка к поездке;
  2. дорога в аэропорт;
  3. в аэропорту: регистрация;
  4. в аэропорту: контроль;
  5. в аэропорту: ожидание;
  6. в аэропорту: посадка на рейс.

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

 

                                                                                                      Пример CJM для одной из персон

 

Список требований персонажей, который вы получите из CJM, можно использовать, чтобы оценить уже существующий интерфейс, спроектировать новый и даже найти удачные решения у конкурентов.Например, требованием одного из персонажей для сайта аэропорта является возможность построить маршрут от текущего местоположения до другой интересующей его точки. Это может быть важно, например, транзитному пассажиру, чтобы понять, как добраться от места высадки с предыдущего рейса до места посадки на следующий. Или маме, которая захочет посмотреть, как добраться до нужного гейта от комнаты матери и ребенка. На сайте и в мобильном приложении «Шереметьево» схема аэропорта есть, но ее интерактивность ограничена: она не умеет строить маршруты. В поисках удачных решений смотрим, как нужная нам функция реализована на сайтах или в приложениях других аэропортов. На сайте «Внуково» схема аэропорта есть, но она совсем неинтерактивная, а из-за формата ее представления (сразу три этажа на одной картинке) пользоваться ей неудобно — это не то, что нам нужно. А вот на сайте аэропота Хитроу карта строит и показывает маршрут между двумя произвольно выбранными объектами — и эту идею можно взять на вооружение для дальнейшей работы.

 

                                                         Построение маршрута на сайте аэропорта Хитроу (мобильная версия).

 

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

Заключение

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

Если вы хотите, чтобы мы построили персонажей и создали CJM для вашего сервиса — напишите нам на info@usabilitylab.net или оставьте заявку на сайте.

Подписывайтесь на наш Телеграм, чтобы не пропустить выход новых, интересных статей!

CJM: разработка требований для сайта и приложения аэропорта “Шереметьево”

Специалист на проекте: Ольга Алтабаева

Коротко о проекте

Тип проекта: исследование пользователей; разработка требований к интерфейсу;
Продукт: сайт и приложение (App Store, Google Play) аэропорта «Шереметьево»;
Цель: разработать перечень требований к новому интерфейсу сайта и приложения аэропорта «Шереметьево»;
Длительность: 17 рабочих дней;
Особенности проекта: в проекте был использован метод Customer Journey Map и метод персон, позволившие детально проработать возможные пользовательские сценарии и на этой основе создать полный перечень требований к интерфейсу сайта/приложения современного аэропорта;
Результат: список персон, их пользовательских сценариев, возможные проблемы на их пути и перечень требований к интерфейсу сайта и приложения современного аэропорта, которые их устраняют.

Что такое Customer Journey Map (CJM)

Customer Journey Map (CJM), или «карта пути клиента», — это карта, на которой представлены основные каналы и точки взаимодействия клиента с компанией, его цели, потребности, мысли и чувства, которые он при этом испытывает и, что самое важное, проблемы (или барьеры), с которыми он при этом сталкивается. Наличие таких проблем — «болевых точек» — может повлиять на лояльность клиента или вынудить его уйти, предпочтя другой, более удобный и подходящий ему сервис.

             Часть одной из CJM, построенных на проекте (откройте иллюстрацию в новой вкладке, чтобы увидеть ее в полном размере)

 

Использование CJM позволяет:

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

Дальше мы расскажем, как строили CJM, чтобы определить требования к новому интерфейсу сайта и мобильного приложения аэропорта «Шереметьево».

Шаг 1. Определение цели и направления исследования

Как правило, CJM используется для достижения одной из двух целей:

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

На данном проекте мы работали с уже существующими сервисами — сайтом и приложением аэропорта «Шереметьево». Целью проекта было составить требования к новой версии сайта и мобильного приложения аэропорта.

С учетом цели выбирается направление исследования. Мы определяем:

  • «Point of view» — чья точка зрения будет рассматриваться: какие именно клиенты, персоны нас интересуют;
  • «Scope» — объем исследования: нужно проанализировать весь путь клиента при взаимодействии с сервисом или сфокусироваться на какой-то определенной его части;
  • «Focus» — что находится в фокусе нашего внимания: мы рассматриваем опыт клиента или процессы в организации.

Мы рассматривали CJM с точки зрения клиента аэропорта Шереметьево: анализировали весь путь взаимодействия клиента с сервисом, начиная от подготовки к поездке (планирование поездки, сбор багажа и т.д.) до прибытия в аэропорт прилета.

Исходя из целей и направления исследования, мы определили основные этапы проекта:

  1. определить с заказчиком задачи сайта и приложения с точки зрения бизнеса;
  2. выделить основные персоны пользователей сайта и описать их потребности, цели и ограничения;
  3. создать основные сценарии процесса поездки для выбранных персон;
  4. сформулировать требования к функциональности, навигации и информационному наполнению.

Шаг 2. Сбор данных

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

Кабинетное исследование включает в себя изучение информации, которую можно получить, не покидая офиса:

  • из в открытых источников — например, анализ аэропортов-конкурентов, посты пассажиров об их опытах перелетов в соцсетях, статьи в медиа и т.д.;
  • в самой компании — например, база отзывов пассажиров, внутренняя документация организации, результаты прошлых исследований, если они есть).

Полевое исследование включает в себя:

В нашем исследовании для сбора информации о пользователях и возможных ситуациях, в которые они попадают в поездках, мы использовали:

  • информацию, собранную в интернете (отзывы пассажиров, обсуждения на форумах, справочные статьи, например, «Как развлечь ребенка в аэропорту»);
  • анализ конкурентных сервисов (других аэропортов, авиакомпаний и приложений для покупки билетов);
  • интервью с сотрудниками Шереметьево;
  • серию «коридорных» интервью с пользователями.

Шаг 3. Персоны (персонажи)

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

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

Вот список персонажей, который мы составили:

  1. пассажир, путешествующий по работе;
  2. семья с двумя детьми;
  3. пассажир с собакой;
  4. пассажир с ограниченными возможностями;
  5. иностранный турист;
  6. трансферный пассажир;
  7. встречающие;
  8. провожающие.

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

Например, вот как выглядела карточка персоны для пассажира путешествующего по работе:

                                                                         Карточка персонажа «Пассажир, путешествующий по работе»

 

Данные из исследования позволили выделить разные типы персон, с разными потребностями и возможными проблемами. Нам важно было получить максимально полную картину аудитории, учесть ее потребности и сохранить лояльность всех ее представителей при проектировании сервиса.

 

                                                                       Карточка персонажа «Пассажир с ограниченными возможностями»

 

                                                                                                       Карточка персонажа «Провожающий»

 

Шаг 4. Пользовательские сценарии и построение CJM

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

Для начала мы разбили весь путь на основные этапы:

  1. подготовка к поездке;
  2. дорога в аэропорт;
  3. в аэропорту: регистрация;
  4. в аэропорту: контроль;
  5. в аэропорту: ожидание;
  6. в аэропорту: посадка на рейс.

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

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

 

Часть CJM для персонажа, путешествующего с домашним питомцем (откройте иллюстрацию в новой вкладке, чтобы увидеть в полном размере)

 

Кроме того, мы отдельно рассмотрели непредвиденные ситуации, в которые могут попасть все и/или определенные персоны:

  1. отмена рейса;
  2. задержка рейса на несколько часов;
  3. задержка рейса на долгое время;
  4. потерялся ребенок;
  5. проблемы со здоровьем;
  6. опоздание на рейс;
  7. потеря багажа.

Например, вот один из сценариев непредвиденной ситуации для персонажа с домашним животным:

  • Ситуация: Проблемы со здоровьем
  • Цель: Получить квалифицированную помощь
  • Шаги:
    • заметить, что животное ведет себя необычно (вялое, слишком возбуждено, есть какие-то признаки недомогания;
    • найти пункт ветеринарного контроля
  • Проблемы и вопросы: Специфических проблем нет

Использование CJM: Разработка решений

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

Так, в нашем примере для персоны, путешествующей с питомцем, был предложен ряд идей/требований для сайта и приложения. Вот некоторые из них:

  1. В ходе обновления навигации, поместить информацию о перелете с животными в разделы «Вылетающим» (подраздел «Перелет с животными»), «Нужна помощь?», «Прилетающим» и в разделе с описанием возможностей добраться до аэропорта.
  2. В разделе «Вылетающим» в подразделе «Перелет с животными» должно содержаться:
    • Схема последовательного прохождения всех этапов подготовки к полету в аэропорту (регистрация, досмотры, ветеринарный контроль, таможенный контроль, паспортный контроль, посадка) с описанием особенностей их прохождения с животными. Подробное описание прохождения ветеринарного контроля.
    • Отдельный подраздел с описанием подготовки животного к полету:
      • Списки нужных документов в зависимости от класса животного (животное-компаньон, собака-поводырь, экзотические виды животные, птицы) со ссылками на нормативные документы и образцы. Также требуемые документы разделены на группы: по территории РФ и за рубеж.
      • Требования к перевозке/клетке: размер, материал, оснащение;
      • Контакты ветеринарных служб аэропорта;
      • Советы по перевозке;
      • Рекомендуется разместить показательное видео с процессом доставки животного на борт при транспортировке в багаже. Это поможет снизить тревогу пассажиров за своих питомцев.
  3. ….

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

Что потом

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

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

Если вы хотите, чтобы мы провели исследование ваших пользователей, оценили ваш продукт или спроектировали для вас интерфейс — напишите нам на info@usabilitylab.net или оставьте заявку на сайте.

Автор текста: Мария Киоса

Подписывайтесь на наш канал в Телеграме, чтобы не пропустить выход новых статей

Актуален ли метод создания персонажей для реализации UX-стратегии?

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

Ранние дни веб-дизайна

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

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

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

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

Персонажи как инструмент дизайна

Одним из самых ранних методов моделирования, широко использовавшихся в стратегии проектирования веб-дизайна, были персонажи.
Впервые об таком способе разработки сайтов заговорил Алан Купер, а Ким Гудвин так объяснила его на примере сайта самого же Купера:

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

Ким Гудвин. Совершенствование ваших персонажей («Perfecting Your Personas» by Kim Goodwin)

У меня была возможность провести много проектов с использованием персонажей для крупных компаний США, Европы и Южной Америки.
Мне нравятся такие проекты, потому что они позволяют мне хорошо понять желания и ожидания ключевого сегмента пользователей ещё до того, как я начну создавать для них тот или ной продукт.
В ходе создания персонажей, я исследую такие вопросы, как:

  • Благодаря каким свойствам бренд обретает поклонников?
  • Почему разные типы пользователей ведут себя по-разному при использовании веб-сайтов и мобильных приложений?
  • Какие факторы влияют на совершение покупки или другие типы поведения, связанные с конверсией?
  • Какие характеристики отличают одну группу пользователей от другой с точки зрения проектирование опыта взаимодействия?

Проекты с использованием персонажей позволили мне проводить много, как мне кажется, интересных, групповых мероприятий:
домашние интервью, видео-дневники, совместные покупки с незнакомыми пользователями (прим. переводчика: shop-alongs) и составление карты пути потребителя
(прим. переводчика: journey mapping, более подробно о методе см. здесь) Мне нравится даже процесс анализа данных в проектах по созданию персонажей: в течение этого этапа мы пересматриваем все видео и интервью,
которые у нас есть, и размечаем их тегами, отражающими темы, возможности и паттерны, которые и выявляют различия между будущими персонажами. Затем мы развешиваем фотографии,
артефакты и цитаты по всем стенам нашей рабочей комнаты, чтобы разобраться и структурировать собранные нами данные, используя методологию «обоснованной теории» (прим. переводчика: grounded theory,
более подробно о методе см. здесь).

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

  • веб-аналитика,
  • АБ-тестирование и многофакторное тестирование,
  • гибкие и бережливые (agile/lean) методологии разработки.
Некоторые рассматривают метод создания персонажей как анахронизм,
который мы должны исключить из нашего набора инструментов для создания стратегии UX.

Веб-аналитика

Первый аргумент, который люди приводят для обоснования отказа от метода персонажей — это доступность подробной веб-аналитики, а также постоянное совершенствование аналитического инструментария. Инструменты веб-аналитики прошли долгий путь, начиная с ранних версий, который давали просто логи просмотров страниц со списками URL и количеством посещений каждой страницы. Но сейчас инструменты аналитики помогают создать значительно более точное представление о поведении пользователя и могут очень быстро предоставлять совокупные данные, и, так как сессий много, эти данные статистически довольно точны. Если прописать для страницы правильный код, аналитика сможет дать нам информацию о стоимости каждого элемента веб-страницы (в процентах или в валютном эквиваленте). Так мы сможем понять, является ли тот или иной элемент действительно полезным для пользователя, или он находится на сайте только потому, что маркетолог или руководитель компании хочет его там видеть.

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

Я согласен с тем, что мы должны полностью использовать возможности аналитических инструментов. На самом деле, почти в каждом проекте, в котором я участвую, еще на ранней стадии я фокусируюсь на изучении любой доступной аналитики (и других количественных данных). Однако, и у веб-аналитики есть свои ограничения.

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

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

Другой недостаток аналитического подхода заключается в том, что он игнорирует принципы работы UX-дизайнера. Мне ещё не доводилось видеть дизайнера, который с нетерпением ждал бы отчёта аналитики за последнюю неделю. Начать с того, что это — своего рода объективная оценка твоей работы, оценка того, насколько твой дизайн хорош. Это пугает. Ещё более устрашающей является мысль, что числа диктуют нам направление работы. Дизайнеры, как правило, не считают обработку количественных данных своей первостепенной задачей — они скорее хотят быть креативными. Для них важно понять проблему дизайна и найти решение.

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

В связи со всеми этим причинам я советую своим клиентам применять смешанный подход. Мы используем аналитику и другие доступные нам пользовательские данные, чтобы получить исходный набор характеристик и информацию о поведении пользователей. Затем мы делаем большой шаг в сторону развития исследований персонажей — интервьюируем людей у них дома, проводим дневниковые исследования (просим людей вести видео-дневники) и наблюдаем за их совместными покупками с другими пользователями. На основе всех этих данных мы формируем обоснованные
и надежные пользовательские архетипы с действенными и различающимися наборами характеристик. Наконец, мы усердно работаем над способами связи полученных архетипов с аналитикой, и пытаемся увидеть, как полученные нами паттерны поведения соотносятся с характеристиками, отслеженными с помощью этих аналитических данных. Эта информация позволяет нам высчитать приблизительное количество пользователей, соответствующих каждому архетипу, и то, как именно эти пользователи откликаются на перемены в дизайне новых версий. Благодаря аналитике мы можем также узнать, что нам нужно изменить в персонажах. Так, мы будем уверенны в том, что получившиеся архетипы точно отражают реальный паттерн поведения, присущий тому или мной сегменту пользователей.

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

A/B и многофакторное тестирование

Второй аргумент, который выдвигают мои коллеги в пользу архаичности метода персонажей, является A/B или многофакторное тестирование (прим. переводчика: более подробно об этих методах можно прочитать здесь). Сторонники такого мнения утверждают, что подход с персонажами чрезвычайно неточен и не опирается на количественные данные, потому что персоны, как правило, основаны на небольшой выборке, и дизайнеры обычно должны выдумывать решения, которые удовлетворят персонажей. Они также утверждают, что несколько архетипов часто пересекаются, и в результате не всегда можно понять, какой дизайн будет удобен для какого-то конкретного пользователя. Потому разработчики предлагают другой подход: проводить тестирование различных типов дизайна, и, получив количественные результаты, реализовывать наиболее успешный с точки зрения количественных данных дизайн.

Я согласен с тем, что A/B и многофакторное тестирование – очень важные инструменты. Оно позволяет понять, какой из нескольких вариантов дизайна лучше выбрать, опираясь на актуальные результаты. Однако проблема заключается в том, что результаты тестирования все же не указывают вам на единственное верное решение. А тем временем, вы должны завершить дизайн и оптимизировать его до такой степени,
чтобы сайт или приложение можно было проверять на реальных пользователях. Коротко говоря, A/B тестирование позволяет понять, какое из существующих решений лучше, но оно не даёт общего понимания того, каким должен быть опыт взаимодействия пользователя с продуктом.

Другая проблема заключается в том, что A/B и многофакторное тестирование стоит достаточно дорого. Мало того, что для него нужен целый набор полностью законченных вариантов дизайна, которые при этом могут оказаться провальными, вам ещё нужно привлечь немало людей и дорогое программное обеспечение, чтобы провести всё это (прим. переводчика: На самом деле, это не совсем так: существуют бесплатные инструменты, позволяющие быстро изменять небольшие элементы сайта, например, размер кнопки. К тому же, провести такое тестирование несложно — нужно лишь, чтобы сайт имел некоторую посещаемость).

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


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

Гибкие (agile) и бережиливые (lean) подходы к разработке

Это третий аргумент, который приводят мои коллеги против метода персонажей. Они говорят, что гибкий подход не даёт им нужной свободы действия для того, чтобы сформулировать типы персонажей достаточно хорошо. Метод персонажей не позволяет вписаться в спринт. UX-профессионалы, приспосабливающиеся к agile-методам, говорят, что им очень сложно успевать создавать персонажей, разрабатывать функции для предстоящего спринта
и одновременно не забывать добавлять ключевые функции в главный список задач. Нет времени и для создания промежуточных артефактов — например, персонажей, необходимость которых многие разработчики вообще не понимают.

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

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


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

Заключение

Не успел появиться метод создания персонажей в UX-дизайне, как многие стали предсказывать его скорую «кончину». Но несмотря на то, что оптимальный подход для создания и использования персонажей всё ещё развивается, продуктивность метода создания персонажей не уменьшилась благодаря доступности новых данных и методов управления. Напротив, персонажи стали ещё более полезным инструментом, так как они как бы «очеловечивают» собранные данные и содействуют применению подхода, ориентированного на пользователя даже в контексте быстрых процессов разработки.

Контакты
Россия
129085, г.Москва, ул. Годовикова д.
9, стр. 2, подъезд 2.1, офис 2.22