Кейс «Модульбанка»: Как использовать аналитику и юзабилити-тестирования для проектирования сервиса11.08.2016 09:38

Основными источниками знаний о поведении пользователей являются аналитика и юзабилити-тестирования. А вот как и в какой последовательности применять эти инструменты для многих остается загадкой. Сегодня я расскажу на примере «Модульбанка», как получить максимальную пользу из совместного применения этих инструментов.

Немного о мифах

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

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

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

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

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

Первые шаги

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

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

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

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

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

Ни одна аналитика не могла бы дать ответ на вопрос, почему так получается. А вот юзабилити-тесты показали как думают пользователи:

1. Новая форма платежа непривычна — в ней слишком мало полей по сравнению со старым вариантом. Предыдущая платежка с 50-ю полями для заполнения больше похожа на печатный документ. На новую кидаешь взгляд, возникает мысль «что-то здесь непонятное» и уходишь на старый вариант.
2. Непонятно, как работает новая форма. Лучше сделаю, как раньше. На самом деле, у нас была встроена функция автозаполнения реквизитов контрагента. Поиск происходил, когда человек начинал вводить название юр лица. Реквизиты подтягивались сами собой, если контрагент был заведен в системе ранее. Теперь то мы добавили функцию поиска любого даже незаведенного контрагента по ИНН и реквизиты автозаполняются.
3. Баг это или нововведение — не важно, деньги моей компании нужно пересылать по проверенному пути. Деньгами своими, как физлица я бы еще рискнул, но не деньгами компании. Не стоит пробовать эту инновационную форму, в ней не видно половины полей, а это грозит тем, что платеж вернется и сроки оплаты могут быть прострочены или деньги вообще пропадут.

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

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

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

Как с этим жить

В декабре прошлого года мы выпустили вторую версию интернет-банка. Перед ее запуском провели серию юзабилити-тестов по новым интерфейсам — найденные ошибки сразу исправляли. И снова проводили тестирование. Затем настроили аналитику. И что вы думаете? После запуска нового портала обнаружили еще десяток узких мест:

1. Оказалось, что на 19% запросов поиска выдаётся «not found». Пользователи вводили туда что-то эдакое, что система не находила. Собрать эти данные мы не можем в силу закона о персональных данных. Поэтому мы опять пошли искать ответы и делать юзабилити-тесты и опросы пользователей. Однако, по сравнению с первой версией портала, меню поиска стало нативнее. В нововй версии им пользуются в 2,3 раза чаще.
2. Более 60% просмотров приходятся не на главную страницу интернет-банка, где размещен дашборд и различные графики, а на страницу «Счета и операции». Однако, эти просмотры — короткие, буквально заход и выход, а на главной длительность пребывания большая. После общения с пользователями выяснилось, что «Дашборд» дает информацию, которую они долго изучают — графики, поступления, списания, чат. А раздел «Счета и Операции» собрал в себе частые действия с быстрым доступом. Зашел на страницу — нажал на кнопку и перешел в другой слой. Хорошо это или плохо — вопрос с которым еще предстоит разобраться.
3. Реквизиты. Аналитика показала, что в этом слое было много просмотров, много уникальных посетителей и мало успешных действий. После тестов и опросов выяснилось, что банки в принципе не понимают, что у предпринимателей есть еще несколько действий, связанных с реквизитами, которые не учтены в интерфейсах.

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

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

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

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

Минусы юзабилити-тестов

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

Функции, которыми по данным аналитики пользуются до 7–10% пользователей очень трудно проверить с помощью юзабилити-тестов. В выборку юзабилити-теста могут вообще не попасть люди, которые пользуются этой функциональностью. Это значит, что под фичу нужно специально искать тех, кто её использует. Либо углубляться в первопричину у тех, кто её не использует, чтоб понять почему это происходит, можно ли это исправить или лучше от этого отказаться.

В нашем случае показателен пример тестирования iOS- и Android-приложений. Пользователи этих платформ очень интересно отличаются в поведении. У нас для этого даже есть специальное название — «занимательная аналитика».