Выявление юзабилити-проблем в мобильном приложении

Поздравляю, вы создали мобильное приложение и прошли через процедуру проверки в Apple App Store или Google Play. Теперь вы готовы к покорению бескрайних просторов целевой аудитории и захвату своей доли рынка. Если вы считаете, что все самое сложное уже позади, то у нас есть плохие новости.

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

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

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

Система аналитики для мобильных приложений

Для начала нам надо встроить в мобильное приложение систему аналитики, например, Flurry (есть еще Google Analytics, Яндекс.Метрика, Mixpanel) . Через некоторое время, допустим, месяц, мы получим временной срез информации о том, как и кто пользуется нашим приложением.

Рассмотрим аналитический инструмент на примере Flurry:

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

Какие данные он нам может предоставить:

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

Обработка полученных данных

Данные о переходах с экрана на экран, которые предоставляет аналитика, всегда очень интересны.

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

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

Данные, собранные аналитическим инструментом, показывают, на каком экране в каждой сессии пользователь вышел из приложения. Именно поэтому можно понять, была ли выполнена задача пользователя, вышел ли он из-за непонимания интерфейса или какой-то ошибки на полпути.

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

Например, собранные данные показывают, что пользователь вышел на этапе заполнения корзины.

Гипотезы:

• Пользователь не понимает, какие данные нужно указывать в полях
• Проблемы с оплатой товара, не ясно, прошла оплата или нет
• Проблемы с отображением товаров в корзине — часть товаров не видно

Или, например, пользователь выходит на странице товара

Гипотезы:

• Проблемы с отображением товара (недостаточное количество изображений)
• Не хватает информации о товаре, чтобы принять решение о покупке
• Непонятно как перейти к оформлению заказа
• Проблемы с добавлением товара в корзину
• У конкурентов дешевле данный товар

Для проверки гипотез нужно тестировать продукт на реальных пользователях, которые являются представителями целевой группы. Как описать целевую группу? Нужно создать персонажей и их сценарии использования.

Создание персонажей и их сценариев использования

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

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

Описание персонажа

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

Пример персонажа для мобильного интернет-магазина по продаже пони

Конезаводчик Сергей, 25 лет

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

Задачи на портале:

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

Сценарии для проектирования

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

Пример сценария

• Запустил приложение
• Ввел запрос поиска
• Выбрал интересующее в поисковой выдаче
• Просмотрел характеристики
• Прочитал отзывы
• Заказал
• Получил уведомление о времени доставки

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

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

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

Юзабилити-тестирование

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

Теперь самое время провести тестирование.

Для тестирования необходимо:

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

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

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

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

Сделать листы оценки:

• выполнил ли задачу — смог ли достигнуть нужного результата;
• сложности — например, от одного до пяти, как он считает;
• затраченного времени — тут надо отмечать, прошел ли за разумное время или затратил много времени, понимая, что от него хотят.

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

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

“У вашего друга скоро день рождения. И вы решили подарить ему розового пони в яблоках. Чтобы не ехать на конюшню, вы собираетесь заказать его в интернет-магазине. Купите подарок для вашего друга”.

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

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

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

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

Итого

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

Установите систему аналитики в ваше приложение.

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

Анализируйте поступающие данные и корректируйте ваши планы глядя на них.

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

Сделайте персону для вашего приложения. Знайте своего пользователя в лицо.

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

Тестируйте на живых пользователях.

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

Не останавливайтесь на достигнутом.

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