Factorin. Тестирование и дизайн онбординга в мобильном приложении

UX-тестирование и редизайн ⇒ улучшение понимания пользователями основных механик взаимодействия с интерфейсом.

Factorin — факторинговый онлайн-сервис, один из крупнейших B2B-блокчейнов в России, Центральной и Восточной Европе с оборотом более 500 млн. долл.

Глоссарий

Контекст

Factorin.io — онлайн-платформа, которая упрощает взаимодействие покупателей, поставщиков и факторов и автоматизирует всю ручную работу по подготовке, сверке и согласованию документов. В результате поставщик может получить деньги уже через 2 часа после поставки.

Интерфейс Факторина существует в двух вариантах, рассчитанных на разные контексты работы пользователя:

1. Веб-приложение. Для стационарного рабочего места; воспроизводящее устройство — настольный монитор офисного формата или ноутбук.
2. Мобильное приложение. Для взаимодействия «на ходу»; воспроизводящие устройства — смартфоны на iOS и Android.

Задача

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

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

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

Я решил проверить это с помощью UX-тестирования интерфейса на пользователях.

Гипотезы

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

1. Пользователи не будут внимательно читать экраны онбординга, и поэтому не разберутся с управлением (подтвердилась)
2. Навигация в приложении будет непонятна пользователям (не подтвердилась)
3. Разная логика подписания реестров в модуле Согласования и модуле Уступки может запутать пользователей (подтвердилась)
4. Пользоваться фильтрами на мобильном неудобно (не подтвердилась)

Сценарии

В тестировании принимало участие 7 респондентов, а всего с их помощью было проверено 5 сценариев:

Полный сценарий пользовательского тестирования в google doc (можно использовать как рабочий шаблон)

Тестирование

Интерфейс любого профессионального сервиса обычно подразумевает предварительное ознакомление и обучение пользователей основам работы в нем.

В Факторине обучение было реализовано стандартным образом — при первом входе запускались несколько последовательно сменяющих друг друга экранов с инструкциями.

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

🙀 Обнаруженные проблемы

Тестирование на реальных пользователях показало следующее:

1. Респонденты не усваивали инструкции, представленные в виде экранов онбординга. Перейдя к практике, они путались и не могли выполнить целевые действия с первого раза.
2. Респонденты не понимали, почему в двух разных модулях приложения для, как им казалось, однотипных действий реализованы разные паттерны. Они пытались применить усвоенный в одном сценарии жест, но в других сценариях он имел другой эффект, что нарушало уже сформированные ожидания и вызывало смущение.

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

🧠 Причины проблем

Насколько я увидел, этому было несколько причин:

• Гайд существовал как бы сам по себе, в отрыве от контекста пользовательской работы. Он появлялся тогда, когда система принудительно решала его показать, а не в момент, когда пользователь действительно испытывал необходимость в поясняющем материале.
• Гайд мешал пользователю сфокусироваться, отвлекал внимание и загружал его оперативную память.
• Информация в справке шла одним большим пакетом (подряд шесть экранов с инструкциями, относящимися к разным сценариям), и ее запоминание, при отсутствии возможности немедленного закрепления новых знаний на практике, требовало от респондента серьезных ментальных усилий.
• Кроме того, знакомство с гайдом в такой форме воспринималось пользователями не как реальная задача, а скорее как подготовительный этап к «настоящей» работе, которая была впереди — им хотелось поскорее закончить с ознакомлением и приступить к следующим сценариям.

По-видимому, здесь я на практике столкнулся с известным парадоксом активного пользователя (the paradox of the active user) — когда пользователь не хочет тратить время на обучение работе с системой, но хочет иметь возможность начать использовать систему немедленно.

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

🤷 Поведение респондентов

Во время теста пользователи действовали следующим образом:

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

Пространство решений

Увидев все это на пользовательском тестировании, я понял, как можно скорректировать обучение:

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

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

Онбординг после редизайна:

Встроенная справка в сценарии работы с поставками. Остается на экране, пока пользователь не скроет подсказку.

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

Метрики

• Процент успешного завершения сценария.
• Кол-во пользователей, успешно завершивших целевой сценарий с первой попытки.
• Время, потраченное на выполнение целевого сценария с первой попытки.
• Время, потраченное на изучение справки/обучение.
• Субъективная удовлетворенность.

Результат

Тестирование нового дизайна онбординга показало следующие результаты:

• Время, затрачиваемое новыми пользователями на обучение, сократилось на 56%.
• Семь из семи респондентов успешно завершили сценарии согласования и уступки реестров с первой попытки.
• Время выполнения сценария согласования реестра уменьшилось в среднем с 4,2 до 2 мин.
• Не было ни одного повторного обращения к справке.
• Респонденты отмечали реализацию решения как «очень удобную».

Выводы

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

В этом кейсе

• Factorin. Тестирование и дизайн онбординга в мобильном приложении
• Глоссарий
• Контекст
• Задача
• Гипотезы
• Сценарии
• Тестирование
• 🙀 Обнаруженные проблемы
• 🧠 Причины проблем
• 🤷 Поведение респондентов
• Пространство решений
• Метрики
• Результат
• Выводы