Быстрые пользовательские тесты

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

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

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

Как снизить риск такого события и не разориться на масштабных лабораторных UX-исследованиях? Об этом мы и хотим поговорить в этой статье, где мы описали наш реальный опыт при работе с приложением Росбанк ИНВЕСТ.

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

А потом через неделю мы заходим в инструмент аналитики и видим, что из 1000 пользователей, попавших в наш сценарий, завершили его всего 20%.

Почему?

Начинаем разбираться, на каком именно шаге ушли пользователи. Понимаем, что проблема на шаге выбора тарифа. Возможно не добавили cаll to action, и пользователи не догадались, что такой кнопкой является сам блок тарифа.

Ладно, ничего страшного. Берем задачу в следующий спринт: дорисовали кнопку выбора, отдали в разработку, поправили код, протестировали, выкатили в релиз. Метрика подросла, но опять проблема на той же странице выбора тарифа. Хорошо, что попросили телефон и согласие на обработку данных заранее. Звоним пользователю и выясняем — оказывается, на этот раз смутила формулировка в описании тарифа. Задачу в спринт. Дорабатываем формулировку, отправляем в разработку, тестируем, в прод. Наконец показатель отказа опустился до уровня в 0,1%.

После того как отгремели салюты, радость от успеха поутихла, самое время подсчитать потери:

А можно ли было избежать, или хотя бы минимизировать эти проблемы заранее?

Можно.

Один из самых простых и практически бесплатных способов — это коридорное тестирование, о котором далее и пойдёт речь.

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

В таких тестах можно использовать прототипы разной степени сложности, начиная буквально от бумажных, склеенных и нарисованных «на коленке», до полноценных сборок, адаптированных под конкретное устройство, с рабочей анимацией и вводом prod-like данных.

Вот пример PNG-изображений, склеенных в invision:

Или более сложными прототипами в Figma:

Ну и заканчивая сложными прототипами, больше напоминающими настоящий реализованный функционал, во Framer, Protopie или Principle.

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

Давайте попробуем протестировать интерфейс онбординга* в одном из наших приложений.

1. Прототип

Подготовка прототипа может занять от 20 минут до нескольких часов – в зависимости от детализации и длины сценария, которые мы хотим протестировать:

2. Задача и гипотезы

Звучит банально, но перед тем как показать прототип, нужно хорошо подготовиться:

3. Респонденты

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

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

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

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

4. Тестирование прототипа

Приступаем к самому интересному. Формулируем цель сценария и начинаем тестирование.

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

Если вы снимаете процесс тестирования на видео – постарайтесь сделать так, чтобы на записи было видно и то, что делает пользователь (экран с прототипом), и лицо пользователя, чтобы фиксировать эмоции (иногда это позволяет распознать замешательство).

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

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

5. Фиксируем результаты

В идеале и по канонам, одним из артефактов пользовательского исследования является карта эмпатии, но так как мы говорим об экспресс-проверках и действительно быстрых сессиях, то и результаты тестирования у нас будут упрощенными.

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

Большую работу мы делаем Figma, поэтому и результаты тестирования оформим в Figma Jam:

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

6. Сравниваем стоимость

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

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