Разработка цифрового продукта – это сложный и дорогой процесс. Чем сложнее продукт, тем больше вероятность допустить ошибку. Именно поэтому перед выпуском он проходит тщательное и всестороннее тестирование, а выявленные на этом этапе проблемы обходятся дороже всего.
А что если ошибка допущена на этапе проектирования пользовательского опыта? Ведь казалось бы, опыт невозможно проверить заранее, а этап проектирования – один из первых при создании интерфейса.
Получается, что плохо спроектированный сценарий может привести к полной переработке крупных функциональных блоков приложения.
Как снизить риск такого события и не разориться на масштабных лабораторных UX-исследованиях? Об этом мы и хотим поговорить в этой статье, где мы описали наш реальный опыт при работе с приложением Росбанк ИНВЕСТ.
На самом деле, создать пользовательский интерфейс на первый взгляд, кажется не самой сложной задачей: открываем графический редактор, выбираем сценарий, по которому хотим провести пользователя, рисуем экраны во всех состояниях и отправляем в разработку. Разработчик превращает макеты в код. Тестировщик проверяет нет ли ошибок, и всё ли соответствует требованиям. Дальше прикручиваем аналитику и оправляем сборку в релиз. Супер! Делов-то!)
А потом через неделю мы заходим в инструмент аналитики и видим, что из 1000 пользователей, попавших в наш сценарий, завершили его всего 20%.
Почему?
Начинаем разбираться, на каком именно шаге ушли пользователи. Понимаем, что проблема на шаге выбора тарифа. Возможно не добавили cаll to action, и пользователи не догадались, что такой кнопкой является сам блок тарифа.
Ладно, ничего страшного. Берем задачу в следующий спринт: дорисовали кнопку выбора, отдали в разработку, поправили код, протестировали, выкатили в релиз. Метрика подросла, но опять проблема на той же странице выбора тарифа. Хорошо, что попросили телефон и согласие на обработку данных заранее. Звоним пользователю и выясняем — оказывается, на этот раз смутила формулировка в описании тарифа. Задачу в спринт. Дорабатываем формулировку, отправляем в разработку, тестируем, в прод. Наконец показатель отказа опустился до уровня в 0,1%.
После того как отгремели салюты, радость от успеха поутихла, самое время подсчитать потери:
- 3 спринта разработка → аналитика → дизайн → программирование → тестирование
- место под рекламную площадку
- пользователи, которые ушли и через этот канал больше не вернутся
А можно ли было избежать, или хотя бы минимизировать эти проблемы заранее?
Можно.
Один из самых простых и практически бесплатных способов — это коридорное тестирование, о котором далее и пойдёт речь.
Суть метода заключается в том, что на стадии проектирования дизайна или вайрфеймов мы создаем небольшой прототип сценария, работу которого хотим потестировать в реальности.
Как же именно это делать? Очень просто: выходим в условный коридор, находим коллег, знакомых, друзей или незнакомых людей на улице, и просим выполнить несколько задач с помощью нашего интерфейса. В процессе фиксируем в какой момент у пользователя возникают затруднения и пытаемся разобраться с чем они связаны.
В таких тестах можно использовать прототипы разной степени сложности, начиная буквально от бумажных, склеенных и нарисованных «на коленке», до полноценных сборок, адаптированных под конкретное устройство, с рабочей анимацией и вводом prod-like данных.
Вот пример PNG-изображений, склеенных в invision:
Или более сложными прототипами в Figma:
Ну и заканчивая сложными прототипами, больше напоминающими настоящий реализованный функционал, во Framer, Protopie или Principle.
Важно понимать, что коридорки нужны для того, чтобы быстро и дешево проверить наличие очевидных проблем интерфейса. Следовательно, чем быстрее собран прототип, тем эффективнее коридорка.
Немного практики
Давайте попробуем протестировать интерфейс онбординга* в одном из наших приложений.
*онбординг — это оформление доступа и начало использования продукта
1. Прототип
Подготовка прототипа может занять от 20 минут до нескольких часов – в зависимости от детализации и длины сценария, которые мы хотим протестировать:
2. Задача и гипотезы
Звучит банально, но перед тем как показать прототип, нужно хорошо подготовиться:
- Сформулировать задачу для пользователя и гипотезы (возможно вы тестируете какую-то новую механику или формулировку которая может вызвать проблему)
- Спланировать, как вы будете фиксировать результаты
- Подготовить тестовую среду (например если тестирование дистанционное, то нужно позаботиться, чтобы прототип без проблем открылся у пользователя на устройстве)
3. Респонденты
Как правило, не имеет особого значения, с кем именно проводить такие исследования. Единственным принципиальным условием является неучастие респондента в работе над продуктом. Однако следует учесть, что перед тестированием его необходимо погрузить в контекст, причём лучше это конечно сделать как можно проще, «на пальцах». Поэтому хорошо если он будет хотя бы минимально в курсе темы продукта.
Перед тестированием проведите небольшое интервью. Вопросов должно быть немного: имя, возраст, сфера деятельности, опыт с продуктом или продуктом-конкурентом. Как правило этого достаточно. Так можно понять насколько опыт пользователя релевантен цели которую вы ставите в исследовании.
Например: сантехнику Василию будет довольно сложно оценить новые возможности графика изменения цены в брокерском приложении. Зато он скорее всего справится с тем чтобы, заполнить анкету онбординга, и более того, укажет вам на те термины которые нуждаются в пояснении.
И наоборот опытный брокер Виталий вряд ли обратит ваше внимание на термин который он использует каждый день, а вот возможность увеличить график жестом или отсортировать список инструментов по убыванию цены, оценит по достоинству.
4. Тестирование прототипа
Приступаем к самому интересному. Формулируем цель сценария и начинаем тестирование.
Попросите пользователя, чтобы он как можно больше проговаривал вслух все мысли и всё, что он видит в интерфейсе – как он понимает, что написано на полях и кнопках, куда он собирается нажать, что по его мнению должно происходить, и так далее. Очень важно знать, что пользователь думает и чувствует, взаимодействуя с продуктом и проговаривание является основным способом узнать это.
Если вы снимаете процесс тестирования на видео – постарайтесь сделать так, чтобы на записи было видно и то, что делает пользователь (экран с прототипом), и лицо пользователя, чтобы фиксировать эмоции (иногда это позволяет распознать замешательство).
В процессе просите пользователя комментировать свои действия: как мы уже заметили, очень важно, чтобы он озвучивал, что он делает, куда хочет нажать, почему именно туда. Если сценарий не рассчитан на тот путь, который выбрал пользователь – выясните почему он захотел пройти этим путем. Сначала такого рода монолог будет непривычен для респондента, но через пару минут это пройдет.
Если пользователь остановился на каком-то шаге и не может пройти дальше, нет ничего страшного в том чтобы подсказать ему, но перед этим спросите его: куда он смотрит, что пытается найти, что именно ему непонятно и что он ожидал увидеть на этом шаге.
5. Фиксируем результаты
В идеале и по канонам, одним из артефактов пользовательского исследования является карта эмпатии, но так как мы говорим об экспресс-проверках и действительно быстрых сессиях, то и результаты тестирования у нас будут упрощенными.
Для фиксации результатов нам достаточно будет небольшой таблички в которую заносятся данные пользователя, список сценариев и комментариев которые фиксируются во время теста или после просмотра видеофиксации. А также ссылки на видео материал.
Большую работу мы делаем Figma, поэтому и результаты тестирования оформим в Figma Jam:
В будущем эти материалы могут быть прикреплены к задаче на разработку вместе с макетами и служить основанием принятых решений.
6. Сравниваем стоимость
Казалось бы, дизайнер теперь делает кучу лишней работы. Но если разобраться, подготовка к такому тестированию не должна занимать много времени, сам тест вообще занимает не больше 15 минут, а за спринт можно провести подобных 2–3 итерации. Таким образом, подобная «лишняя» работа экономит далее огромное количество времени для продуктовой команды в целом и для дизайнера в частности.
Да, скорее всего тестирование не спасет вас от всех ошибок, которые могут быть допущены на стадии проектирования, но коридорное исследование является хорошим способом проверить себя перед передачей макетов в разработку.
Итоги:
- Подготовив прототип, сформулируйте гипотезы
- Внимательно отнеситесь к опыту респондента
- В процессе интервью уделите всё свое внимание респонденту и его реакции на продукт
- Обязательно фиксируйте результаты: на них можно будет ссылаться в дальнейшей работе над проектом
- Помните, что коридорка не заменяет серьёзные UX исследования, но помогает не допустить «очевидных» ошибок.