Как провести тестирование интерфейса на удалёнке и не набить шишек

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

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

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

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

Еще несколько проблем всплыли прямо во время встречи с пользователями.

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

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

Процесс

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

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

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

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

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

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

Чему мы научились

Онлайн-тестирование имеет свои особенности, диктующие особые правила. Чтобы проверка прототипа прошла качественно, необходимо:

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

— Записывать видео, чтобы фиксировать действия и эмоции пользователя.

— Предварительно расположить человека к общению, чтобы пользователь воспринимал процесс как полезное приключение, а не строгий экзамен.

Результаты тестирования нужно оформить следующим образом:

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

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

— Задокументировать, кто и как прошел сценарии, снабдив это комментариями самих пользователей.

— Написать краткий вывод к каждому сценарию и общий вывод для всех.

— Закончить выводом о необходимости конкретных изменений.

Бонусом можно добавить личные впечатления и дать рекомендации команде продукта.

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