Как проверить удобство мобильного приложения на реальных пользователях

Всё работает, а человек не нажимает

Представим приложение для записи в салон. Клиентка хочет перенести визит на четверг. Она нашла свою запись, увидела свободное время и кнопку переноса. Разработчики уже проверили: перенос работает. Но клиентка останавливается: если изменить дату, что будет с предоплатой? Не отменится ли старая запись раньше, чем появится новая?

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

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

Сначала решите, что именно хотите узнать

«Проверить, удобно ли приложение» звучит разумно, но для первой встречи это слишком широкая задача. Удобно кому? При каких обстоятельствах? Один человек не найдёт запись, другой найдёт её сразу, но испугается потерять деньги. Если собрать всё под словом «неудобно», непонятно, с чего начинать исправления.

В нашем примере вопрос можно сузить: понимает ли клиент, как перенести уже оплаченную запись и что произойдёт с предоплатой? Тут есть конкретное действие и конкретное сомнение. Ответ поможет принять решение о содержании экрана, а не просто поставить ему оценку.

Заранее запишите для себя признаки успешного выполнения: человек нашёл нужный визит, выбрал другую дату и верно объяснил, что теперь забронировано и что будет с оплатой. Участнику этот список показывать не нужно. Иначе вы сами расскажете ему то, что собирались проверить.

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

Не обязательно ждать готового приложения

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

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

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

При этом заранее объяснять весь замысел тоже не стоит. Незавершённая разработка не отменяет проверки надписей: если по ним невозможно разобраться без рассказа автора, вы уже узнали что-то важное.

Пригласите людей, которым знакома такая задача

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

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

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

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

Формулировка задания не должна выдавать ответ

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

Хорошее задание даёт жизненную ситуацию и цель, но оставляет путь открытым. Именно эту разницу разбирает статья NN/G о сценариях заданий. Для нашего примера она выглядит так:

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

Самое трудное для наблюдателя: не спасать экран

В начале скажите простую вещь: проверяем приложение, а не ваши способности. Объясните, будете ли записывать экран или разговор, и заранее получите согласие. На личном телефоне могут появиться частные сообщения, поэтому договоритесь, как их скрыть и кто увидит запись. Практические вопросы подготовки описаны в руководстве GOV.UK.

Дальше придётся немного потерпеть. Человек молчит и смотрит в экран, а вам уже хочется сказать: «Там ниже есть кнопка». Но после такой подсказки вы наблюдаете выполнение с помощью. Иногда помочь действительно нужно, чтобы продолжить встречу. Просто отметьте помощь, а не записывайте результат как самостоятельный успех.

Лучше спросить: «Что вы сейчас ожидаете увидеть?» Или после действия: «Как вы поняли, что произошло?» Вопрос «Вы же заметили, что деньги сохранятся?» уже подсказывает ответ. Не стоит и хвалить за правильную кнопку: участник быстро поймёт, какой маршрут вам нравится, и начнёт искать одобрение вместо решения своей задачи.

У исследователей GDS есть хорошие заметки о проведении таких встреч. Важная мысль для владельца продукта: спокойная обстановка помогает, объяснение интерфейса за участника мешает. Если человек спрашивает, что значит надпись, сначала узнайте, как он сам её понимает.

На телефоне обнаруживаются свои трудности

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

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

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

*Иллюстрация принципа: сначала заметить место, где человек остановился, а уже потом помогать ему пройти дальше.*

Записывайте событие, а не готовый диагноз

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

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

Отмечайте выполнение без помощи, с помощью и отказ от продолжения. Рядом пишите последствия: человек потратил лишнее время, выбрал неверную дату или мог отменить не ту запись. Фраза «двум из пяти участников этой серии понадобилась подсказка» честно описывает наблюдение. А утверждать, что «40% всех наших пользователей не справятся», по этим встречам нельзя: всю аудиторию вы не изучали.

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

Переделайте причину и проверьте ещё раз

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

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

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

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

Частые вопросы