Слайды воркшопа с Летнего Аналитического Фестиваля (2014) про Customer Journey Mapping. На воркшопе мы говорили о разнице между продуктом и услугой, а том, что такое целостный и непрерывный UX при, почему он важен, с какой стороны к этому подходит бизнес-аналитик, а с какой -- UX-дизайнер. И поговорили про инструмент, который может помочь объединить усилия тех и других для того, чтобы создать качественную услугу (или улучшить существующую).
9. ЛАФ 5, 2014 г.
Что должен понимать BA, чтобы у UXD был
шанс выполнить свою работу хорошо
Офигенный UX
Нормальный UX
Бедовый UX
Инструмент
совместной
работы
10. ЛАФ 5, 2014 г.
Услуга разными глазами
Принять
заказ
Проверить
наличие
товара
Подтвердить
заказ
Собрать и
отправить
заказ
Уведомить
клиента об
отправке
Получить
подтверждение
о доставке
Закрыть
заказ
Бизнес-процесс
Услуга
Офомить
заказ
Получить
подтвержден
ие заказа
Получить
уведомление
об отправке
Получить
заказ
Косвенная обратная связь
Услуга глазами UXD
Услуга глазами
аналитика
Клиент
11. ЛАФ 5, 2014 г.
Customer Journey Map
11
itmine
“Инструмент визуализации взаимодействия
пользователей с вашим продуктом.
14. ЛАФ 5, 2014 г.
Для чего CJM?
14
itmine
• Комплексный и непрерывный UX;
• Создание нового и инновационного
взаимодействия;
• Повышение лояльности;
• Увеличение конверсии;
• Прозрачная ответственность на каждом шаге.
15. ЛАФ 5, 2014 г.
Виды CJM
15
itmine
• Линейный;
• Нелинейный;
• Временной.
17. ЛАФ 5, 2014 г.
Шаг 1
17
itmine
Выделяем все точки контакта и каналы
взаимодействия человека с нашим продуктом
18. ЛАФ 5, 2014 г.
Шаг 2
18
itmine
Для каждой точки контакта выявляем:
+ Степень критичности (самые важные исправляем в первую очередь).
• Описываем процесс:
• Цели человека (чего хочет добиться);
• Ожидаемый результат;
• Критерии успеха (что должно произойти, что бы он перешел к следующему шагу?);
• Действия пользователя (идеальный сценарий);
• Проблемы и барьеры.
• Фиксируем KPI;
• Идеи и улучшения.
+ Кто за что отвечает;
• Все возможные каналы взаимодействия;
20. ЛАФ 5, 2014 г.
Где брать данные?
20
itmine
• Собственный опыт (“тайный покупатель”).
• Знания собственные и команды;
• Прямое общения с ЦА (интервью, опросы,
анкетирование, наблюдение);
• Косвенное исследование (веб-аналитика,
анализ обращений в тех. поддержку, отзывы в
соц. сетях/форумах);
• Конкуренты и аналогичные системы;
• Юзабилити-тестирование;
Если не брать в расчет стартапы, проектирование услуги осуществляется в рамках компании, которая уже обладает своей корпоративной архитектурой. В одних случаях - это устоявшаяся архитектура, в других она находится в процессе изменения. Но в любом случае это для нас означает, что уже определены и существуют бизнес процессы, есть ИТ инфраструктура, которая дает инструменты для процессов и должна их дать для проектируемых услуг.
Зачастую проектирование услуги осуществляется тем бизнесом, который может ее предоставить. Т.е. является владельцем соответствующих бизнес-процессов. Бизнес при создании услуги руководствуется своими целями и своим видением, не заморачиваясь на то, как эту услугу хотели бы видеть клиенты, будет ли она им удобна или нет. При этом бизнес не готов идти на изменения процессов или более не менее значительную модификацию инфраструктуры. Такое отношение к услуге является утилитарным. Она попросту становится интерфейсом клиента к процессам с целью что-то получить от клиента или что-то ему передать. Для того, чтобы сделать такую услугу удобной клиенту, привлечение UXD может уже мало помочь, поскольку максимум, что можно сделать – оптимизировать интерфейсы взаимодействия клиента с компанией в рамках оказываемой услуги. Это бедовый UX.
Но что нужно для того, чтобы спроектировать качественную (в глазах Клиента) услугу? Необходимо иметь возможность влияния на процесс и инфраструктуру его выполнения.
В контексте корпоративной архитектуры минимально комфортная точка для проектирования услуги – уровень бизнес-процессов. Для нас это означает, что мы можем, проектируя услугу, влиять на процесс (до разумных пределов) и инфраструктуру.
Но еще лучше, когда об услугах мы задумываемся на стратегическом уровне – на уровне определения целей компании. В этом случае само развитие бизнеса происходит под общей идеей создания и развития слоя клиентских услуг, а корпоративная архитектура выстраивается ориентированной на реализацию этого слоя.
Почему правильный вариант – начинать проектирование услуг на уровне целей компании?
Для этого необходимо посмотреть на пирамиду клиентского опыта. Клиент обладает своим жизненным опытом, который определяет его цели. Понимая цели клиента, мы понимаем, что можем ему предложить такого, чем он будет с удовольствием пользоваться. По сути личные цели нашей целевой аудитории определяют цели нашего бизнеса.
Понимая цели клиента, мы можем понять его ожидание и его видение того, какими должны быть услуги. Это тот уровень знания, который определяет образ услуги и, как следствие, влияет на образ бизнес-процессов компании и ее инфраструктуру.
Нижний уровень пирамиды клиентского опыта, критерии удовлетворенности, влияет на особенности реализации услуги.
CJM – это инструмент, который позволяет на ранней стадии проектирования или модификации корпоративной архитектуры смоделировать услугу, оценить удовлетворенность клиента и при необходимости оптимизировать ее.
Кто должен проектировать услугу?
С одной стороны основой услуги является бизнес-процесс. Но, проектируя услугу от процесса, мы ее фактически не проектируем, а констатируем в том виде, в каком она из этого процесса вытекает. Т.е. она не учитывает особенности целевой аудитории, а просто является интерфейсом между компанией и клиентом.
Для того, чтобы услуга отвечала ожиданиям целевой аудитории, должны быть выполнены два условия:
при проектировании услуги необходимо иметь возможность модификации процессов и инфраструктуры в случае, если это потребуется для оптимизации услуги под особенности целевой аудитории;
оптимизацию услуги должны осуществлять специалисты, понимающие толк в том, как понимание опыта пользователя конвертировать в UXD.
Поэтому проектирование услуги должно представлять собой взаимодействие БА и UXD со следующим распределением зон ответственности:
БА проектирует процесс и находит возможности его модификации под потребности оптимизации услуги;
UXD оптимизирует услугу и формирует требования к модификации процесса для этой оптимизации.
Проектирование услуги - это поиск компромисса между желаниями Заказчика и конечного пользователя. И этот компромисс БА и UXD должны искать совместными усилиями.