Большинство владельцев сайтов создают их для того, чтобы либо продвигать свою продукцию на рынок товаров, либо получать прибыль непосредственно при помощи монетизации своего сайта. То есть на нем размещают рекламу, а за ее просмотры пользователями владелец сайта получает определенную прибыль.
Именно поэтому администраторы заинтересованы в большой посещаемости. Чем она больше, тем больше будет прибыль с рекламы. Полновесный график обеспечивается за счет высокого уровня "юзабилити"-страниц. Так что же такое "юзабилити"? Какими способами можно сделать свой сайт наиболее привлекательным для пользователей и потенциальных клиентов?
Введение в понятие
"Юзабилити" - это, по сути, показатель того, в какой степени посетителю сайта удобно взаимодействовать с его интерфейсом. Методы, позволяющие улучшить сайт на стадии его разработки, также называются данным термином.
Допустим, что пользователь открывает ту или иную веб-страницу. Что он ожидает увидеть? Конечно же, в первую очередь, понятное меню. А вместе с ним - четкую структуру. Сюда также относится и читабельный контент. Однако сейчас можно встретить множество ресурсов, на которых имеется путаница из гиперссылок, картинок и кнопок. Казалось бы, что все необходимые элементы есть. Однако для их правильного использования может потребоваться время.
Вряд ли какой-то клиент захочет тратить свое драгоценное время, чтобы сделать это. "Юзабилити" - это достаточно серьезное в наше время. Forrester Research провели исследование, посвященное этой теме. Оно показало, что практически половина покупателей покидает интернет-магазин, если не может быстро найти в его разделах тот или иной товар. Кроме того, после такого опыта работы с ресурсом половина покупателей отказалась вновь вернуться на него.
Исследования и имеющие отношение к "юзабилити"
Социологи также отмечают тот факт, что в наше время люди уже слишком нетерпеливы. Особенно пользователи Интернет-аудитории. Еще одно исследование было проведено Nielsen Norman Group. Оно показало, что обычный среднестатистический пользователь находится на странице всего лишь около полминуты. Отмечалось, что в большинстве случаев пользователи даже не досматривают веб-страницу до конца.
Якоб Нильсен считает, что причина подобного поведения кроется в большом количестве действительно бесполезной информации. Так, людям постоянно необходимо фильтровать широкий информационный поток, чтобы выбрать из него только те фрагменты, которые их интересуют на самом деле.
Разумеется, на подробное изучение сайта может уйти столько времени, что ни на что другое его попросту не останется. Клиенты не хотят, и не будут ждать, если сайт медленно загружается, а также не будут им пользоваться, если он имеет сложный интерфейс. Вот тут-то в дело и вступает "юзабилити". Это помогает расправиться со многими проблемами.
Множество специалистов в данной области высказываются примерно так же. Например, говорят о том, что между простым, понятным для любого пользователя, веб-сайтом и хорошо освещенной магазинной витриной можно провести вполне ясную параллель. "Юзабилити" - это "степень освещенности" в данном случае. Разработчик должен ясно понимать, что он имеет только несколько секунд для того чтобы заинтересовать посетителя и ненавязчиво дать понять, что его сайт лучше, чем другие.
Сделать это можно за счет использования продуманного интерфейса. За короткий промежуток времени он должен дать понять пользователю на интуитивном уровне, что и как можно делать дальше. Человек должен быть заинтересован в сайте, почувствовать, что здесь он найдет то, что ему нужно. Если этого не произойдет, клиент покинет сайт.
Проведение тестирования
Этот процесс в любом случае является обязательным этапом при разработке "юзабилити". Его суть, в принципе, незамысловата: несколько респондентов решают набор тех или иных задач, используя только прототип системы. Специалист, который при этом находится рядом, все действия и слова фиксирует. Когда сбор данных будет закончен, они анализируются. При необходимости корректировки вносятся в проект.
Тестирование "юзабилити" проводится с целью обнаружения недочетов или проблем. Они вполне могут возникать у респондентов во время работы с сайтом, и бояться этого не стоит. Главное - внести правильные корректировки.
Что включает в себя анализ сайта?
Анализ "юзабилити" позволяет получить комплексную картину всего сайта. Сюда обычно включают выводы по дизайну, результаты тестирования, сравнение прототипов анализируемых страниц, а также выдачу разного рода рекомендаций, которые помогут устранить имеющиеся проблемы.
Заключение по дизайну определяет так называемое "юзабилити" интерфейса. То есть насколько удобно и одновременно комфортно пользователю будет работать с данным веб-сайтом. "Юзабилити"-примеры предоставляются многими сервисами, которые всегда готовы предоставить свои услуги в этом плане.
Различия уровней ресурсов
Если расходы на рекламу одинаковы, то сайт, имеющий более высокий уровень "юзабилити", примет большее количество потенциальных клиентов. Они будут также более лояльны к компании. А это немаловажно, поскольку клиенты станут посещать сайт и делать покупки на постоянной основе.
Вполне возможен вариант с разгрузкой менеджеров компании, поскольку при высоком уровне "юзабилити" клиенты могут найти ответы на интересующие их вопросы сами, на страницах ресурса. Следовательно, руководство может снизить затраты, необходимые на содержание менеджеров, что положительно скажется на бизнесе.
Что изучается для получения "юзабилити"?
Это целый комплекс факторов. К ним можно отнести следующие критерии:
- Эффективность использования. С какой скоростью клиент сможет решать свои вопросы, если научится пользоваться ресурсом?
- Простота обучения. Насколько быстро впервые зашедший на ресурс посетитель научится использовать интерфейс?
- Запоминаемость. Сможет ли клиент воспроизвести схему использования, выученную впервые, при повторном открытии страниц?
- Ошибки. С какой частотой посетитель допускает ошибки, находясь на сайте? Как можно исправить эти ошибки, и в какой степени они серьезны?
- Удовлетворение от проделанной работы. Понравился ли ресурс пользователю? Если понравился, то насколько?
Заключение и выводы
Статистика показывает, что из 10 пользователей больше половины (а если быть точнее, то 6) не могут найти в международной сети необходимую информацию сразу же. Причина этого кроется в неправильном построении "юзабилити". Интернет был создан для обмена тотальным потоком информации, однако множество сайтов не соблюдают обыкновенные правила подобного обмена. Это приводит к тому, что поиск полезной информации занимает гораздо большее количество времени. Коэффициент полезности же работы пропорционально падает.
Проходить тестирование рекомендуется всем владельцам сайтов. Это выгодно им в первую очередь, поскольку за счет правильной постановки "юзабилити" можно увеличить постоянную аудиторию сайта. А следовательно, удачно его монетизировать.
От автора: не будем кривить душой: любой сайт создается для получения прибыли. Владельцы интернет-магазина «спят и видят», как бы продать побольше товаров. Разум блоггеров постоянно занят поисками . Даже сайты благотворительных организаций - и те создаются с целью извлечения выгоды, в частности, для привлечения внимания спонсоров и общества к проблеме. Однако, максимальную отдачу можно получить только если сайтом удобно пользоваться. Как лучше проверить юзабилити сайта? Об этом и поговорим сегодня.
Согласитесь, на сайт с удобной навигацией, красивым дизайном, качественной информацией и хорошей функциональностью хочется возвращаться снова и снова. Чего не скажешь о неудобных веб-ресурсах, которых совсем не заботит комфорт пользователей. А те, в свою очередь, чувствуя неуважение к себе и своим потребностям, быстренько ретируются с такого сайта, так ничего и не купив. Чтобы этого не произошло, нужно обязательно проверять юзабилити сайта.
Юзабилити сайта (от англ. Usability) - это удобство в его использовании. Чем выше юзабилити, тем выше качество сайта, тем проще и быстрее посетитель может достичь свой цели - например, сделать заказ или найти какую-то информацию.
Основными проблемами, которые можно выявить при проверке юзабилити сайта, являются:
Наличие даже одной из вышеупомянутых проблем может довольно плачевно повлиять на место сайта в поисковой выдаче, его посещаемость потенциальными клиентами и в целом, на их лояльность к ресурсу.
Что такое юзабилити-тестирование?
Это исследование, направленное на определение степени удобства и соответствия веб-страницы или пользовательского интерфейса их предполагаемому применению. Этот процесс, называемый также проверкой эргономичности, предполагает привлечение пользователей в качестве тестировщиков, чтобы на выходе получились объективные данные.
Как проходит процесс тестирования в «лабораторных условиях»?
Пример тестирования юзабилити: пользователю предлагают решить некоторые задачи, для выполнения которых создавался данный веб-ресурс, и в процессе выполнения теста фиксировать свои замечания. Фиксация замечаний осуществляется обычно с помощью видео- или аудиозаписи, чтобы затем их можно было детально проанализировать.
В процессе могут участвовать наблюдатели, которые следят за ситуацией и делают свои заметки о ходе тестирования. Возможен такой вариант проверки юзабилити и функциональности сайта: разрабатывается «идеальный» сценарий поведения пользователя и его «путешествия» по сайту, а затем фиксируются отклонения от этого маршрута и выполняются соответствующие правки.
После нескольких кругов ада итераций «тест/доработка» можно получить интерфейс, приемлемый для решения той или иной задачи, удобный клиенту и приносящий прибыль владельцу сайта.
Использование фокус-группы
Одна из разновидностей описанного выше способа - тестирование продукта с помощью фокус-группы. Его суть состоит в том, что реальные пользователи заходят на сайт и осуществляют различные действия вплоть до совершения конверсии.
В результате вы получите обратную связь «со стороны», список вопросов и возникших трудностей и, возможно даже, предложений по доработке. В таком исследовании должны участвовать представители целевой аудитории, которые отличаются между собой уровнем владения компьютером, профессией, социально-демографическими и другими характеристиками.
Данный вид проверки юзабилити сайта онлайн позволит проанализировать продукт с позиции конечного пользователя и получить ответы на следующие вопросы:
отвечает ли структура и дизайн интерфейса целям бизнеса;
на какие элементы пользователь обращает больше всего внимания;
удобная ли навигация;
быстро ли пользователь может адаптироваться к интерфейсу и его функционалу;
нормально ли работает механизм обратной связи;
Современные тенденции и подходы в веб-разработке
Узнайте алгоритм быстрого роста с нуля в сайтостроении
производит ли продукт правильное впечатление;
имеются ли различия в реальных и конверсионных пользовательских маршрутах.
Где взять эти самые фокус-группы? Для этого существует множество сервисов для тестирования юзабилити с помощью фокус-групп (askusers.ru, usabilla.com, sitepolice.ru и др.); можно также воспользоваться помощью специализированных компаний.
Минусом данного метода является его платность. Для получения нормальной выборки (не из 2-х человек) вам потребуется немалый бюджет. Кроме этого, привлекая к исследованию фокус-группы, вы, скорее всего, получите только перечень проблем, решение которых вам придется искать либо самостоятельно, либо с помощью специалистов.
Инструменты для оценки юзабилити
Как еще можно проверить юзабилити сайта онлайн? В интернете существует огромное количество различных инструментов, как платных, так и бесплатных. Приведу самые полезные, на мой взгляд:
Google Analytics Content Experiments. Это бесплатный и доступный всем инструмент, с помощью которого вы можете тестировать практически любые изменения на веб-сайте, чтобы понять, способствуют ли они снижению показателя отказов или увеличению конверсии.
Для подключения инструмента перейдите в Google Analytics и найдите вкладку «Поведение» - «Эксперименты». Чтобы настроить эксперимент, нужно произвести несколько действий:
задать название и цель эксперимента. Целью может быть посещение веб-страницы, покупка товара, присутствие пользователя определенное время. Цель можно создать свою или выбрать из предложенных Google Analytics;
выбрать процент распределения трафика. Это количество посетителей, которые будут видеть тот или иной целевой вариант;
задать минимальное время эксперимента. Обычно это недели две;
настроить порог достоверности. Чем он выше, тем точнее будет определен выигрышный вариант, однако, это увеличит время эксперимента.
К недостаткам использования данного инструмента можно отнести невозможность проверки сразу нескольких задач, отсутствие поливариантности тестирования и сегментации трафика.
Visual Website Optimizer. Он позволяет эффективно повысить конверсию, обладает простым онлайн-редактором для настройки множества вариантов своей посадочной страницы, создает уникальные связки таргетинга. К примеру, вы можете указать ему: если посетитель пришел к нам с Вконтакте и пользуется OS Windows, то, будь добр, покажи ему эту веб-страницу, а если он заходит с MacBook, то вот эту…Также Visual Website Optimizer может похвастаться удобной системой отчетности и еще кучей разных фишек.
Qualaroo. Бесплатный опросник пользователей, позволяющий узнать непредвзятое мнение о веб-ресурсе. С его помощью вы сможете определить проблемы и увеличить вашу прибыль. Этот инструмент обратной связи существенно облегчает работу юзабилити-аналитикам.
Яндекс.Метрика. Позволяет проанализировать этапы заполнения формы и выяснить, какие из них вызвали наибольшие затруднения у посетителей, какие пользователи не стали заполнять тот или иной пункт и т. д.
Тепловые карты. К ним можно отнести «Карту кликов» Яндекс.Метрики, статистику веб-страниц Google Analytics, usabilitytools.com, feng-gui.com и т. д. Эти инструменты позволяет оценить суммарное поведение пользователей на сайте. С помощью тепловых карт вы сможете увидеть, куда кликает большинство людей, а куда - нет. В зависимости от результата вносятся соответствующие корректировки.
Чек-лист для проверки
Быстро ли загружаются веб-страницы? Перегруженность анимациями, тяжеловесными картинками и флеш-заставками могут повлиять на рейтинг вашего сайта в поисковой выдаче и, конечно же, на лояльность пользователей.
Есть ли логотип на каждой странице? На нем должна присутствовать ссылка на главный ресурс.
Как оформлен контент? В тексте должна быть хорошая структура: заголовок, подзаголовки, списки и т. д. И не должно быть ошибок. Недооформленный текст с ошибками плохо читается и воспринимается как людьми, так и роботами поисковых систем. Заголовки и подзаголовки должны быть емкие и краткие, соответствовать той рекламе, что размещается в сети.
Надеюсь, данная статья была вам полезна в оценке юзабилити сайта. Подписывайтесь на обновления нашего блога и узнайте еще много чего полезного о юзабилити, веб-дизайне, и других областях . До скорых встреч!
Современные тенденции и подходы в веб-разработке
Узнайте алгоритм быстрого роста с нуля в сайтостроении
Подготовка, интервью и сбор данных
В закладки
Руководитель направления UX-исследований Mail.Ru Group Наталия Спрогис в блоге компании на «Хабрахабре» рассказала о подготовке и проведении юзабилити-тестирований: что включить в сценарий теста, как выбрать метод сбора данных, составить задания и собрать впечатления респондентов.
План тестирования - это, с одной стороны набор заданий, вопросов и опросников, которые вы даете каждому респонденту, а с другой - методологическая база исследования: метрики и гипотезы, которые вы проверяете и фиксируете, выбранный инструментарий.
Точно ли нужно тестирование
Для начала вы должны быть уверены, что на данном этапе проекту нужно именно юзабилити-тестирование. Поэтому уточняйте, с какой целью к вам обращается проектная команда. Юзабилити-тестирования не всемогущи, и уже на старте нужно понимать, что оно может принести продукту. Сразу подготовьте проектную команду к тому, на какие вопросы вы сможете дать ответы, а на какие нет. Бывали случаи, когда мы либо предлагали заказчикам другой метод (например, сейчас лучше подойдут глубинные интервью или дневниковые исследования), либо рекомендовали вообще отказаться от исследования, а вместо этого сделать сплит-тест.
Например, мы никогда не беремся в качественных исследованиях проверять «привлекательность» какой-то функции или варианта дизайна. Мы можем собрать с пользователей отзывы, но слишком велик риск, что на их ответы повлияет социальная желательность. Люди всегда склонны сказать, что стали бы пользоваться даже тем, чем пользоваться не будут. Да и маленький размер выборки не позволяет доверять таким ответам. Например, у нас был неудачный опыт тестирования игровых лендингов: лендинг, который выбирали как наиболее привлекательный на тесте, при A/B-тестировании отработал гораздо хуже.
Ряд ограничений есть и у тестирования прототипов и концепций. При планировании вы должны понимать, что реально можно «выжать» из этого теста. Здорово, когда у проекта есть возможность протестировать прототипы или дизайн до внедрения. Однако, чем менее детальный и рабочий прототип, чем выше уровень абстракции для респондента, тем меньше данных можно получить из теста. Лучше всего на тестировании прототипов выявляются проблемы нейминга и метафор иконок, то есть все вопросы понятности. Возможность проверить что-то сверх этого сильно зависит от сути проекта и детальности проработки прототипа.
Основа для составления сценария юзабилити-теста
Планирование тестирования начинается не с составления текста заданий, а с детальной проработки целей и вопросов исследования совместно с проектной командой. Вот основа для составления плана:
Важные сценарии. Это те пользовательские сценарии (задачи, или юзкейсы), которые влияют на бизнес или связаны с целью тестирования. Даже если команда подозревает проблемы в конкретных местах, часто стоит проверить основные кейсы. При этом важными для теста могут считаться следующие сценарии:
- наиболее частотные (например, отправка сообщения в мессенджере);
- влияющие на бизнес-цели (например, работа с платежной формой);
- связанные с обновлением (те, которые затронул редизайн или внедрение новой функциональности).
Известные проблемы. Часто исследование должно дать ответ на причины бизнес-проблем сервиса. Например, продюсера беспокоит большой отток игроков после первого часа игры. А иногда проблемные места интерфейса уже известны команде, и вам необходимо собрать подробности и конкретику. Например, в службу поддержки часто обращаются с вопросами по форме оплаты.
Вопросы. У команды также могут быть вопросы для исследования: например, замечают ли пользователи баннер, рекламирующий дополнительные услуги; понятно ли назван определенный раздел.
Гипотезы. Это то, во что преобразуются известные проблемы и вопросы команды. Хорошо, если заказчик приходит к вам с готовыми гипотезами - например, «Наши клиенты платят только с телефона с комиссией. Возможно, пользователи не видят выбора более выгодного способа оплаты». Если же гипотез нет, а есть только желание проверить проект абстрактно «на юзабилити», ваша задача - эти гипотезы сформулировать.
Подумайте совместно с проектной командой о тех местах, где пользователи ведут себя не так, как ожидается (если такая информация есть). Выясните, нет ли элементов дизайна, над которыми много спорили и которые могут оказаться проблемными. Сделайте собственный аудит продукта, чтобы найти потенциальные сложности для пользователей, которые важно проверить на тесте. Все это поможет вам составить список тех элементов (заданий, вопросов, проверок), которые должны войти в итоговый сценарий.
Метод сбора данных
Важно продумать, как вы будете собирать данные о происходящем во время теста для последующего анализа. Традиционно используются следующие варианты:
Наблюдение. Во время выполнения заданий респондент остается наедине с продуктом и ведет себя так, как считает нужным. Комментарии респондента собираются посредством опросников и общения с модератором после теста. Это наиболее «чистый» метод, он обеспечивает более естественное поведение респондента и возможность корректно измерить ряд метрик (например, время выполнения задания).
Однако за кадром остается много полезных качественных данных. Увидев то или иное поведение респондента, вы не можете понять, почему он так действует. Конечно, можно спросить об этом в конце теста, но, скорее всего, респондент будет хорошо помнить только последнее задание. Кроме того, за время выполнения заданий его мнение о системе может меняться, и вы получите только итоговую картину, а не первые впечатления.
Think Aloud (мысли вслух). Долгое время этот метод использовался в юзабилити-тестированиях чаще всего. Якоб Нильсен в свое время называл его главным инструментом оценки юзабилити. Суть в том, что вы просите респондента озвучивать все мысли, возникающие у него при работе с интерфейсом, и комментировать все свои действия. Это выглядит примерно так: «Сейчас я собираюсь добавить этот товар в корзину. А где же кнопка? А, вот она. Ой, я забыл посмотреть, какой там был цвет».
Метод помогает понять, почему пользователь ведет себя тем или иным образом и какие эмоции вызывает у него текущее взаимодействие. Он дешев и прост, с ним справится даже неопытный исследователь.
Однако у него есть свои недостатки. Во-первых, для людей не слишком естественно все время «думать вслух». Они будут часто замолкать, и вам придется постоянно напоминать им, что надо продолжать говорить. Во-вторых, задания при таком методе выполняются несколько дольше, чем в реальной жизни. Кроме того, часть респондентов начинает пользоваться продуктом более вдумчиво. Проговаривая причины своих действий, они стараются действовать рациональнее, да и просто не хотят выглядеть идиотами, и вы можете не поймать какие-то интуитивные моменты их поведения.
Активное вмешательство модератора . Метод идеален для тестирования концепций и прототипов. Во время выполнения заданий модератор активно взаимодействует с пользователем: выясняет в нужные моменты причины его поведения и задает уточняющие вопросы. В некоторых случаях модератор даже может выдавать незапланированные задания, вытекающие из диалога.
Этот метод позволяет собрать максимальное количество качественных данных. Однако его можно применять, только если вы доверяете профессионализму своего модератора. Некорректно сформулированные или невовремя заданные вопросы могут сильно повлиять на поведение и впечатления респондента и даже сделать результаты теста невалидными. Также при использовании этого метода нельзя замерить практически никакие метрики.
Retrospective think aloud, RTA (ретроспектива). Это комбинация первых двух методов. Пользователь сначала выполняет все задания без вмешательства, а потом перед ним проигрывается видеозапись его работы, и он комментирует свое поведение и отвечает на вопросы модератора. Главный недостаток метода - сильно увеличивается время тестирования. Однако бывают случаи, когда он оптимален.
Например, один раз перед нами встала задача протестировать несколько видов мобов (игровых монстров) в одной RPG. Естественно, мы не могли ни отвлекать респондентов вопросами, ни заставлять их комментировать свои действия во время боя. Это бы сделало невозможным игру, где нужна концентрация для победы. С другой стороны, пользователь вряд ли смог бы после серии схваток вспомнить, заметил ли он загоревшуюся красным секиру у первой крысы. Поэтому в этом тесте мы воспользовались методом RTA. С каждым пользователем мы пересматривали его бои и обсуждали, какие эффекты монстров он заметил и как их понял.
Постарайтесь продумать, как получить достаточно данных, сохранив максимальную естественность поведения респондента. Несмотря на простоту и универсальность метода «мысли вслух», который долгое время был самым популярным в юзабилити-тестированиях, мы стараемся все чаще заменять его на наблюдение. Если модератор видит интересное поведение респондента - он подождет, пока тот выполнит задачу, и задаст вопрос после. Сразу после задания больше вероятность, что респондент помнит, почему он так сделал.
Очень помогает в этом вопросе айтрекер. Видя фокус текущего внимания респондента, вы можете лучше понять его поведение, не задавая лишних вопросов. Айтрекер вообще значительно улучшает качество модерирования, и эта его роль, на мой взгляд, не менее важна, чем возможность построения хитмапов.
Метрики
Метрики - это количественные показатели юзабилити. В результате тестирования вы всегда получаете набор найденных в интерфейсе проблем. Метрики же позволяют понять, насколько все хорошо или плохо, а также сравнить с другим проектом или предыдущими версиями дизайна.
Какие бывают метрики
По ISO 9241-11 основными характеристиками юзабилити являются эффективность, продуктивность и удовлетворенность. Для разных проектов могут быть актуальны разные метрики, но все они так или иначе завязаны на эти три характеристики. Я напишу о наиболее часто используемых показателях.
Успешность выполнения заданий. Можно использовать бинарный код: справился с заданием или не справился. Мы чаще придерживаемся подхода Нильсена и выделяем три вида оценок успешности:
- справился с заданием практически без проблем - 100%;
- столкнулся с проблемами, но выполнил задание самостоятельно - 50%;
- не справился с заданием - 0%.
Если из 12 респондентов 4 справились с заданием легко, 6 - с проблемами, а 2 потерпели фиаско, то средняя успешность по этому заданию будет 58%.
Иногда вы будете сталкиваться с ситуацией, когда в среднюю группу попадают очень разные по степени «проблемности» респонденты. Например, один респондент мучился над каждым полем формы, а второй лишь немного ошибся в самом конце. Вы можете давать оценку на собственное усмотрение, в зависимости от того, что произошло на тесте. Например, 25% - если респондент только начал выполнять задание, или 80% - если допустил незначительную ошибку.
Чтобы избежать слишком большой субъективности, продумайте шкалы оценок заранее, а не решайте для каждого респондента после теста. Также стоит подумать, что делать с ошибками. Например, вы дали задание купить билеты в кино на проекте «Кино Mail.Ru». Один из респондентов случайно купил билет не на завтра, а на сегодня, и не заметил этого. Он уверен, что справился с заданием и имеет билет на руках. Но его ошибка настолько критична, что он не попадет в кино, поэтому я бы поставила «0%», несмотря на то что билет куплен.
Процент успешности - очень простая и наглядная метрика, и я рекомендую ее использовать, если у ваших заданий есть четкие цели. Взгляд на график успешности по заданиям позволяет быстро определить самые проблемные места интерфейса.
Время выполнения заданий. Эта метрика показательна только в сравнении. Как вы поймете, плохо или хорошо то, что пользователь выполняет задачу за 30 секунд? А вот то, что время сократилось по сравнению с предыдущей версией дизайна, уже хорошо. Или то, что регистрация на нашем проекте занимает меньше времени, чем у конкурентов. Есть интерфейсы, где сокращение времени на выполнение задач критично - например, рабочий интерфейс сотрудника колл-центра.
Однако не для всех задач эта метрика применима. Возьмем задачу подбора товара в интернет-магазине. Пользователи должны быстро находить фильтры и другие элементы интерфейса, связанные с поиском товаров, но сам процесс выбора будет занимать у них разное время, и это совершенно нормально. Женщины при выборе туфель бывают готовы отсмотреть 20 страниц выдачи. И это необязательно значит, что на первых страницах не было подходящих товаров или что они не видят фильтры. Часто им просто хочется увидеть все варианты.
Частотность проблем. Любой отчет о юзабилити-тестировании содержит список проблем, с которыми столкнулись респонденты. Количество респондентов, которые столкнулись с проблемой, - показатель ее частотности в рамках теста. Эту метрику можно применять только в том случае, если ваши пользователи выполняли абсолютно одинаковые задания.
Если же в тесте были вариации или задания были не четко сформулированы, а составлены на основании интервью, то посчитать частотность будет сложно. Нужно будет не только считать столкнувшихся, но и оценивать, сколько респондентов могли бы столкнуться с проблемой (выполняли схожую задачу, заходили в тот же раздел). Тем не менее эта характеристика позволяет команде понять, какие проблемы стоит исправлять в первую очередь.
Субъективная удовлетворенность. Это субъективная оценка пользователем удобства или комфорта работы с системой. Выявляется она при помощи опросников, которые респонденты заполняют в процессе или после тестирования. Есть стандартные опросники. Например, System Usability Scale, Post-Study Usability Questionnaire или Game Experience Questionnaire для игр. Или вы можете составить собственный опросник.
Это далеко не единственные возможные метрики. Например, список из 10 UX-метрик, которые выделяет Джеф Сауро. Для вашего продукта метрики могут быть другими: например, с какого уровня респонденты разбираются в правилах игры, сколько ошибок допускают при заполнении длинных форм. Помните, что решение использовать многие метрики накладывает на тестирование ряд ограничений. Респонденты должны действовать максимально естественно и в одинаковых условиях. Поэтому хорошо бы обеспечить:
- Единые точки старта. Одни и те же задания для разных респондентов должны начинаться с одной и той же точки интерфейса. Вы можете после каждого задания просить респондентов вернуться на главную страницу.
- Отсутствие вмешательств. Любое общение с модератором может повлиять на метрики эффективности, если модератор невольно подскажет что-то респонденту, и увеличивает время выполнения задания.
- Порядок заданий. Чтобы компенсировать эффект обучения в сравнительном тестировании, обязательно меняйте порядок знакомства со сравниваемыми продуктами для разных респондентов. Пусть половина начинает с вашего проекта, а половина - с конкурентного.
- Критерии успешности. Заранее продумайте, какое именно поведение вы считаете успешным для задания: например, допустимо ли, чтобы при подборе товара в интернет магазине респондент не пользовался фильтрами.
Трактовка метрик
Помните, что классическое юзабилити-тестирование - это качественное исследование и полученные вами метрики в первую очередь иллюстративны. Они дают общий взгляд на разные сценарии в продукте, позволяя увидеть болевые точки. Например, настройки аккаунта вызывают больше сложностей, чем регистрация в системе. Они могут показать динамику изменений, если вы измеряете их регулярно. То есть метрики позволяют понять, что в новом дизайне выполнять задачу стали быстрее. Именно эти отношения гораздо более показательны и надежны, чем найденные абсолютные значения метрик.
Джеф Сауро, эксперт по статистике в UX-исследованиях, советует не представлять метрики средними значениями, а всегда считать доверительные интервалы. Это гораздо правильнее, особенно если в результатах респондентов присутствует разброс. Для этого можно воспользоваться его бесплатными онлайн-калькуляторами: для успешности и для времени выполнения заданий. Не обойтись без статистической обработки и при сравнении результатов.
Когда нужны метрики
Далеко не каждый отчет о юзабилити-тестировании содержит метрики. Их сбор и анализ требует времени и накладывает ограничения на методы проведения теста. Вот в каких случаях они действительно нужны:
- Доказать. Часто есть необходимость доказать, что в продукт нужно внести изменения, - особенно в крупных компаниях. Для лиц, принимающих решения, цифры наглядны, понятны и привычны. Когда вы показываете, что 10 из 12 респондентов не смогли оплатить товар или что регистрация в системе занимает в среднем в два раза больше времени, чем у конкурентов, - это придает результатам исследования больший вес.
- Сравнить. Если вы сравниваете свой продукт с другими на рынке, вам также не обойтись без метрик. Иначе вы увидите достоинства и недостатки разных проектов, но не сможете оценить, какое место ваш продукт занимает среди них.
- Увидеть изменения. Метрики хороши для регулярных тестов одного и того же продукта после внесения изменений. Они позволяют увидеть прогресс после редизайна, обратить внимание на те места, которые остались без улучшений. Использовать эти показатели вы можете опять же как доказательную базу, которая покажет руководству вес вложений в редизайн. Или просто для понимания того, что вы достигли результатов и движетесь в нужном направлении.
- Иллюстрировать, сделать акцент. Цифры хорошо помогают иллюстрировать важные проблемы. Иногда мы считаем их для наиболее ярких и важных моментов теста, даже если не используем метрики во всех заданиях.
Тем не менее мы используем метрики далеко не в каждом тесте. Можно обойтись без них, если исследователь плотно работает с командой проекта, есть внутреннее доверие и команда достаточно зрелая, чтобы грамотно расставить приоритеты решения проблем.
Способ фиксации данных
Казалось бы, чем плохи блокнотик и ручка или просто открытый документ Word? В современном Agile-мире разработки UX-исследователи должны стараться как можно быстрее выдавать команде результаты своих наблюдений.
Чтобы оптимизировать время на анализ, хорошо заранее заготовить шаблон для ввода заметок в процессе теста. Мы пробовали делать это в специализированном программном обеспечении (например, Noldus Observer или Morae Manager), но на практике наиболее гибкими и универсальными оказались таблицы. Заранее разметьте в таблице вопросы, которые точно планируете задавать, места под ввод проблем, обнаруженных в заданиях, а также гипотезы (на каждом респонденте вы будете помечать, подтвердились она или нет). Наши таблички выглядят подобным образом:
Чем еще вы можете воспользоваться:
- . Кастомизируемый шаблон Excel для ввода наблюдений по каждому респонденту. Встроен таймер, который измеряет время выполнения заданий, автоматически генерируются графики времени и успешности.
- Rainbow Spreadsheet от Томера Шерона из Google. Наглядная таблица для совместной работы исследователя и команды. Ссылка ведет на статью с описанием метода, там же есть ссылка на Google-таблицу с шаблоном.
С опытом большинство записей можно делать прямо во время теста. Если не успели вовремя, то лучше записать все, что помните, сразу после теста. Если возвращаться к анализу через несколько дней - скорее всего, придется пересмотреть видео и потратить гораздо больше времени.
Подготовка к тестированию
Помимо метода, метрик и непосредственно протокола тестирования, необходимо определиться со следующими вещами:
Формат общения с модератором. Модератор может находиться в одной комнате с участником тестирования. В этом случае ему будет легко вовремя задавать вопросы. Однако присутствие модератора может влиять на респондента: он начнет задавать вопросы модератору, провоцируя того явно или неявно ему подсказать.
Мы стараемся хотя бы на часть теста оставлять респондента наедине с продуктом. Так его поведение становится более раскованным и естественным. А чтобы не бегать туда-сюда, если что-то пойдет не так, можно оставить включенным любой мессенджер с аудиосвязью, чтобы модератор мог связаться с респондентом из наблюдательной комнаты.
Способ постановки заданий. Задания может озвучивать модератор. Но в этом случае, несмотря на единый протокол тестирования, текст задания может каждый раз произноситься немного по-разному. Особенно это актуально, если тест ведет несколько модераторов. Иногда даже небольшие различия в формулировках могут поставить респондентов в разные начальные условия.
Чтобы этого избежать, можно либо «надрессировать» модераторов всегда читать тексты задания, либо выдавать респондентам задания на листочках или на экране. Различие формулировок перестает быть проблемой, если использовать гибкий сценарий, когда задания формулируются в процессе теста, на основании интервью с модератором.
Можно использовать средства продукта для постановки заданий. Например, при тестировании ICQ задания респонденты получали через окно чата с модератором, а при тестировании «Почты Mail.Ru» они приходили в письмах. Такой способ постановки заданий был максимально естественным для этих проектов, а еще мы многократно обкатывали базовые сценарии переписки.
Создание естественного контекста. Даже если мы говорим о лабораторных исследованиях, подумайте, как приблизить использование продукта на тесте к реальным условиям. Например, если вы тестируете мобильные устройства, то как респонденты будут их держать? Для хорошего изображения на видеозаписи лучше, когда телефон или планшет фиксированы на стенде или лежат на столе. Однако это не дает понять, все ли зоны доступны и удобны для нажатия, ведь телефоны часто держат одной рукой, а с планшетами лежат на диване.
Стоит подумать об обстановке, в которой будет использоваться продукт: отвлекает ли что-то человека, шумно ли, хороший ли интернет. Все это можно имитировать в лаборатории.
План теста для заказчика. Это также важный этап подготовки, так как он вовлекает проектную команду. Вы можете не посвящать заказчика во все методологические особенности теста (как будете общаться с респондентом, фиксировать данные и прочее). Но обязательно покажите ему, какие будут задания и что вы на них собираетесь проверять. Возможно, вы не учли какие-то особенности проекта, а может быть, у команды проекта появятся дополнительные идеи и гипотезы. У нас обычно получается подобная табличка:
План отчета. Естественно, отчет пишется по результатам исследования. Но есть хорошая практика - составлять план отчета еще до проведения тестов, основываясь на целях и задачах исследования. С таким планом перед глазами вы сможете проверить свой сценарий на полноту, а также подготовить наиболее удобные формы, чтобы зафиксировать данные для последующего анализа. Возможно, вы решите, что отчёт не нужен и достаточно общего файла с наблюдениями для вас и команды. А если вы мотивируете команду заполнять его вместе с вами, будет совсем здорово.
Конечно, вы можете просто «дать попользоваться продуктом» своему другу и наблюдать за тем, какие сложности у него возникнут. Но грамотно составленный сценарий позволит не упустить важные проблемы и не натолкнуть случайно респондента на нужные вам ответы. Ведь юзабилити-тестирование - это упрощенный эксперимент, а в любом эксперименте важна предварительная подготовка.
Протокол любого юзабилити-тестирования состоит из следующих частей:
- Инструктаж или брифинг (приветствие, описание мероприятия, подписание документов).
- Вводное интервью (проверка скрининга, небольшое интервью об использовании продукта, контексте и сценариях).
- Работа с продуктом (задания тестирования).
- Сбор итоговых впечатлений от продукта на основании опыта тестирования.
Инструктаж или брифинг
Независимо от предмета тестирования любое исследование начинается одинаково. Что нужно сделать:
Создать атмосферу. Познакомьтесь с человеком, предложите ему чай, кофе или воду, покажите, где туалет. Постарайтесь немного расслабить респондента, ведь он может нервничать перед мероприятием. Узнайте, легко ли было вас найти, спросите, как настроение.
Описать процесс. Расскажите, что за мероприятие ждет респондента, сколько времени оно займет, из каких частей оно состоит, что вы будете делать. Обязательно обратите внимание респондента на то, что его вклад поможет улучшить продукт и что вы не тестируете способности человека. Если вы ведете видеозапись, предупредите об этом респондента и скажите ему, что данные не появятся в сети. Я говорю примерно следующее:
Мы находимся в офисе компании Mail.Ru Group. Сегодня мы поговорим о проекте ХХХ. Это займет около часа. Сначала мы немного побеседуем, потом я попрошу вас что-то попробовать сделать в самом проекте, а после мы обсудим ваши впечатления. Мы будем вести видеозапись того, что происходит в комнате и на экране компьютера. Запись нужна исключительно для анализа, в интернете вы себя не увидите.
Мы проводим исследование, чтобы сделать проект ХХХ лучше, понять, что в нем нужно исправить и в какую сторону ему развиваться. Поэтому очень прошу вас открыто высказывать любые комментарии: и положительные, и отрицательные. Не бойтесь нас обидеть. Если при изучении проекта у вас что-то не получится, относитесь к этому спокойно. Значит, мы с вами нашли проблему, которую команде проекта нужно исправить. Главное - помните, что мы не тестируем вас, это вы тестируете продукт. Если вы готовы, предлагаю начинать.
Подписать документы. Как правило, это согласие на обработку персональных данных, а иногда еще соглашение о неразглашении информации о тестировании. Для тестов с несовершеннолетними необходимо согласие родителей на участие их ребенка в исследовании. Обычно мы высылаем его родителям заранее и просим принести с собой. Обязательно объясните, зачем вы просите подписать документы, и дайте время изучить их. В России люди с опаской относятся к любым бумагам, которые требуется подписать.
Настроить оборудование. Если вы используете айтрекинг, биометрическое оборудование или просто ведете видеозапись - самое время все это включить. Предупредите респондента, когда начнете запись.
Вводное интервью
Оно решает следующие задачи:
Проверить рекрутинг. На всякий случай всегда начинайте с этого - даже если вы доверяете агентству или человеку, который нашел респондента. Не раз уже на тесте мы выясняли, что респондент неправильно понял вопросы и на самом деле пользуется продуктом не совсем так, как нам нужно. Старайтесь отойти от формальности и не задавать вопросы из скринингового опросника: человек может уже знать, что отвечать на них.
Сценарии и контекст использования продукта. Даже если у вас мало времени на тест, не пропускайте этот пункт. Хотя бы в целом узнайте у респондента, какие задачи он решает при помощи продукта, пользуется ли аналогичными проектами, в каких условиях взаимодействует с ними и с каких устройств. Ответы помогут вам лучше понимать причины поведения респондента, а если вы применяете гибкий сценарий - то и формулировать подходящие задания. Если хватает времени, попросите респондента показать, что и как он обычно делает. Это бывает источником дальнейших вопросов и инсайтов.
Ожидания и отношения. Начало тестирования - хороший момент, чтобы узнать, что респондент знает о продукте, как относится к нему и чего от него ожидает. После теста вы сможете сравнить ожидания с итоговым впечатлением.
Для большинства тестов подойдет такая структура вводного интервью. Если вы тестируете новый продукт, то, возможно, стоит пропустить вводные вопросы. Если вы начнете слишком подробно обсуждать какую-то тему, это может создать у пользователя определенные ожидания от продукта. Поэтому оставьте только пару общих вопросов, чтобы наладить контакт с респондентом, и сразу же переходите к заданиям, а обсуждать сценарии, отношения и контекст лучше после того, как пользователь первично изучит продукт.
Работа с продуктом, составление заданий
Какие бывают задания
Давайте представим, что вы хотите протестировать интернет-магазин. У вас есть важные сценарии (поиск и выбор товара, процесс оформления заказа), известные проблемы (частые ошибки в форме оплаты) и даже гипотеза, что дизайнер что-то намудрил с фильтром по цене. Как же сформулировать задания?
Сфокусированные задания. Кажется очевидным сделать примерно такое задание: «Выберите посудомоечную машину шириной 45 сантиметров с функцией "луч на полу" стоимостью не более 30 тысяч рублей». Это мотивирует респондента пользоваться фильтрами и сравнивать товары между собой. Вы сможете проверить фильтр по цене на всех респондентах и посмотреть на ключевой сценарий подбора товара. Подобные задания вполне имеют право на жизнь и хороши для проверки конкретных гипотез (как с фильтром по цене).
Однако, если весь тест будет состоять из них, то вы рискуете следующим:
- Точечная проверка интерфейса. Вы найдете только те проблемы, которые связаны с деталями задания (фильтр по цене и ширине). Вы не увидите прочих проблем - например, сортировки товаров или других фильтров, - если не укажете и на них. А сделать задания для всех элементов сайта вы вряд ли сможете.
- Отсутствие вовлечения. Подобные задания пользователи часто выполняют механически. Увидев первый товар, подходящий под критерии, они останавливаются. Возможно, в жизни респондент никогда не выбирал посудомойки и ему все равно, что такое «луч на полу». Чем больше задание походит на ситуацию из реальной жизни и чем больше в нём контекста, понятного пользователю, тем выше шансы вовлечь респондента, который представит, что на самом деле выбирает товар. А вовлеченный пользователь лучше «проживает» интерфейс, оставляет больше комментариев, повышаются его шансы найти проблемы и дать полезные знания о поведении и особенностях аудитории.
- Суженный спектр инсайтов. В реальной жизни пользователь, возможно, подбирал бы товар совсем не так. Например, вообще не пользовался бы фильтрами (а тут вы на них указали). Или искал бы товар по критериям, которых нет на сайте. Давая жесткие, сфокусированные задания, вы не узнаете о реальном контексте использования продукта, не найдете сценариев, которые команда проекта, возможно, не предусмотрела, не соберете данные о потребностях в контенте и функциональности.
Задания с контекстом. Один из способов лучше вовлечь пользователей - добавить в сухое задание реальную историю и контекст. Например, вместо «Найдите на сайте рецепт пирога со сливами» предложите следующее: «Через час к вам придут гости. Найдите, что можно испечь за это время. У вас в холодильнике есть все для бисквита, а также немножко слив. Но, к сожалению, нет сливочного масла».
Подобный подход можно использовать и с интернет-магазином. Например: «Представьте, что вы выбираете подарок сестре. У нее недавно сломался фен, и она была бы рада получить новый. Вам нужно уложиться в 7 тысяч рублей». Важно, чтобы респондент действительно выбрал реального человека, которому будет «покупать» подарок (если нет сестры, предложите другого родственника или подругу). Ключевой фактор для подобных заданий - реальность и понятность контекста. Легко представить, что ты выбираешь подарок родным, куда труднее - что ты «бухгалтер, составляющий годовой отчет».
Яркий пример такого подхода - «метод Болливуда», который придумала индийский UX-эксперт Апала Лахири Чаван. Она утверждает, что индусам, как и многим азиатам, сложно открыто высказывать мнение об интерфейсе. Зато, представляя себя героями вымышленных драматических ситуаций (как в любимых ими фильмах), они раскрываются и начинают живо участвовать в тестировании. Поэтому задания для индусов должны выглядеть примерно так:
Представьте, что ваша любимая юная племянница собирается замуж. И тут вы узнаете, что ее будущий муж - мошенник, да еще и женатый. Вам нужно срочно купить два билета на рейс до Бангалора для себя и для жены обманщика, чтобы расстроить свадьбу и спасти семью от позора. Торопитесь!
Задания с опорой на опыт респондентов. Напомним: для успешного тестирования респонденты должны соответствовать аудитории проекта. Поэтому для проверки интернет-магазина бытовой техники мы рекрутируем тех, кто недавно выбирал технику или выбирает ее сейчас. Именно этим мы будем пользоваться, составляя задания с опорой на опыт респондентов. Есть два варианта использования такого подхода:
- Параметры респондентов. В этом случае вы адаптируете фиксированные задания под респондентов. Например, в случае с магазином бытовой техники и задачей на работу с фильтрами уточняете у человека, что именно он недавно приобрел. Узнаете критерии (цена, функции) и предлагаете повторить «покупку» на вашем сайте.
- Сценарии респондентов. Задания полностью формируются с опорой на опыт участников. Чтобы понять, какие сценарии проверить, модератор выясняет, как именно человек решал задачу в жизни, и предлагает сделать это на сайте. Например, покупатель перед выбором долго сравнивал между собой несколько моделей. Даже если на сайте нет подходящей функции, предложите респонденту сравнить товары, чтобы понять, на какие параметры он станет опираться. Возможно, вы получите идеи, как должна выглядеть функция сравнения, а также адаптируете под этот сценарий страницу товара.
Подобные задания дают много реальных примеров выполнения базовых операций в продукте. Это часто порождает гораздо больший спектр проблем и находок. Кроме того, позволяет проверить продукт на новых сценариях, которые вы не считали основными или даже не продумывали.
Когда мы тестировали проект «Недвижимость Mail.Ru», много открытий помогли сделать именно задания с опорой на опыт респондентов. Мы увидели, что люди при поиске квартиры в Подмосковье указывают в геофильтре конечные станции метро, имея в виду, что это станции, до которых можно доехать из области. Мы же рассчитывали, что фильтр по метро ищет квартиру недалеко от станции. Также мы узнали, чем отличаются сценарии поиска новостроек от вторички, что помогло вынести поиск новостроек в другой раздел на сайте - со своими фильтрами и своей концепцией описания квартир. Советую также прочитать отличную Джареда Спула о пользе подобных заданий.
Задания без заданий. Иногда лучше вообще не предлагать пользователям задания на работу с проектом, а посмотреть, с чего они сами начнут знакомство с продуктом. Дайте респонденту вводную: «Представьте, что вы решили попробовать этот продукт. Я оставлю вас на несколько минут. Делайте то, что вы стали бы делать в реальной жизни. Я не даю вам никаких заданий».
Важно, чтобы модератор при этом выходил из комнаты. В противном случае у пользователя появляется соблазн сразу же что-то спросить, уточнить: «А надо ли регистрироваться? А как вот это сделать?» и так далее.
Данный тип заданий полезен для полностью новых продуктов. Мы часто применяем его для мобильных приложений и игр. Так мы узнаем, читают ли пользователи обучающие материалы, какие детали сразу привлекают внимание, что люди понимают в концепции продукта, как потом описывают его возможности. Уже после свободного задания идут запланированные конкретные сценарии.
Еще одна область применения свободных заданий - контентные проекты. Если вы хотите понять, как читают ваши статьи (где надолго задерживаются, что пропускают, на какие элементы на странице обращают внимание), то просто оставьте респондента на несколько минут наедине с проектом. Только без модератора, смотрящего через плечо, пользователь расслабится и будет читать текст так же, как обычно. Так мы тестируем проекты «Новости Mail.Ru», «Леди Mail.Ru»и другие. Этот подход позволил выделить разные модели поведения на сайте, разные паттерны чтения статей и понять, какие типы материалов стоит оформлять по-другому.
Составляем хорошие задания
Первое задание - простое. Начинайте тестирование с ознакомительных и несложных заданий. Респондент должен освоиться с форматом тестирования, особенно если вы используете метод «мысли вслух»: ему нужно привыкнуть к необходимости озвучивать свои мысли и чувства. Не стоит сразу вываливать на него всю боль и страдания интерфейса.
Не подсказывайте. Сформулируйте задания так, чтобы не подсказывать респонденту правильных действий. Если вы хотите протестировать возможность добавлять товары в избранное в интернет-магазине - обойдитесь без задания «Давайте добавим вот этот телевизор в избранное», особенно если кнопка так и называется. Респондент, прочитав задание, будет просто находить на экране кнопку с нужной подписью - возможно, даже не понимая, что именно он делает.
Лучше объяснить смысл задания, не прибегая к терминам в интерфейсе. Например: «На сайте есть возможность сохранить понравившиеся товары и потом выбрать, что из них заказать. Давайте попробуем сделать это с таким-то телевизором».
Следите за терминологией. Не используйте непонятные слова и обозначения. Это кажется очевидным, но мы, привыкнув к каким-то терминам, часто забываем, что их мало кто знает за пределами ИТ-тусовки. Например, при тестировании новой функциональности тредов (цепочек писем) в «Почте Mail.Ru» нам пришлось сложно. Ведь у пользователей, незнакомых с этой функцией, просто нет в голове термина, который бы обозначал треды.
В итоге мы никак их не называли. Мы просто показывали респондентам ящик с подключенными цепочками и обсуждали эту новую возможность, причем давали пользователям самим подобрать слово для обозначения тредов. Это помогло нам позже использовать наиболее понятные тексты в обучающих промоматериалах.
Следите не только за заданиями, но и за вопросами модератора, особенно за теми, которые приходят от команды во время тестирования. Например, при обсуждении функций не стоит использовать слово «тулбар»: оно знакомо не всем. Ещё несколько лет назад далеко не все пользователи знали даже слово «браузер». То, как именно лучше сформулировать задания, зависит от аудитории тестирования. Не стоит кидаться и в другую крайность, объясняя все термины подряд. Например, опытным игрокам не надо растолковывать, что такое «баф», «фраг», «респаун» и так далее.
Меньше тестового. Часто велик соблазн сделать респонденту тестовый аккаунт в системе и проводить тестирование на нем. Ведь можно заранее все обкатать в этом аккаунте, избежать накладок и не тратить время на регистрацию или авторизацию респондента. Часто еще и технически гораздо легче включить новый дизайн на тестовых, а не на реальных данных.
Однако при таком подходе вы рискуете получить гораздо меньше полезных результатов, ведь у тестовых действий нет реальных последствий. Ситуация становится совсем искусственной, пользователям сложно проецировать ее на реальный опыт.
Например, при работе в собственном аккаунте в соцсети респонденты, как и в реальной жизни, будут аккуратно делать все, что могут увидеть их друзья (публиковать ссылки, отправлять сообщения). При настройках собственного ящика в почте они постараются не удалить важные письма. При тестировании интернет-магазинов иногда применяют подход, когда вознаграждение нужно потратить прямо на тесте. В таком случае респондент не ткнет в первый подходящий по заданию товар, а подберет то, что ему на самом деле нужно.
Имея одни лишь тестовые данные, вы найдете проблемы, связанные только с ними, а не проверите функциональность на разных вариациях. Например, когда мы тестировали социальную панель браузера «Амиго», один из респондентов, подключивший в панель свой аккаунт «ВКонтакте», сразу отметил, что так читать ему неудобно. Почти вся лента состояла из подписок на группы с эротическими фотографиями. А в узкой панели на картинках было просто ничего не разглядеть.
Еще одна проблема тестовых данных - сложно разобраться в системе, так как все вокруг непривычное. Например, пользователь соцсети привык узнавать свою страницу по собственной фотографии. Даже тестируя прототипы, мы стараемся максимально их персонализировать. Например, при тестировании кликабельных прототипов в «Одноклассниках» мы всегда адаптируем их для каждого пользователя, вставляя на страницу его имя и фотографию, а иногда и последние новости.
Не ограничивайтесь интерфейсом. Не забывайте о том, что взаимодействие с продуктом часто не ограничивается одним лишь интерфейсом. Если есть возможность, тестируйте сопутствующие продукты или сервисы и связи между ними. При тестировании игр мы стараемся проверить не только игру, но и ее сайт и связанные с ним загрузку, регистрацию в игре, поиск информации на форуме. А при тестировании одного интернет-магазина я также проверяла звонок оператора после оформления заказа, что дало рекомендации для колл-центра.
Думайте о тайминге. Для хорошего сценария важно расставлять приоритеты задач. Скорее всего, если система большая и целей у теста много, вам захочется сделать очень много заданий. Однако уставший респондент уже не будет полезен. Хороший тест длится не больше полутора часов, два - это максимум. Исключение - разве что игры. И помните, что ваши цели - не только задания, но и интервью, опросники, настройка оборудования и подписание документов. Все это обычно занимает не менее получаса.
Если заданий слишком много, а отказываться от каких-то не хочется, можете наименее приоритетные пустить в ротацию, то есть показывать только части респондентов. Или сделать часть теста обязательной для всех, а остальное смотреть только с теми, с кем хватит времени. Но это, скорее всего, будут наиболее успешные респонденты.
Оценивайте полезность задания. Подумайте, действительно ли оно соответствует вашим гипотезам. Например, вы хотите проверить функцию подписки на новости на сайте. Задание «Подпишитесь на новостную рассылку» позволит проверить только то, смогут ли найти рассылку те, кто будет ее искать. Однако люди редко приходят на сайт, чтобы подписаться на новости. Задание не относится к реальной жизни. Вам же нужно понять, замечают ли возможность подписки те, кто выполняет совсем другие задачи.
Проверять это можно разными способами - в зависимости от реализации функции. Если человек занимался заданиями, в которых ему на глаза могла попасть возможность подписки, спросите его, есть ли она на сайте. Только обязательно уточните, где он видел эту возможность или как она реализована, чтобы удостовериться, что респондент не просто с вами соглашается.
Если предложение подписки встроено в процесс регистрации или оформления заказа -посмотрите, воспользуется ли им респондент, а после задания обсудите это. Очень мало шансов, что в лабораторных условиях люди реально подпишутся на рассылки, но можно проверить, обратил ли человек внимание на такую возможность, чего он ожидает от рассылки и так далее.
Сбор итоговых впечатлений
Цель заключительной фазы тестирования - собрать впечатления от работы с продуктом, понять, что понравилось пользователю, а что его расстроило, оценить субъективную удовлетворенность. Как правило, в этой части теста используется сочетание интервью с модератором и заполнения формальных опросников.
Интервью с модератором
В итоговом интервью мы всегда задаем респондентам примерно одни и те же вопросы: «Какие впечатления остались?», «Что понравилось, а что нет?», «Было ли то, что показалось сложным или неудобным?», «Чего не хватало?», «Что хотелось бы изменить в продукте?». Самое время уточнить непонятные моменты поведения респондента, если вы не сделали этого в процессе теста. Если вы до теста узнавали у пользователей отношение к бренду или продукту и ожидания от него - выясните, изменилось ли что-нибудь. При интервью обращайте внимание на следующее:
Социальная желательность. Обращайтесь с результатами интервью очень аккуратно. Если во время теста вы часто слышите импульсивные комментарии под влиянием проблем, то в финальном интервью вовсю расцветает социальная желательность.
Одним кажется, что, говоря о проблемах в продукте, они признаются в собственной некомпетентности. Другие просто не хотят расстраивать приятного в общении модератора. Очень часто респонденты (особенно женщины), которые промучились весь тест, говорят, что все, в принципе, нормально. Отрицательные отзывы также могут быть продиктованы социальной желательностью: если респондент уверен, что цель теста - найти недостатки, он старательно пытается их отыскать.
Цитаты и приоритеты. Хотя все слова участников теста в финальном интервью часто нужно делить на два, а то и на десять, это не значит, что они бесполезны. По тому, как респонденты подытоживают впечатления, вы можете сделать вывод о приоритетах. Продукт - «полный отстой»? Что именно повлияло на это? Какую из многих проблем респондент запомнил больше всего и считает самой раздражающей?
Однако делайте скидку на то, что лучше всего запоминается последнее задание. Также очень полезно отслеживать, какими прилагательными респонденты описывают продукт, с чем сравнивают свой опыт.
Не забываем о хорошем. Очень часто отчет о юзабилити-тестировании - это длинный перечень найденных во время теста проблем. В общем-то, поиск проблем - одна из основных задач исследования. Но не забывайте и о положительных сторонах продукта.
Во-первых, отчет без положительных результатов просто демотивирует команду. А во-вторых, полезно знать, что пользователям в продукте нравится: вдруг при следующем редизайне решат убрать функцию, которая так всем приглянулась. Поэтому обязательно спрашивайте у респондентов о положительных сторонах продукта, даже если они ругали интерфейс в течение всего тестирования.
Отношение к «хотелкам». Скорее всего, респонденты, помимо своих впечатлений, будут высказывать пожелания и идеи. Ваша задача - понять, какая проблема стоит за предложениями. Потому что решения, которые предложат пользователи, с высокой вероятностью вам не подойдут. Ведь участники тестирования не дизайнеры, они не в курсе особенностей и ограничений разработки. Тем не менее за любым подобным запросом стоит потребность, которую вы должны зафиксировать. Если респондент говорит, что ему вот здесь непременно нужна большая зеленая кнопка, обязательно спросите: а зачем?
Мера удовлетворенности
Часто по словам респондента в финальном интервью сложно понять, понравился ему продукт или нет, а уж тем более трудно сравнить отношение нескольких респондентов, которые и плюсы отмечали, и недостатки находили. Тут на помощь исследователю приходят опросники. Во-первых, при заполнении опросника (особенно до разговора с модератором) чуть меньше влияние пресловутой социальной желательности, хотя полностью вы от него не избавитесь. Во-вторых, опросник дает вам четкие параметры для сравнения сценариев, продуктов или стадий проекта.
Составление хорошего опросника - отдельная и очень большая тема. Тут важны и формулировки, и шкалы, и многое другое. Хорошим подспорьем могут стать готовые и проверенные опросники: они уже отточены и многократно протестированы. Проблема только в том, что почти у всех этих анкет нет официальных переводов на русский. Естественно, вы можете перевести их самостоятельно, но с методологической точки зрения переводы нужно протестировать, чтобы проверить корректность формулировок. Тем не менее анкеты могут стать ориентиром при составлении собственных опросников.
Есть опросники, которые даются после каждого задания, чтобы оценить удовлетворенность от конкретных сценариев. Например:
- After Scenario Questionnaire (ASQ) . Три вопроса о сложности, продуктивности и подсказках в системе.
- Single Ease Question (SEQ) . Один вопрос о сложности сценария.
А есть анкеты, которые применяются уже в заключительной фазе тестирования. Вот несколько примеров, которые мы используем при необходимости:
- System Usability Scale и Post-Study System Usability Questionnaire . Два классических и популярных опросника, созданных более 20 лет назад. Оба состоят из утверждений. Респонденты должны указать степень согласия с ними. Все эти утверждения с разных сторон характеризуют юзабилити продукта. Например: «Я легко мог найти нужную информацию», «Разные возможности системы легко доступны» и так далее.
- . Опросник, который часто помогает нам на тестах. Пользователю предоставляется набор прилагательных, из которых он выбирает те, что могут характеризовать продукт. В итоге вы получаете облако слов - характеристик вашего проекта. Часто эта методика приносит очень интересные результаты.
- Game Experience Questionnaire . К играм нельзя применять классические юзабилити-опросники: вовлеченность в игровой процесс гораздо важнее, чем понятность интерфейсов. Поэтому для игр нужно всегда составлять особые опросники или пользоваться Game Experience Questionnaire. Опросник содержит несколько модулей: базовый модуль, внутриигровой блок, постопросник и опросник социальных возможностей игры. Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.
Подготовка, интервью и сбор данных
В закладки
Руководитель направления UX-исследований Mail.Ru Group Наталия Спрогис в блоге компании на «Хабрахабре» рассказала о подготовке и проведении юзабилити-тестирований: что включить в сценарий теста, как выбрать метод сбора данных, составить задания и собрать впечатления респондентов.
План тестирования - это, с одной стороны набор заданий, вопросов и опросников, которые вы даете каждому респонденту, а с другой - методологическая база исследования: метрики и гипотезы, которые вы проверяете и фиксируете, выбранный инструментарий.
Точно ли нужно тестирование
Для начала вы должны быть уверены, что на данном этапе проекту нужно именно юзабилити-тестирование. Поэтому уточняйте, с какой целью к вам обращается проектная команда. Юзабилити-тестирования не всемогущи, и уже на старте нужно понимать, что оно может принести продукту. Сразу подготовьте проектную команду к тому, на какие вопросы вы сможете дать ответы, а на какие нет. Бывали случаи, когда мы либо предлагали заказчикам другой метод (например, сейчас лучше подойдут глубинные интервью или дневниковые исследования), либо рекомендовали вообще отказаться от исследования, а вместо этого сделать сплит-тест.
Например, мы никогда не беремся в качественных исследованиях проверять «привлекательность» какой-то функции или варианта дизайна. Мы можем собрать с пользователей отзывы, но слишком велик риск, что на их ответы повлияет социальная желательность. Люди всегда склонны сказать, что стали бы пользоваться даже тем, чем пользоваться не будут. Да и маленький размер выборки не позволяет доверять таким ответам. Например, у нас был неудачный опыт тестирования игровых лендингов: лендинг, который выбирали как наиболее привлекательный на тесте, при A/B-тестировании отработал гораздо хуже.
Ряд ограничений есть и у тестирования прототипов и концепций. При планировании вы должны понимать, что реально можно «выжать» из этого теста. Здорово, когда у проекта есть возможность протестировать прототипы или дизайн до внедрения. Однако, чем менее детальный и рабочий прототип, чем выше уровень абстракции для респондента, тем меньше данных можно получить из теста. Лучше всего на тестировании прототипов выявляются проблемы нейминга и метафор иконок, то есть все вопросы понятности. Возможность проверить что-то сверх этого сильно зависит от сути проекта и детальности проработки прототипа.
Основа для составления сценария юзабилити-теста
Планирование тестирования начинается не с составления текста заданий, а с детальной проработки целей и вопросов исследования совместно с проектной командой. Вот основа для составления плана:
Важные сценарии. Это те пользовательские сценарии (задачи, или юзкейсы), которые влияют на бизнес или связаны с целью тестирования. Даже если команда подозревает проблемы в конкретных местах, часто стоит проверить основные кейсы. При этом важными для теста могут считаться следующие сценарии:
- наиболее частотные (например, отправка сообщения в мессенджере);
- влияющие на бизнес-цели (например, работа с платежной формой);
- связанные с обновлением (те, которые затронул редизайн или внедрение новой функциональности).
Известные проблемы. Часто исследование должно дать ответ на причины бизнес-проблем сервиса. Например, продюсера беспокоит большой отток игроков после первого часа игры. А иногда проблемные места интерфейса уже известны команде, и вам необходимо собрать подробности и конкретику. Например, в службу поддержки часто обращаются с вопросами по форме оплаты.
Вопросы. У команды также могут быть вопросы для исследования: например, замечают ли пользователи баннер, рекламирующий дополнительные услуги; понятно ли назван определенный раздел.
Гипотезы. Это то, во что преобразуются известные проблемы и вопросы команды. Хорошо, если заказчик приходит к вам с готовыми гипотезами - например, «Наши клиенты платят только с телефона с комиссией. Возможно, пользователи не видят выбора более выгодного способа оплаты». Если же гипотез нет, а есть только желание проверить проект абстрактно «на юзабилити», ваша задача - эти гипотезы сформулировать.
Подумайте совместно с проектной командой о тех местах, где пользователи ведут себя не так, как ожидается (если такая информация есть). Выясните, нет ли элементов дизайна, над которыми много спорили и которые могут оказаться проблемными. Сделайте собственный аудит продукта, чтобы найти потенциальные сложности для пользователей, которые важно проверить на тесте. Все это поможет вам составить список тех элементов (заданий, вопросов, проверок), которые должны войти в итоговый сценарий.
Метод сбора данных
Важно продумать, как вы будете собирать данные о происходящем во время теста для последующего анализа. Традиционно используются следующие варианты:
Наблюдение. Во время выполнения заданий респондент остается наедине с продуктом и ведет себя так, как считает нужным. Комментарии респондента собираются посредством опросников и общения с модератором после теста. Это наиболее «чистый» метод, он обеспечивает более естественное поведение респондента и возможность корректно измерить ряд метрик (например, время выполнения задания).
Однако за кадром остается много полезных качественных данных. Увидев то или иное поведение респондента, вы не можете понять, почему он так действует. Конечно, можно спросить об этом в конце теста, но, скорее всего, респондент будет хорошо помнить только последнее задание. Кроме того, за время выполнения заданий его мнение о системе может меняться, и вы получите только итоговую картину, а не первые впечатления.
Think Aloud (мысли вслух). Долгое время этот метод использовался в юзабилити-тестированиях чаще всего. Якоб Нильсен в свое время называл его главным инструментом оценки юзабилити. Суть в том, что вы просите респондента озвучивать все мысли, возникающие у него при работе с интерфейсом, и комментировать все свои действия. Это выглядит примерно так: «Сейчас я собираюсь добавить этот товар в корзину. А где же кнопка? А, вот она. Ой, я забыл посмотреть, какой там был цвет».
Метод помогает понять, почему пользователь ведет себя тем или иным образом и какие эмоции вызывает у него текущее взаимодействие. Он дешев и прост, с ним справится даже неопытный исследователь.
Однако у него есть свои недостатки. Во-первых, для людей не слишком естественно все время «думать вслух». Они будут часто замолкать, и вам придется постоянно напоминать им, что надо продолжать говорить. Во-вторых, задания при таком методе выполняются несколько дольше, чем в реальной жизни. Кроме того, часть респондентов начинает пользоваться продуктом более вдумчиво. Проговаривая причины своих действий, они стараются действовать рациональнее, да и просто не хотят выглядеть идиотами, и вы можете не поймать какие-то интуитивные моменты их поведения.
Активное вмешательство модератора . Метод идеален для тестирования концепций и прототипов. Во время выполнения заданий модератор активно взаимодействует с пользователем: выясняет в нужные моменты причины его поведения и задает уточняющие вопросы. В некоторых случаях модератор даже может выдавать незапланированные задания, вытекающие из диалога.
Этот метод позволяет собрать максимальное количество качественных данных. Однако его можно применять, только если вы доверяете профессионализму своего модератора. Некорректно сформулированные или невовремя заданные вопросы могут сильно повлиять на поведение и впечатления респондента и даже сделать результаты теста невалидными. Также при использовании этого метода нельзя замерить практически никакие метрики.
Retrospective think aloud, RTA (ретроспектива). Это комбинация первых двух методов. Пользователь сначала выполняет все задания без вмешательства, а потом перед ним проигрывается видеозапись его работы, и он комментирует свое поведение и отвечает на вопросы модератора. Главный недостаток метода - сильно увеличивается время тестирования. Однако бывают случаи, когда он оптимален.
Например, один раз перед нами встала задача протестировать несколько видов мобов (игровых монстров) в одной RPG. Естественно, мы не могли ни отвлекать респондентов вопросами, ни заставлять их комментировать свои действия во время боя. Это бы сделало невозможным игру, где нужна концентрация для победы. С другой стороны, пользователь вряд ли смог бы после серии схваток вспомнить, заметил ли он загоревшуюся красным секиру у первой крысы. Поэтому в этом тесте мы воспользовались методом RTA. С каждым пользователем мы пересматривали его бои и обсуждали, какие эффекты монстров он заметил и как их понял.
Постарайтесь продумать, как получить достаточно данных, сохранив максимальную естественность поведения респондента. Несмотря на простоту и универсальность метода «мысли вслух», который долгое время был самым популярным в юзабилити-тестированиях, мы стараемся все чаще заменять его на наблюдение. Если модератор видит интересное поведение респондента - он подождет, пока тот выполнит задачу, и задаст вопрос после. Сразу после задания больше вероятность, что респондент помнит, почему он так сделал.
Очень помогает в этом вопросе айтрекер. Видя фокус текущего внимания респондента, вы можете лучше понять его поведение, не задавая лишних вопросов. Айтрекер вообще значительно улучшает качество модерирования, и эта его роль, на мой взгляд, не менее важна, чем возможность построения хитмапов.
Метрики
Метрики - это количественные показатели юзабилити. В результате тестирования вы всегда получаете набор найденных в интерфейсе проблем. Метрики же позволяют понять, насколько все хорошо или плохо, а также сравнить с другим проектом или предыдущими версиями дизайна.
Какие бывают метрики
По ISO 9241-11 основными характеристиками юзабилити являются эффективность, продуктивность и удовлетворенность. Для разных проектов могут быть актуальны разные метрики, но все они так или иначе завязаны на эти три характеристики. Я напишу о наиболее часто используемых показателях.
Успешность выполнения заданий. Можно использовать бинарный код: справился с заданием или не справился. Мы чаще придерживаемся подхода Нильсена и выделяем три вида оценок успешности:
- справился с заданием практически без проблем - 100%;
- столкнулся с проблемами, но выполнил задание самостоятельно - 50%;
- не справился с заданием - 0%.
Если из 12 респондентов 4 справились с заданием легко, 6 - с проблемами, а 2 потерпели фиаско, то средняя успешность по этому заданию будет 58%.
Иногда вы будете сталкиваться с ситуацией, когда в среднюю группу попадают очень разные по степени «проблемности» респонденты. Например, один респондент мучился над каждым полем формы, а второй лишь немного ошибся в самом конце. Вы можете давать оценку на собственное усмотрение, в зависимости от того, что произошло на тесте. Например, 25% - если респондент только начал выполнять задание, или 80% - если допустил незначительную ошибку.
Чтобы избежать слишком большой субъективности, продумайте шкалы оценок заранее, а не решайте для каждого респондента после теста. Также стоит подумать, что делать с ошибками. Например, вы дали задание купить билеты в кино на проекте «Кино Mail.Ru». Один из респондентов случайно купил билет не на завтра, а на сегодня, и не заметил этого. Он уверен, что справился с заданием и имеет билет на руках. Но его ошибка настолько критична, что он не попадет в кино, поэтому я бы поставила «0%», несмотря на то что билет куплен.
Процент успешности - очень простая и наглядная метрика, и я рекомендую ее использовать, если у ваших заданий есть четкие цели. Взгляд на график успешности по заданиям позволяет быстро определить самые проблемные места интерфейса.
Время выполнения заданий. Эта метрика показательна только в сравнении. Как вы поймете, плохо или хорошо то, что пользователь выполняет задачу за 30 секунд? А вот то, что время сократилось по сравнению с предыдущей версией дизайна, уже хорошо. Или то, что регистрация на нашем проекте занимает меньше времени, чем у конкурентов. Есть интерфейсы, где сокращение времени на выполнение задач критично - например, рабочий интерфейс сотрудника колл-центра.
Однако не для всех задач эта метрика применима. Возьмем задачу подбора товара в интернет-магазине. Пользователи должны быстро находить фильтры и другие элементы интерфейса, связанные с поиском товаров, но сам процесс выбора будет занимать у них разное время, и это совершенно нормально. Женщины при выборе туфель бывают готовы отсмотреть 20 страниц выдачи. И это необязательно значит, что на первых страницах не было подходящих товаров или что они не видят фильтры. Часто им просто хочется увидеть все варианты.
Частотность проблем. Любой отчет о юзабилити-тестировании содержит список проблем, с которыми столкнулись респонденты. Количество респондентов, которые столкнулись с проблемой, - показатель ее частотности в рамках теста. Эту метрику можно применять только в том случае, если ваши пользователи выполняли абсолютно одинаковые задания.
Если же в тесте были вариации или задания были не четко сформулированы, а составлены на основании интервью, то посчитать частотность будет сложно. Нужно будет не только считать столкнувшихся, но и оценивать, сколько респондентов могли бы столкнуться с проблемой (выполняли схожую задачу, заходили в тот же раздел). Тем не менее эта характеристика позволяет команде понять, какие проблемы стоит исправлять в первую очередь.
Субъективная удовлетворенность. Это субъективная оценка пользователем удобства или комфорта работы с системой. Выявляется она при помощи опросников, которые респонденты заполняют в процессе или после тестирования. Есть стандартные опросники. Например, System Usability Scale, Post-Study Usability Questionnaire или Game Experience Questionnaire для игр. Или вы можете составить собственный опросник.
Это далеко не единственные возможные метрики. Например, список из 10 UX-метрик, которые выделяет Джеф Сауро. Для вашего продукта метрики могут быть другими: например, с какого уровня респонденты разбираются в правилах игры, сколько ошибок допускают при заполнении длинных форм. Помните, что решение использовать многие метрики накладывает на тестирование ряд ограничений. Респонденты должны действовать максимально естественно и в одинаковых условиях. Поэтому хорошо бы обеспечить:
- Единые точки старта. Одни и те же задания для разных респондентов должны начинаться с одной и той же точки интерфейса. Вы можете после каждого задания просить респондентов вернуться на главную страницу.
- Отсутствие вмешательств. Любое общение с модератором может повлиять на метрики эффективности, если модератор невольно подскажет что-то респонденту, и увеличивает время выполнения задания.
- Порядок заданий. Чтобы компенсировать эффект обучения в сравнительном тестировании, обязательно меняйте порядок знакомства со сравниваемыми продуктами для разных респондентов. Пусть половина начинает с вашего проекта, а половина - с конкурентного.
- Критерии успешности. Заранее продумайте, какое именно поведение вы считаете успешным для задания: например, допустимо ли, чтобы при подборе товара в интернет магазине респондент не пользовался фильтрами.
Трактовка метрик
Помните, что классическое юзабилити-тестирование - это качественное исследование и полученные вами метрики в первую очередь иллюстративны. Они дают общий взгляд на разные сценарии в продукте, позволяя увидеть болевые точки. Например, настройки аккаунта вызывают больше сложностей, чем регистрация в системе. Они могут показать динамику изменений, если вы измеряете их регулярно. То есть метрики позволяют понять, что в новом дизайне выполнять задачу стали быстрее. Именно эти отношения гораздо более показательны и надежны, чем найденные абсолютные значения метрик.
Джеф Сауро, эксперт по статистике в UX-исследованиях, советует не представлять метрики средними значениями, а всегда считать доверительные интервалы. Это гораздо правильнее, особенно если в результатах респондентов присутствует разброс. Для этого можно воспользоваться его бесплатными онлайн-калькуляторами: для успешности и для времени выполнения заданий. Не обойтись без статистической обработки и при сравнении результатов.
Когда нужны метрики
Далеко не каждый отчет о юзабилити-тестировании содержит метрики. Их сбор и анализ требует времени и накладывает ограничения на методы проведения теста. Вот в каких случаях они действительно нужны:
- Доказать. Часто есть необходимость доказать, что в продукт нужно внести изменения, - особенно в крупных компаниях. Для лиц, принимающих решения, цифры наглядны, понятны и привычны. Когда вы показываете, что 10 из 12 респондентов не смогли оплатить товар или что регистрация в системе занимает в среднем в два раза больше времени, чем у конкурентов, - это придает результатам исследования больший вес.
- Сравнить. Если вы сравниваете свой продукт с другими на рынке, вам также не обойтись без метрик. Иначе вы увидите достоинства и недостатки разных проектов, но не сможете оценить, какое место ваш продукт занимает среди них.
- Увидеть изменения. Метрики хороши для регулярных тестов одного и того же продукта после внесения изменений. Они позволяют увидеть прогресс после редизайна, обратить внимание на те места, которые остались без улучшений. Использовать эти показатели вы можете опять же как доказательную базу, которая покажет руководству вес вложений в редизайн. Или просто для понимания того, что вы достигли результатов и движетесь в нужном направлении.
- Иллюстрировать, сделать акцент. Цифры хорошо помогают иллюстрировать важные проблемы. Иногда мы считаем их для наиболее ярких и важных моментов теста, даже если не используем метрики во всех заданиях.
Тем не менее мы используем метрики далеко не в каждом тесте. Можно обойтись без них, если исследователь плотно работает с командой проекта, есть внутреннее доверие и команда достаточно зрелая, чтобы грамотно расставить приоритеты решения проблем.
Способ фиксации данных
Казалось бы, чем плохи блокнотик и ручка или просто открытый документ Word? В современном Agile-мире разработки UX-исследователи должны стараться как можно быстрее выдавать команде результаты своих наблюдений.
Чтобы оптимизировать время на анализ, хорошо заранее заготовить шаблон для ввода заметок в процессе теста. Мы пробовали делать это в специализированном программном обеспечении (например, Noldus Observer или Morae Manager), но на практике наиболее гибкими и универсальными оказались таблицы. Заранее разметьте в таблице вопросы, которые точно планируете задавать, места под ввод проблем, обнаруженных в заданиях, а также гипотезы (на каждом респонденте вы будете помечать, подтвердились она или нет). Наши таблички выглядят подобным образом:
Чем еще вы можете воспользоваться:
- . Кастомизируемый шаблон Excel для ввода наблюдений по каждому респонденту. Встроен таймер, который измеряет время выполнения заданий, автоматически генерируются графики времени и успешности.
- Rainbow Spreadsheet от Томера Шерона из Google. Наглядная таблица для совместной работы исследователя и команды. Ссылка ведет на статью с описанием метода, там же есть ссылка на Google-таблицу с шаблоном.
С опытом большинство записей можно делать прямо во время теста. Если не успели вовремя, то лучше записать все, что помните, сразу после теста. Если возвращаться к анализу через несколько дней - скорее всего, придется пересмотреть видео и потратить гораздо больше времени.
Подготовка к тестированию
Помимо метода, метрик и непосредственно протокола тестирования, необходимо определиться со следующими вещами:
Формат общения с модератором. Модератор может находиться в одной комнате с участником тестирования. В этом случае ему будет легко вовремя задавать вопросы. Однако присутствие модератора может влиять на респондента: он начнет задавать вопросы модератору, провоцируя того явно или неявно ему подсказать.
Мы стараемся хотя бы на часть теста оставлять респондента наедине с продуктом. Так его поведение становится более раскованным и естественным. А чтобы не бегать туда-сюда, если что-то пойдет не так, можно оставить включенным любой мессенджер с аудиосвязью, чтобы модератор мог связаться с респондентом из наблюдательной комнаты.
Способ постановки заданий. Задания может озвучивать модератор. Но в этом случае, несмотря на единый протокол тестирования, текст задания может каждый раз произноситься немного по-разному. Особенно это актуально, если тест ведет несколько модераторов. Иногда даже небольшие различия в формулировках могут поставить респондентов в разные начальные условия.
Чтобы этого избежать, можно либо «надрессировать» модераторов всегда читать тексты задания, либо выдавать респондентам задания на листочках или на экране. Различие формулировок перестает быть проблемой, если использовать гибкий сценарий, когда задания формулируются в процессе теста, на основании интервью с модератором.
Можно использовать средства продукта для постановки заданий. Например, при тестировании ICQ задания респонденты получали через окно чата с модератором, а при тестировании «Почты Mail.Ru» они приходили в письмах. Такой способ постановки заданий был максимально естественным для этих проектов, а еще мы многократно обкатывали базовые сценарии переписки.
Создание естественного контекста. Даже если мы говорим о лабораторных исследованиях, подумайте, как приблизить использование продукта на тесте к реальным условиям. Например, если вы тестируете мобильные устройства, то как респонденты будут их держать? Для хорошего изображения на видеозаписи лучше, когда телефон или планшет фиксированы на стенде или лежат на столе. Однако это не дает понять, все ли зоны доступны и удобны для нажатия, ведь телефоны часто держат одной рукой, а с планшетами лежат на диване.
Стоит подумать об обстановке, в которой будет использоваться продукт: отвлекает ли что-то человека, шумно ли, хороший ли интернет. Все это можно имитировать в лаборатории.
План теста для заказчика. Это также важный этап подготовки, так как он вовлекает проектную команду. Вы можете не посвящать заказчика во все методологические особенности теста (как будете общаться с респондентом, фиксировать данные и прочее). Но обязательно покажите ему, какие будут задания и что вы на них собираетесь проверять. Возможно, вы не учли какие-то особенности проекта, а может быть, у команды проекта появятся дополнительные идеи и гипотезы. У нас обычно получается подобная табличка:
План отчета. Естественно, отчет пишется по результатам исследования. Но есть хорошая практика - составлять план отчета еще до проведения тестов, основываясь на целях и задачах исследования. С таким планом перед глазами вы сможете проверить свой сценарий на полноту, а также подготовить наиболее удобные формы, чтобы зафиксировать данные для последующего анализа. Возможно, вы решите, что отчёт не нужен и достаточно общего файла с наблюдениями для вас и команды. А если вы мотивируете команду заполнять его вместе с вами, будет совсем здорово.
Конечно, вы можете просто «дать попользоваться продуктом» своему другу и наблюдать за тем, какие сложности у него возникнут. Но грамотно составленный сценарий позволит не упустить важные проблемы и не натолкнуть случайно респондента на нужные вам ответы. Ведь юзабилити-тестирование - это упрощенный эксперимент, а в любом эксперименте важна предварительная подготовка.
Протокол любого юзабилити-тестирования состоит из следующих частей:
- Инструктаж или брифинг (приветствие, описание мероприятия, подписание документов).
- Вводное интервью (проверка скрининга, небольшое интервью об использовании продукта, контексте и сценариях).
- Работа с продуктом (задания тестирования).
- Сбор итоговых впечатлений от продукта на основании опыта тестирования.
Инструктаж или брифинг
Независимо от предмета тестирования любое исследование начинается одинаково. Что нужно сделать:
Создать атмосферу. Познакомьтесь с человеком, предложите ему чай, кофе или воду, покажите, где туалет. Постарайтесь немного расслабить респондента, ведь он может нервничать перед мероприятием. Узнайте, легко ли было вас найти, спросите, как настроение.
Описать процесс. Расскажите, что за мероприятие ждет респондента, сколько времени оно займет, из каких частей оно состоит, что вы будете делать. Обязательно обратите внимание респондента на то, что его вклад поможет улучшить продукт и что вы не тестируете способности человека. Если вы ведете видеозапись, предупредите об этом респондента и скажите ему, что данные не появятся в сети. Я говорю примерно следующее:
Мы находимся в офисе компании Mail.Ru Group. Сегодня мы поговорим о проекте ХХХ. Это займет около часа. Сначала мы немного побеседуем, потом я попрошу вас что-то попробовать сделать в самом проекте, а после мы обсудим ваши впечатления. Мы будем вести видеозапись того, что происходит в комнате и на экране компьютера. Запись нужна исключительно для анализа, в интернете вы себя не увидите.
Мы проводим исследование, чтобы сделать проект ХХХ лучше, понять, что в нем нужно исправить и в какую сторону ему развиваться. Поэтому очень прошу вас открыто высказывать любые комментарии: и положительные, и отрицательные. Не бойтесь нас обидеть. Если при изучении проекта у вас что-то не получится, относитесь к этому спокойно. Значит, мы с вами нашли проблему, которую команде проекта нужно исправить. Главное - помните, что мы не тестируем вас, это вы тестируете продукт. Если вы готовы, предлагаю начинать.
Подписать документы. Как правило, это согласие на обработку персональных данных, а иногда еще соглашение о неразглашении информации о тестировании. Для тестов с несовершеннолетними необходимо согласие родителей на участие их ребенка в исследовании. Обычно мы высылаем его родителям заранее и просим принести с собой. Обязательно объясните, зачем вы просите подписать документы, и дайте время изучить их. В России люди с опаской относятся к любым бумагам, которые требуется подписать.
Настроить оборудование. Если вы используете айтрекинг, биометрическое оборудование или просто ведете видеозапись - самое время все это включить. Предупредите респондента, когда начнете запись.
Вводное интервью
Оно решает следующие задачи:
Проверить рекрутинг. На всякий случай всегда начинайте с этого - даже если вы доверяете агентству или человеку, который нашел респондента. Не раз уже на тесте мы выясняли, что респондент неправильно понял вопросы и на самом деле пользуется продуктом не совсем так, как нам нужно. Старайтесь отойти от формальности и не задавать вопросы из скринингового опросника: человек может уже знать, что отвечать на них.
Сценарии и контекст использования продукта. Даже если у вас мало времени на тест, не пропускайте этот пункт. Хотя бы в целом узнайте у респондента, какие задачи он решает при помощи продукта, пользуется ли аналогичными проектами, в каких условиях взаимодействует с ними и с каких устройств. Ответы помогут вам лучше понимать причины поведения респондента, а если вы применяете гибкий сценарий - то и формулировать подходящие задания. Если хватает времени, попросите респондента показать, что и как он обычно делает. Это бывает источником дальнейших вопросов и инсайтов.
Ожидания и отношения. Начало тестирования - хороший момент, чтобы узнать, что респондент знает о продукте, как относится к нему и чего от него ожидает. После теста вы сможете сравнить ожидания с итоговым впечатлением.
Для большинства тестов подойдет такая структура вводного интервью. Если вы тестируете новый продукт, то, возможно, стоит пропустить вводные вопросы. Если вы начнете слишком подробно обсуждать какую-то тему, это может создать у пользователя определенные ожидания от продукта. Поэтому оставьте только пару общих вопросов, чтобы наладить контакт с респондентом, и сразу же переходите к заданиям, а обсуждать сценарии, отношения и контекст лучше после того, как пользователь первично изучит продукт.
Работа с продуктом, составление заданий
Какие бывают задания
Давайте представим, что вы хотите протестировать интернет-магазин. У вас есть важные сценарии (поиск и выбор товара, процесс оформления заказа), известные проблемы (частые ошибки в форме оплаты) и даже гипотеза, что дизайнер что-то намудрил с фильтром по цене. Как же сформулировать задания?
Сфокусированные задания. Кажется очевидным сделать примерно такое задание: «Выберите посудомоечную машину шириной 45 сантиметров с функцией "луч на полу" стоимостью не более 30 тысяч рублей». Это мотивирует респондента пользоваться фильтрами и сравнивать товары между собой. Вы сможете проверить фильтр по цене на всех респондентах и посмотреть на ключевой сценарий подбора товара. Подобные задания вполне имеют право на жизнь и хороши для проверки конкретных гипотез (как с фильтром по цене).
Однако, если весь тест будет состоять из них, то вы рискуете следующим:
- Точечная проверка интерфейса. Вы найдете только те проблемы, которые связаны с деталями задания (фильтр по цене и ширине). Вы не увидите прочих проблем - например, сортировки товаров или других фильтров, - если не укажете и на них. А сделать задания для всех элементов сайта вы вряд ли сможете.
- Отсутствие вовлечения. Подобные задания пользователи часто выполняют механически. Увидев первый товар, подходящий под критерии, они останавливаются. Возможно, в жизни респондент никогда не выбирал посудомойки и ему все равно, что такое «луч на полу». Чем больше задание походит на ситуацию из реальной жизни и чем больше в нём контекста, понятного пользователю, тем выше шансы вовлечь респондента, который представит, что на самом деле выбирает товар. А вовлеченный пользователь лучше «проживает» интерфейс, оставляет больше комментариев, повышаются его шансы найти проблемы и дать полезные знания о поведении и особенностях аудитории.
- Суженный спектр инсайтов. В реальной жизни пользователь, возможно, подбирал бы товар совсем не так. Например, вообще не пользовался бы фильтрами (а тут вы на них указали). Или искал бы товар по критериям, которых нет на сайте. Давая жесткие, сфокусированные задания, вы не узнаете о реальном контексте использования продукта, не найдете сценариев, которые команда проекта, возможно, не предусмотрела, не соберете данные о потребностях в контенте и функциональности.
Задания с контекстом. Один из способов лучше вовлечь пользователей - добавить в сухое задание реальную историю и контекст. Например, вместо «Найдите на сайте рецепт пирога со сливами» предложите следующее: «Через час к вам придут гости. Найдите, что можно испечь за это время. У вас в холодильнике есть все для бисквита, а также немножко слив. Но, к сожалению, нет сливочного масла».
Подобный подход можно использовать и с интернет-магазином. Например: «Представьте, что вы выбираете подарок сестре. У нее недавно сломался фен, и она была бы рада получить новый. Вам нужно уложиться в 7 тысяч рублей». Важно, чтобы респондент действительно выбрал реального человека, которому будет «покупать» подарок (если нет сестры, предложите другого родственника или подругу). Ключевой фактор для подобных заданий - реальность и понятность контекста. Легко представить, что ты выбираешь подарок родным, куда труднее - что ты «бухгалтер, составляющий годовой отчет».
Яркий пример такого подхода - «метод Болливуда», который придумала индийский UX-эксперт Апала Лахири Чаван. Она утверждает, что индусам, как и многим азиатам, сложно открыто высказывать мнение об интерфейсе. Зато, представляя себя героями вымышленных драматических ситуаций (как в любимых ими фильмах), они раскрываются и начинают живо участвовать в тестировании. Поэтому задания для индусов должны выглядеть примерно так:
Представьте, что ваша любимая юная племянница собирается замуж. И тут вы узнаете, что ее будущий муж - мошенник, да еще и женатый. Вам нужно срочно купить два билета на рейс до Бангалора для себя и для жены обманщика, чтобы расстроить свадьбу и спасти семью от позора. Торопитесь!
Задания с опорой на опыт респондентов. Напомним: для успешного тестирования респонденты должны соответствовать аудитории проекта. Поэтому для проверки интернет-магазина бытовой техники мы рекрутируем тех, кто недавно выбирал технику или выбирает ее сейчас. Именно этим мы будем пользоваться, составляя задания с опорой на опыт респондентов. Есть два варианта использования такого подхода:
- Параметры респондентов. В этом случае вы адаптируете фиксированные задания под респондентов. Например, в случае с магазином бытовой техники и задачей на работу с фильтрами уточняете у человека, что именно он недавно приобрел. Узнаете критерии (цена, функции) и предлагаете повторить «покупку» на вашем сайте.
- Сценарии респондентов. Задания полностью формируются с опорой на опыт участников. Чтобы понять, какие сценарии проверить, модератор выясняет, как именно человек решал задачу в жизни, и предлагает сделать это на сайте. Например, покупатель перед выбором долго сравнивал между собой несколько моделей. Даже если на сайте нет подходящей функции, предложите респонденту сравнить товары, чтобы понять, на какие параметры он станет опираться. Возможно, вы получите идеи, как должна выглядеть функция сравнения, а также адаптируете под этот сценарий страницу товара.
Подобные задания дают много реальных примеров выполнения базовых операций в продукте. Это часто порождает гораздо больший спектр проблем и находок. Кроме того, позволяет проверить продукт на новых сценариях, которые вы не считали основными или даже не продумывали.
Когда мы тестировали проект «Недвижимость Mail.Ru», много открытий помогли сделать именно задания с опорой на опыт респондентов. Мы увидели, что люди при поиске квартиры в Подмосковье указывают в геофильтре конечные станции метро, имея в виду, что это станции, до которых можно доехать из области. Мы же рассчитывали, что фильтр по метро ищет квартиру недалеко от станции. Также мы узнали, чем отличаются сценарии поиска новостроек от вторички, что помогло вынести поиск новостроек в другой раздел на сайте - со своими фильтрами и своей концепцией описания квартир. Советую также прочитать отличную Джареда Спула о пользе подобных заданий.
Задания без заданий. Иногда лучше вообще не предлагать пользователям задания на работу с проектом, а посмотреть, с чего они сами начнут знакомство с продуктом. Дайте респонденту вводную: «Представьте, что вы решили попробовать этот продукт. Я оставлю вас на несколько минут. Делайте то, что вы стали бы делать в реальной жизни. Я не даю вам никаких заданий».
Важно, чтобы модератор при этом выходил из комнаты. В противном случае у пользователя появляется соблазн сразу же что-то спросить, уточнить: «А надо ли регистрироваться? А как вот это сделать?» и так далее.
Данный тип заданий полезен для полностью новых продуктов. Мы часто применяем его для мобильных приложений и игр. Так мы узнаем, читают ли пользователи обучающие материалы, какие детали сразу привлекают внимание, что люди понимают в концепции продукта, как потом описывают его возможности. Уже после свободного задания идут запланированные конкретные сценарии.
Еще одна область применения свободных заданий - контентные проекты. Если вы хотите понять, как читают ваши статьи (где надолго задерживаются, что пропускают, на какие элементы на странице обращают внимание), то просто оставьте респондента на несколько минут наедине с проектом. Только без модератора, смотрящего через плечо, пользователь расслабится и будет читать текст так же, как обычно. Так мы тестируем проекты «Новости Mail.Ru», «Леди Mail.Ru»и другие. Этот подход позволил выделить разные модели поведения на сайте, разные паттерны чтения статей и понять, какие типы материалов стоит оформлять по-другому.
Составляем хорошие задания
Первое задание - простое. Начинайте тестирование с ознакомительных и несложных заданий. Респондент должен освоиться с форматом тестирования, особенно если вы используете метод «мысли вслух»: ему нужно привыкнуть к необходимости озвучивать свои мысли и чувства. Не стоит сразу вываливать на него всю боль и страдания интерфейса.
Не подсказывайте. Сформулируйте задания так, чтобы не подсказывать респонденту правильных действий. Если вы хотите протестировать возможность добавлять товары в избранное в интернет-магазине - обойдитесь без задания «Давайте добавим вот этот телевизор в избранное», особенно если кнопка так и называется. Респондент, прочитав задание, будет просто находить на экране кнопку с нужной подписью - возможно, даже не понимая, что именно он делает.
Лучше объяснить смысл задания, не прибегая к терминам в интерфейсе. Например: «На сайте есть возможность сохранить понравившиеся товары и потом выбрать, что из них заказать. Давайте попробуем сделать это с таким-то телевизором».
Следите за терминологией. Не используйте непонятные слова и обозначения. Это кажется очевидным, но мы, привыкнув к каким-то терминам, часто забываем, что их мало кто знает за пределами ИТ-тусовки. Например, при тестировании новой функциональности тредов (цепочек писем) в «Почте Mail.Ru» нам пришлось сложно. Ведь у пользователей, незнакомых с этой функцией, просто нет в голове термина, который бы обозначал треды.
В итоге мы никак их не называли. Мы просто показывали респондентам ящик с подключенными цепочками и обсуждали эту новую возможность, причем давали пользователям самим подобрать слово для обозначения тредов. Это помогло нам позже использовать наиболее понятные тексты в обучающих промоматериалах.
Следите не только за заданиями, но и за вопросами модератора, особенно за теми, которые приходят от команды во время тестирования. Например, при обсуждении функций не стоит использовать слово «тулбар»: оно знакомо не всем. Ещё несколько лет назад далеко не все пользователи знали даже слово «браузер». То, как именно лучше сформулировать задания, зависит от аудитории тестирования. Не стоит кидаться и в другую крайность, объясняя все термины подряд. Например, опытным игрокам не надо растолковывать, что такое «баф», «фраг», «респаун» и так далее.
Меньше тестового. Часто велик соблазн сделать респонденту тестовый аккаунт в системе и проводить тестирование на нем. Ведь можно заранее все обкатать в этом аккаунте, избежать накладок и не тратить время на регистрацию или авторизацию респондента. Часто еще и технически гораздо легче включить новый дизайн на тестовых, а не на реальных данных.
Однако при таком подходе вы рискуете получить гораздо меньше полезных результатов, ведь у тестовых действий нет реальных последствий. Ситуация становится совсем искусственной, пользователям сложно проецировать ее на реальный опыт.
Например, при работе в собственном аккаунте в соцсети респонденты, как и в реальной жизни, будут аккуратно делать все, что могут увидеть их друзья (публиковать ссылки, отправлять сообщения). При настройках собственного ящика в почте они постараются не удалить важные письма. При тестировании интернет-магазинов иногда применяют подход, когда вознаграждение нужно потратить прямо на тесте. В таком случае респондент не ткнет в первый подходящий по заданию товар, а подберет то, что ему на самом деле нужно.
Имея одни лишь тестовые данные, вы найдете проблемы, связанные только с ними, а не проверите функциональность на разных вариациях. Например, когда мы тестировали социальную панель браузера «Амиго», один из респондентов, подключивший в панель свой аккаунт «ВКонтакте», сразу отметил, что так читать ему неудобно. Почти вся лента состояла из подписок на группы с эротическими фотографиями. А в узкой панели на картинках было просто ничего не разглядеть.
Еще одна проблема тестовых данных - сложно разобраться в системе, так как все вокруг непривычное. Например, пользователь соцсети привык узнавать свою страницу по собственной фотографии. Даже тестируя прототипы, мы стараемся максимально их персонализировать. Например, при тестировании кликабельных прототипов в «Одноклассниках» мы всегда адаптируем их для каждого пользователя, вставляя на страницу его имя и фотографию, а иногда и последние новости.
Не ограничивайтесь интерфейсом. Не забывайте о том, что взаимодействие с продуктом часто не ограничивается одним лишь интерфейсом. Если есть возможность, тестируйте сопутствующие продукты или сервисы и связи между ними. При тестировании игр мы стараемся проверить не только игру, но и ее сайт и связанные с ним загрузку, регистрацию в игре, поиск информации на форуме. А при тестировании одного интернет-магазина я также проверяла звонок оператора после оформления заказа, что дало рекомендации для колл-центра.
Думайте о тайминге. Для хорошего сценария важно расставлять приоритеты задач. Скорее всего, если система большая и целей у теста много, вам захочется сделать очень много заданий. Однако уставший респондент уже не будет полезен. Хороший тест длится не больше полутора часов, два - это максимум. Исключение - разве что игры. И помните, что ваши цели - не только задания, но и интервью, опросники, настройка оборудования и подписание документов. Все это обычно занимает не менее получаса.
Если заданий слишком много, а отказываться от каких-то не хочется, можете наименее приоритетные пустить в ротацию, то есть показывать только части респондентов. Или сделать часть теста обязательной для всех, а остальное смотреть только с теми, с кем хватит времени. Но это, скорее всего, будут наиболее успешные респонденты.
Оценивайте полезность задания. Подумайте, действительно ли оно соответствует вашим гипотезам. Например, вы хотите проверить функцию подписки на новости на сайте. Задание «Подпишитесь на новостную рассылку» позволит проверить только то, смогут ли найти рассылку те, кто будет ее искать. Однако люди редко приходят на сайт, чтобы подписаться на новости. Задание не относится к реальной жизни. Вам же нужно понять, замечают ли возможность подписки те, кто выполняет совсем другие задачи.
Проверять это можно разными способами - в зависимости от реализации функции. Если человек занимался заданиями, в которых ему на глаза могла попасть возможность подписки, спросите его, есть ли она на сайте. Только обязательно уточните, где он видел эту возможность или как она реализована, чтобы удостовериться, что респондент не просто с вами соглашается.
Если предложение подписки встроено в процесс регистрации или оформления заказа -посмотрите, воспользуется ли им респондент, а после задания обсудите это. Очень мало шансов, что в лабораторных условиях люди реально подпишутся на рассылки, но можно проверить, обратил ли человек внимание на такую возможность, чего он ожидает от рассылки и так далее.
Сбор итоговых впечатлений
Цель заключительной фазы тестирования - собрать впечатления от работы с продуктом, понять, что понравилось пользователю, а что его расстроило, оценить субъективную удовлетворенность. Как правило, в этой части теста используется сочетание интервью с модератором и заполнения формальных опросников.
Интервью с модератором
В итоговом интервью мы всегда задаем респондентам примерно одни и те же вопросы: «Какие впечатления остались?», «Что понравилось, а что нет?», «Было ли то, что показалось сложным или неудобным?», «Чего не хватало?», «Что хотелось бы изменить в продукте?». Самое время уточнить непонятные моменты поведения респондента, если вы не сделали этого в процессе теста. Если вы до теста узнавали у пользователей отношение к бренду или продукту и ожидания от него - выясните, изменилось ли что-нибудь. При интервью обращайте внимание на следующее:
Социальная желательность. Обращайтесь с результатами интервью очень аккуратно. Если во время теста вы часто слышите импульсивные комментарии под влиянием проблем, то в финальном интервью вовсю расцветает социальная желательность.
Одним кажется, что, говоря о проблемах в продукте, они признаются в собственной некомпетентности. Другие просто не хотят расстраивать приятного в общении модератора. Очень часто респонденты (особенно женщины), которые промучились весь тест, говорят, что все, в принципе, нормально. Отрицательные отзывы также могут быть продиктованы социальной желательностью: если респондент уверен, что цель теста - найти недостатки, он старательно пытается их отыскать.
Цитаты и приоритеты. Хотя все слова участников теста в финальном интервью часто нужно делить на два, а то и на десять, это не значит, что они бесполезны. По тому, как респонденты подытоживают впечатления, вы можете сделать вывод о приоритетах. Продукт - «полный отстой»? Что именно повлияло на это? Какую из многих проблем респондент запомнил больше всего и считает самой раздражающей?
Однако делайте скидку на то, что лучше всего запоминается последнее задание. Также очень полезно отслеживать, какими прилагательными респонденты описывают продукт, с чем сравнивают свой опыт.
Не забываем о хорошем. Очень часто отчет о юзабилити-тестировании - это длинный перечень найденных во время теста проблем. В общем-то, поиск проблем - одна из основных задач исследования. Но не забывайте и о положительных сторонах продукта.
Во-первых, отчет без положительных результатов просто демотивирует команду. А во-вторых, полезно знать, что пользователям в продукте нравится: вдруг при следующем редизайне решат убрать функцию, которая так всем приглянулась. Поэтому обязательно спрашивайте у респондентов о положительных сторонах продукта, даже если они ругали интерфейс в течение всего тестирования.
Отношение к «хотелкам». Скорее всего, респонденты, помимо своих впечатлений, будут высказывать пожелания и идеи. Ваша задача - понять, какая проблема стоит за предложениями. Потому что решения, которые предложат пользователи, с высокой вероятностью вам не подойдут. Ведь участники тестирования не дизайнеры, они не в курсе особенностей и ограничений разработки. Тем не менее за любым подобным запросом стоит потребность, которую вы должны зафиксировать. Если респондент говорит, что ему вот здесь непременно нужна большая зеленая кнопка, обязательно спросите: а зачем?
Мера удовлетворенности
Часто по словам респондента в финальном интервью сложно понять, понравился ему продукт или нет, а уж тем более трудно сравнить отношение нескольких респондентов, которые и плюсы отмечали, и недостатки находили. Тут на помощь исследователю приходят опросники. Во-первых, при заполнении опросника (особенно до разговора с модератором) чуть меньше влияние пресловутой социальной желательности, хотя полностью вы от него не избавитесь. Во-вторых, опросник дает вам четкие параметры для сравнения сценариев, продуктов или стадий проекта.
Составление хорошего опросника - отдельная и очень большая тема. Тут важны и формулировки, и шкалы, и многое другое. Хорошим подспорьем могут стать готовые и проверенные опросники: они уже отточены и многократно протестированы. Проблема только в том, что почти у всех этих анкет нет официальных переводов на русский. Естественно, вы можете перевести их самостоятельно, но с методологической точки зрения переводы нужно протестировать, чтобы проверить корректность формулировок. Тем не менее анкеты могут стать ориентиром при составлении собственных опросников.
Есть опросники, которые даются после каждого задания, чтобы оценить удовлетворенность от конкретных сценариев. Например:
- After Scenario Questionnaire (ASQ) . Три вопроса о сложности, продуктивности и подсказках в системе.
- Single Ease Question (SEQ) . Один вопрос о сложности сценария.
А есть анкеты, которые применяются уже в заключительной фазе тестирования. Вот несколько примеров, которые мы используем при необходимости:
- System Usability Scale и Post-Study System Usability Questionnaire . Два классических и популярных опросника, созданных более 20 лет назад. Оба состоят из утверждений. Респонденты должны указать степень согласия с ними. Все эти утверждения с разных сторон характеризуют юзабилити продукта. Например: «Я легко мог найти нужную информацию», «Разные возможности системы легко доступны» и так далее.
- . Опросник, который часто помогает нам на тестах. Пользователю предоставляется набор прилагательных, из которых он выбирает те, что могут характеризовать продукт. В итоге вы получаете облако слов - характеристик вашего проекта. Часто эта методика приносит очень интересные результаты.
- Game Experience Questionnaire . К играм нельзя применять классические юзабилити-опросники: вовлеченность в игровой процесс гораздо важнее, чем понятность интерфейсов. Поэтому для игр нужно всегда составлять особые опросники или пользоваться Game Experience Questionnaire. Опросник содержит несколько модулей: базовый модуль, внутриигровой блок, постопросник и опросник социальных возможностей игры. Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.
Что около половины сайтов теряет клиентов из-за неудобного дизайна и других недочетов в юзабилити. Только представьте: неудачная форма заказа или некликабельная картинка - и потенциальный покупатель понес деньги конкурентам. Чтобы понять, нравится ли вашим посетителям сайт и удобно ли им делать на нем покупки, проведите юзабилити-тестирование.
Что нужно тестировать?
Если сайт уже работает, какие его элементы нужно протестировать станет ясно после аналитики. Реальный пример теста юзабилити компании Imaginary Landscape: из Google-Аналитики видно, что пользователи заходят на страницу с формой обратной связи, но заявку на звонок не отправляют. После юзабилити-тестирования стало понятно, что люди не хотят заполнять такое количество строк. Форму поменяли, количество строк сократили c 11 до 4, после чего конверсия выросла на 140%. Профит.
было стало
Еще тестируют картинки. Они должны привлекать внимание пользователей, вызывать правильные эмоции и побуждать к правильным действиям. Если по картам кликов видно, что на картинку нажимают, но она никуда не ведет, логично сделать ее ссылкой на что-нибудь полезное и актуальное. Либо наоборот: нажав на изображение, пользователи найдут интересную информацию, только они об этом не догадываются. Проблему решить легко. Достаточно сделать так, чтобы картинка реагировала на наведение курсора - немного увеличивалась или подсвечивалась, как бы приглашая на себя нажать. Но сначала нужно узнать о существовании проблемы, а для этого - провести юзабилити-тестирование.
Кроме прочего, тестируют:
- структуру сайта, чтобы сделать ее простой и понятной для пользователя;
- кнопки на кликабельность, особенно после того, как в моду вошел так называемый плоский дизайн ;
- меню, чтобы определить, почему пользователи не заходят в некоторые разделы.
В общем, любые элементы, с которыми посетитель взаимодействует на сайте. Или не взаимодействует, но по нашему плану должен.
В идеале тестирование проводят специалисты: собирают данные, сегментируют ЦА, формируют фокус-группы, составляют анкеты, а после самого исследования анализируют результаты. Это долго и дорого, хотя и стоит того. Но получить общее представление о взаимодействии пользователей с вашим сайтом можно и самостоятельно, причем бесплатно. Для этого есть как минимум 5 способов.
1. Инструменты Яндекс Метрики
В рунете из бесплатных инструментов юзабилити-тестирования пока не придумали ничего удобнее и функциональнее счетчиков Яндекс Метрики. Чего стоит один "Вебвизор".
С его помощью можно воспроизводить перемещения курсора пользователя, клики, заполнение формы и выделение текста. Вы как будто смотрите видеозапись визита посетителя своего сайта: куда он нажал, что ввел в строку поиска или, например, на каком шаге оформления заказа остановился.
Добавьте HTML-код счетчика на страницы своего сайта
Вот так выглядит отчет "Вебвизора". А настоящая магия - просмотр действий пользователя - начнется при нажатии на значок воспроизведения.
"Вебвизор" не единственный полезный инструмент Яндекса, который поможет отследить реакцию пользователей на ваш сайт.
Тепловая карта кликов наглядно покажет самые кликабельные места на странице. Например, по карте кликов Яндекса видим, что кнопку "Получить счетчик" нажимают, а вот новости (колонка справа) особой популярностью не пользуются. Чем горячее цвет в точке, тем чаще на нее кликают пользователи.
Карта скроллинга даст понимание, как посетители прокручивают страницу, где задерживаются дольше всего, следовательно, какая часть им интересна. Аналитика форм поможет разобраться, как пользователь взаимодействует с формами на сайте, какие поля заполняют в заявке, что пишет в строке поиска и т.д. Все инструменты бесплатные, отлично работают и при грамотном подходе помогут эффективно проанализировать юзабилити вашего сайта.
2. UsabilityHub
Онлайн-сервис предлагает 5 простых тестов:
- Five Second Test - тест пяти секунд. Принцип таков: вы загружаете скриншот тестируемой страницы на сайт, участники теста смотрят на нее в течение 5 секунд, после чего дают свою оценку. Можно задавать разные вопросы, например, какой элемент больше всего привлек внимание, что запомнилось, о чем сайт и тому подобное. По завершении вы получите ответы участников теста в полном объеме + автоматически сгенерированное облако часто повторяющихся слов.
1.Загружаем скриншот страницы 2. Задаем участникам вопросы
3. Получаем отчет с ответами 4. Для наглядности изучаем облако
- Click Test - тест кликов. Действия те же, только вместо ответов получаем тепловую карту кликов. По ней мы увидим, что пользователи, к примеру, не жмут на стратегически важную (для нас) кнопку, зато активно кликают картинку. Дополнительно сервис предоставит отчет о количестве кликов и среднем времени щелчка.
- Question Test - тест вопросов. Вы спрашиваете о своем сайте - реальные люди отвечают.
- Navigation Test - анализ навигации. Позволяет понять, насколько удобно пользователям "лазить" по вашему сайту, понятна ли его архитектура и навигация.
- Preference Test - предпочтение. Поможет провести А/В тестирование дизайна сайта, приложения, листовки. Загружаете два варианта дизайна - пользователи выбирают, какой им больше нравится. Все просто и оперативно.
UsabilityHub - англоязычный сервис, но среди предлагаемых языков тестирования есть русский. В платной версии вы выбираете количество участников и вскоре получаете результаты. В бесплатном варианте придется самому поучаствовать в тестированиях, поотвечать на вопросы и пооценивать дизайны. Наберете необходимое количество баллов за участие - получите возможность провести свой тест.
3. Usabilla
Предлагает 3 продукта: тестирование веб-сайта, мобильного приложения и электронного письма. Под тестированием подразумевается хорошая обратная связь от людей в режиме реального времени: участники ставят свои оценки, пишут комментарии, указывают на ошибки, делают скриншоты для большей наглядности. Все данные сохраняются в удобную статистику.
Среди языков тестирования есть русский, но сама программа на английском. В бесплатной демо-версии можно протестировать 2 страницы с участием 10 человек.
4. Optimal Workshop
На сервисе доступны такие инструменты:
- Treejack - тестирование "дерева" сайта. Помогает понять, как пользователи ориентируются на вашем сайте, выполняют ли те действия, которые вы от них ждете, или теряются в его дебрях. Для тестирования нужно расписать информационную архитектуру своего сайта в форму Treejack. Звучит страшно, но каждая строка формы подписана, если знаете английский - легко справитесь. Также нужно поставить задачи участникам тестирования, к примеру, найти мобильный телефон на сайте. На выходе получите исчерпывающую статистику в виде таблиц и диаграмм. Бесплатная демо-версия позволяет опросить 10 человек.
- OptimalSort - тестирование по методу сортировки карточек. Помогает выяснить, как пользователь думает, какие принимает решения и как ему проще достичь конечной цели на вашем сайте. Как это работает: все элементы контента сайта "выписывается" в отдельные карточки, а участникам предлагается отсортировать их так, как им было бы понятно и удобно. В результате вы получаете отчеты в виде таблиц, матриц, дендрограмм и понимание ментальной модели ваших пользователей. В бесплатной версии можно протестировать 30 карточек, опросив 10 человек.
- Chalkmark - помогает узнать первое впечатление о дизайне, показывает тепловую карту кликов и анализ первого щелчка. Для тестирования загрузите скриншот страницы, поставьте участникам задачи и ждите результаты в виде карты кликов, цветовой сетки и схемы подсчета количества щелчков.
Результаты тестирования макета сайта с помощью Chalkmark
В платной версии можно проводить онлайн-опросы с быстрой обратной связью.
5. Feng-GUI
В отличие от предыдущей тройки инструментов, этот не дает обратную связь от живых людей. Приложение на основе своих алгоритмов само генерирует карту внимания пользователя. То есть показывает, куда он посмотрит сразу после загрузки страницы и в какой последовательности (по мнению программы) его взгляд будет перемещаться с одного элемента на другой. Для тестирования вводим url нужной страницы сайта, жмем Analyze, через несколько секунд получаем заветную карту взгляда пользователя.
Каждый из перечисленных инструментов по-своему хорош, но в бесплатных версиях в основном используется ограниченный функционал, к тому же львиная доля сервисов на английском.
Не хотите разбираться в интерфейсах и статистиках англоязычных ресурсов? Идите в народ. К примеру, для оценки дизайна страницы разместите скриншот на revision.ru или подобных площадках, поинтересуйтесь мнением "местных" - web-дизайнеров, разработчиков и других специалистов. Проведите опросы в соцсетях, например, в тематических сообществах, или соберите фокус-группу среди своих знакомых. Для более или менее объективного анализа юзабилити достаточно опросить 5 респондентов (по некоторым данным 8) из своей целевой аудитории.
Тестируйте юзабилити своего сайта. Используйте бесплатные программы, опрашивайте знакомых, нанимайте профи - все методы имеют место. Иногда достаточно всего лишь переместить кнопку в другое место, поменять некоторые элементы дизайна или форму заявки, и сайт начнет приносить ощутимо больше пользы. Просто благодаря тому, что стал более удобным и понятным для посетителей.
