Правила игры изменились для технических подразделений, которые внедряют самообслуживание или портал услуг для своих заказчиков. Если раньше люди использовали имеющиеся инструменты самообслуживания или звонили в службу поддержки, то сегодня технологии порталов обеспечивают тот же уровень удобства и производительности, как мобильные приложения или веб-сайты. Это, в сочетании с привычным пользовательским опытом в мире мобильных приложений, создало среду, в которой наши клиенты больше не хотят работать с плохо спроектированным сервисным порталом. Давайте посмотрим, какие возможности есть в части создания пользовательского интерфейса.
Преобразование технического мышления в DX/UX-мышление
ИТ-специалисты очень отличаются от маркетологов и графических дизайнеров, но теперь нам нужно создать портал, используя методы, которые использовали бы они.
Многие специалисты в области сервис-менеджмента изо всех сил стараются проектировать портал услуг, исходя из точки зрения заказчика. Организации могут наблюдать результат этого труда, когда у них возникают проблемы с тем, чтобы заставить конечных пользователей использовать портал.
Пользователи не стремятся использовать неудачные ИТ-порталы по нескольким ключевым причинам:
- В процессе поиска им не удаётся найти то, что они искали. Язык, который используют в ИТ, включающий технические термины, отличается от того, который пользователи будут использовать при поиске. Результатом является невозможность найти конкретный специфический тип запроса путём поиска.
- Они не могут найти то, что им нужно, даже в процессе просмотра. ИТ часто систематизируют каталог, основываясь на своём представлении об услугах и их организации, что затрудняет навигацию по категориям каталога и задачу поиска необходимого.
- Формы слишком сложные. Когда заказчики находят то, что им нужно, они просто отказываются от заполнения форм или даже не пытаются их заполнить.
- Их отпугивает дизайн портала и неудобство его использования. Заказчики только взглянули на портал и решили, что это лажа или там настолько много ошибок, что пытаясь отправить запрос, они заранее предполагают, что никогда не получат то, что им нужно.
Клиенты часто правы в своих оценках. Имейте в виду, что люди, проектирующие детали, как правило, технические специалисты и мыслят с точки зрения исполнителя. В то время как многие запросы могут быть выполнены, без дополнительного обращения к заказчику, некоторые технические услуги часто требуют дополнительной консультации. В этих случаях заказчику часто трудно ответить на массу технических или детализированных вопросов, что влияет на его мнение о портале. Поэтому важно, чтобы портал был простым в использовании.
Digital experience (DX) – подходящий термин для описания взаимодействия клиента с вашей организацией посредством любой формы цифровых технологий. Он может включать в себя ваш цифровой брендинг, услуги, которые вы предлагаете в цифровом виде, и вашу компетентность в их поддержке.
Подобно DX, UX охватывает пользовательский опыт при использовании ваших цифровых служб. С точки зрения портала услуг, это ваш дизайн и пользовательский опыт, полученный при попытке воспользоваться порталом. Если поиск и заполнение формы запроса отнимает 20 минут, принятие портала будет медленным или трудным. Вспомните ситуацию, когда вы заказывали что-то онлайн и не могли понять, как сделать следующий шаг – оформить заказ или положить в корзину что-то еще. Вы знали, что должна быть кнопка, но не могли её найти. Это все часть UX-дизайна.
В ситуациях, когда у ИТ нет дизайнеров, подразделения маркетинга и коммуникаций часто готовы помочь с брендингом и дизайном, и готовы представлять заказчика во время работы над дизайном. Я покажу два шага, которые в DX используются для разработки веб-интерфейсов или интерфейсов приложений: отображение персонажей и отображение путешествий.
Осознайте участников/персонажей ваших взаимодействий и их путешествие вместе с вами и вашими инструментами
Персонаж может характеризоваться ролью, которую он играет в организации, услугой, которую он потребляет и/или предоставляет, его онлайн-личностью, и даже его симпатиями и страхами. Когда общие для DX и UX ключевые персонажи определены; рассуждайте о них, как о ключевых заинтересованных сторонах, которые будут использовать конечный продукт, в данном случае, портал услуг. Персонаж может представлять одного человека или группу людей с одной ролью.
При отображении персонажа создайте шаблон, содержащий следующие ключевые точки данных (смотрите на рисунке):
- Их имена, должности и роли
- Услуги, которые они предоставляют/в рамках организации
- Услуги, которые они потребляют (как деловые, так и личные, такие как услуги льгот)
- Их тип личности
- Их взаимодействие / стиль общения или подход к обслуживанию
Сбор этих данных даёт информацию о вовлеченности, помогая зафиксировать предпочтения в выборе каналов коммуникации. Не все готовы пользоваться порталом, хотя процент пользователей растёт с ростом числа мобильных приложений и пользователей Интернет. Важно найти причины, не дающие людям пройти путь, который они выбрали. Например, можно использовать длительное время ожидания для объявлений о возможности использовать портал, чтобы подать заявку, если она не критически срочная.
Используйте e-mail маркетинг, чтобы показать, почему портал лучше, чем отправка электронной почты. Понимание предпочтений пользователей поможет при разработке соответствующих маркетинговых кампаний.
Информация о ваших персонажах и их путешествиях (если в технических терминах – вариантах использования) обычно собирается посредством интервью. При работе с одним человеком в роли, личное интервью – это просто. Но для сбора информации о группе людей, представляющих один тип персонажей, необходима стратегия. В этом случае эффективными могут быть фокус-группы. Группа должна состоять максимум из 10-12 человек и в этом случае, собеседование проводится в формате дискуссии с группой участников.
При работе с фокус-группой важно помнить, что не у всех будет одинаковый личностный или сервисный подход. Важно собрать любые / все разнообразные сервисные подходы и типы личности, даже если это означает документирование трех или четырех персонажей для одной группы людей. В конечном счете, дизайн должен охватывать всех из них.
В дополнение к пониманию того, кто будет использовать портал и его подходы к обслуживанию, важно в процессе собеседования обсудить варианты использования. Рекомендуется подготовить карту путешествия для тех, кто будет пользоваться порталом. Например, не только, когда использовать его, почему и как, но также определить конкретные его применения, например, адаптация нового сотрудника или даже что-то совсем простое, как запрос компьютера или ПО.
На следующем шаге, создавая карту путешествия по их опыту и впечатлениям от текущего состояния, можно будет использовать это знание.
Составление карты путешествий – довольно простой процесс, использующий Канбан для сопоставления шагов, которые может пройти персонаж при взаимодействии с порталом. Как правило, на карту наносится опыт, как «на сцене», так и «за кулисами»: показывается путешествие конечного пользователя (на сцене) и исполнителей (за кулисами).
Следующий шаг, после того, как вы построили диаграмму опыта для персонажа, нужно добавить свои эмоции в процесс. Добавление эмоций к опыту, показанному ранее, может выглядеть следующим образом:
Эмоции добавляют фактор, необходимый для улучшения или преобразования опыта. В приведенном примере улучшается существующий портал. Вы можете легко заметить, что есть несколько улучшений, которые могут быть сделаны для принятия портала:
- Добавление единой точки входа на портал.
- Улучшение поиска и категоризации. Если подключение нового члена команды происходит часто, рассмотрите возможность добавления этого на главную страницу.
- Похоже, что есть возможность оптимизировать сам запрос, чтобы помочь получить всё необходимое сразу в одном пакете (или гарантировать, что в случае, если регулярно запрашивают одно и то же, когда они берут нового человека, дизайн портала позволит им сохранить всё это в виде пакета для будущих обращений).
- Наконец, для руководителя ИТ-подразделения очень важно видеть обновления и прогресс на протяжении всего процесса. Чтобы обеспечить это, иногда исполнителям необходимо значительно изменить свой подход к документированию задач и регулярности обновления информация.
Карта путешествий за кулисами может показать аналогичные возможности для улучшения. С одной стороны, если исполнители не обновляют тикет, то нижестоящие исполнители также не будут вовлечены в актуализацию статуса. С одной стороны, повторные запросы в службу поддержки для получения обновлений статуса запроса будут неприятны потребителю и, следовательно, тем, кто принимает вызовы, особенно, если у них тоже нет способа получить актуальную информацию.
Цель составления карт путешествий состоит в том, чтобы активно взаимодействовать с людьми, которые будут использовать портал, как потребителями, так и исполнителями, с целью определения деталей изменения дизайна, которые позволят получить лучший пользовательский опыт. Не важно, кто исполняет процесс, опытный сотрудник или новичок, важно, чтобы потребности пользователя были осознанными на каждом шаге его путешествия.
Преимущества подхода DX/UX
В конечном итоге, DX / UX не является огромным изменением для хороших практик разработки инструментов, которые люди будут использовать. Персонажи и карты путешествий просто формализуют процессы, используемые для этого. Они делают определение требований и создание потока изменений дизайна проще для конечных пользователей, убирая технические аспекты из обсуждений. Проще говоря, это позволяет говорить с пользователями на понятном им языке.
Однако один урок необходимо извлечь. Интернет и телефон привели к такому уровню ожиданий, который ИТ необходимо достичь. ИТ теперь конкурируют с поставщиками инновационных решений, которые занимают наше пространство, и теперь нам нужно быть такими же инновационными, как они. Знакомство с чужим цифровым опытом – один из способов, как этого достичь.
Применение DX/UX-методов полезно везде в ИТ и может/должно применяться ко всем предоставляемым услугам. Это будет заставлять ИТ быть инновационными и создавать решения, которые будут любить конечные пользователи.
Оригинал: Bring DX/UX to the Service Portal, автор Филис Друкер (Phyllis Drucker)
