{ "author_name": "Philipp Kontsarenko", "author_type": "self", "tags": ["\u043a\u0435\u0439\u0441\u044b","\u043c\u043e\u0434\u0443\u043b\u044c\u0431\u0430\u043d\u043a","\u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0435_\u0430\u0443\u0434\u0438\u0442\u043e\u0440\u0438\u0438"], "comments": 14, "likes": 12, "favorites": 9, "is_advertisement": false, "section_name": "default", "id": "17556", "is_wide": "1" }
Philipp Kontsarenko
3 879

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

UX-аналитик «Модульбанка» Наталья Стурза написала для рубрики Growth Hacks колонку о том, как получить максимально полезные данные о пользователях, которые можно применить в проектировании сервиса.

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

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

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

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

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

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

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

Первые шаги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что показала аналитика Что дали юзабилити-тесты Вывод: что делать дальше
Кнопкой «Выход» пользуются +3% iOS и +5% Android пользователей Никто из выборки никогда не пользовался этой кнопкой. Спросили другую выборку почему пользуются? Ответ: Привычка или Для безопасности. Решение: Убрать кнопку выхода. Чем меньше поинтов в меню, тем меньше рассеивается внимание. Средства безопасности все равно разлогинивают при сворачивании.
Пытаются изменить имя и фото в приложении интернет-банка 12% iOS и 7% Android-пользователей iOS-пользователи пытались, Android-пользователи сказали, что не пользовались. Опросы показали, что люди любят и хотят персонализировать даже банковское приложение компании под себя. Решение: дать им то, чего хотят.
Ни одного совершенного налогового платежа. Заходили, смотрели, но даже не заполняли поля. Тесты и личное общение подтвердили, что с налоговыми платежами страхов еще больше. В следующей версии приложения решили убрать, а в этой оставить.
Всем нужен перевод между своими счетами. Сейчас это неочевидно и приходится делать много лишних действий. В приложении у нас этого не было. Хотя казалось бы - простая быстрая операция. Решение: Дать. А позже аналитика веб-кабинета показала, что переводы между счетами это ⅓ всех переводов и платежей.

#Кейсы #модульбанк #исследование_аудитории

{ "is_needs_advanced_access": false }

Комментарии Комм.

Популярные

По порядку

0

Прямой эфир

Хакеры смогли обойти двухфакторную
авторизацию с помощью уговоров
Подписаться на push-уведомления
[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } } ]