5 шагов в UX-нирвану финансовых сервисов

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

Ожидания клиентов по отношению к качеству услуг меняется в зависимости от множества факторов:

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

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

Шаг 1. Реагируй на жалобы

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

Что еще нужно делать:
  • Анализировать обращения в альтернативные каналы. Почему клиент позвонил в контакт-центр и пытается узнать сумму минимального платежа по кредитной карте, а не смотрит эту информацию в мобильном приложении? Почему клиент пошел оплачивать квитанцию за коммунальные услуги с карты, хотя мог бы то же самое сделать в интернет-банке? Такие обращения в альтернативные каналы не являются жалобами, но могут быть сигналами, что ваш цифровой сервис не так хорош, как вы думаете.
  • Сформировать объективную метрику удовлетворенности пользователей и отслеживать ее изменения с течением времени. Анализировать, что не так у клиентов, которые ставят низкие оценки.

    Шаг 2. Делай, как привыкли люди

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

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


    Сервисы с одним ключевым сценарием использования:

    • Gmail: верхнее бургер-меню
    • Яндекс.Карты: нижнее бургер-меню
    • Авито: верхнее бургер-меню
    • WhatsApp: верхние табы
    • Telegram: верхнее бургер-меню

    Сервисы с несколькими ключевыми сценариями:

    • Facebook: таб-бар
    • ВКонтакте: таб-бар
    • Инстаграм: таб-бар
    • Сбербанк: таб-бар

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

    Шаг 3. Спрашивай и исправляй перед запуском

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

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

    Шаг 4. Строй Customer Journey Map

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

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

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

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

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

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

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

      Шаг 5. Говори с клиентом по-человечески

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

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