Юзабилити-тестирование. Гид по UX исследованиям для начинающих

Дизайн продукта, сайта или приложения — весьма длительный процесс, требующий терпения, проницательности и наличия ряда инструментов. Чтобы понять, что в действительности работает, а что нет, важно знать мнение пользователей. Здесь-то и приходит на помощь пользовательское тестирование (user testing).

Объединив усилия, UXPin, UserTesting и Optimal Workshop решили описать UX-процесс, которому они следовали для гипотетического Yelp:

Весь процесс скорее напоминал дизайн-спринт, состоящий из 1-3 недельных проектов, сфокусированных на решении конкретных задач.

Краткий обзор процесса UX-дизайна

1. Определение продукта

На начальном этапе специалисты определили ценностное предложение (value proposition), незаслуженное преимущество (unfair advantage) и общую бизнес-модель. Поскольку Yelp уже добился значительного успеха в привлечении посетителей, они решили, что было бы интересно понять, как можно повысить частоту использования (frequency of use). Далее был разработан общий план тестирования.

2. Тестирование и анализ

На этапе исследования команда рассмотрела в деталях план тестирования и перешла к немодерируемым сессиям. Была определена демография пользователей и детализированы конкретные задачи. В ходе работы использовались различные методы тестирования, начиная от анализа записей взаимодействий пользователей с сайтом, удаленной карточной сортировки (card sorting) и тестирования первого клика (first-click testing).

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

Во время всех тестирований разработчики придерживались следующих принципов:

• Переработка текста. В целях извлечения максимальной пользы специалисты несколько раз корректировали инструкции, чтобы язык был как можно более лаконичным и побуждал к конкретным действиям. Это непременное условие для удаленных немодерируемых тестирований, поскольку письменные инструкции являются единственными директивами для участников.
• Проведение (pilot test). Как только инструкции были готовы, было проведено немодерируемое удаленное тестирование с одним пользователем из группы тестирования. Он также оставил отзыв касательно самих инструкций, чтобы команда могла исправить мелкие недочеты и обеспечить полную ясность.
• Обеспечение задач релевантными вопросами. По каждому заданию участник тестирования должен был ответить на вопрос «Была ли выполнена задача?», а также «Оцените уровень ее легкости/сложности». Ответ на первый вопрос давал понять, осуществима ли задача; в то время как второй — позволял углубиться в возможные улучшения дизайна.
• Избегание наводящих вопросов. При тестировании использовался такой, к примеру, вопрос, как «Насколько легко или трудно было вам выполнить эту задачу?» вместо «Насколько трудно было выполнить эту задачу?», что предотвращает вероятность необъективного ответа.

Для сбора качественных и количественных данных специалисты провели три удаленных юзабилити-тестирования, в каждом из которых участвовало минимум 5 человек. Выявив болевые точки, они разработали потоки задач (task flows), имитируя шаги каждого пользователя на основе текущего дизайна. Проанализировав их и выявив недостатки юзабилити, они улучшили потоки, котоорые и послужили в качестве функциональных принципов редизайна.

3. Дизайн и итерация

Глен Липка (Glen Lipka), вице-президент User Experience, считает, что последовательный (UI, user interface) лучше, чем совершенный пользовательский интерфейс. Последовательность порождает узнаваемость, которая в свою очередь способствует более частому обращению. Ниже приводятся несколько руководящих принципов:

• Дизайн для информации. Люди используют веб-сайты не для того, чтобы восхищаться красивыми дизайнами, но потому что им нужен контент. В описываемом случае, учитывая, что Yelp — это сайт для поиска на местном рынке услуг, редизайн нуждался в лучшей доставке нужной информации нужным людям, и тестирование информационной архитектуры при помощи карточной сортировки было неотъемлемой частью этого процесса.
• Следование принципу MAYA (Most Advanced Yet Acceptable) , «наиболее передовой и в то же время воспринимаемый». В то время как команда хотела обеспечить лучший опыт для изредка заходящих на сайт Yelp пользователей, они не хотели создать нечто настолько чужеродное, что могло бы оттолкнуть опытных пользователей или запутать новых.
• Изучение паттернов пользовательских интерфейсов. Были изучены существующие модели пользовательского интерфейса на других известных сайтах и найдено то, что можно было перенять у них.
• Сделать сайт приятным и удобным для использования (usable). Опыт для изредка заходящих на сайт Yelp пользователей должен был быть более понятным. В то же время, специалисты хотели сохранить приятный внешний вид сайта.

Конечная цель состояла в достижении локального максимума (local maximum). Проект был завершен как только затраты превысили выгоды дополнительной итерации. С учетом ограниченности по времени дизайн-спринта, разработчики не зацикливались на получении глобального максимума (global maximum).

Понимание вашего бизнеса перед проведением тестирования

Прежде чем начать работу над UX, вы должны сперва понять свой бизнес. Какие проблемы он решает, каким образом приносит деньги? В чем он успешен, а в чем его можно улучшить?

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

Для первого шага специалисты выбрали , поскольку это легкая и вместе с тем всесторонняя визуализация бизнеса:

Не будем утомлять вас всей документацией, поэтому просто посмотрим на то, как вы можете сделать это в целях UX на примере Yelp:

• Самая главная проблема: Люди в определенном городе хотят получить [лучший / быстрый / самый дешевый / самый простой] [продукт / услугу].
• 3 самые основные функции: Отзывы пользователей, лента активности (activity stream), поиск по городу / категории.
• Уникальное ценностное предложение: Возможность вносить компании в список, добавлять отзывы и видеть компании, рекомендованные друзьями и другими пользователями.
• «Несправедливое преимущество» (то, что не может быть скопировано или куплено): Сетевые эффекты (network effects) наличия большой базы пользователей.

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

2. Определение объектов пользовательского тестирования

Учитывая уже имеющуюся у сайта огромную базу пользователей, было решено, что наиболее интересными областями исследования станут частота обращений и удержание пользователей. По мнению Нила Патела (Neil Patel), генерального директора QuickSprout, добавление или удаление функций может добавить ценности продукту. Исходя из этих соображений, мы определись с нужными вопросами:

• Какие функции используют люди при выборе ресторана? (например, фотографии, рейтинг и т.д.)
• Могут ли пользователи выбрать ресторан на основе нескольких конкретных критериев?
• Знают ли пользователи, как сохранять варианты?
• Могут ли они узнать, открыто ли конкретное место в данный момент?

3. Выбор методов тестирования

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

Планирование и сбор качественных данных (qualitative data)

Удаленное юзабилити-тестирование с использованием специального ПО (например, UserTesting) для записи экрана и голоса участника позволяет увидеть действия пользователя и услышать его мысли во время выполнения им определенной задачи.

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

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

Такие критерии отбора как возраст, пол, уровень дохода или уровень владения интернетом были не важны. Поскольку это исследование проводилось исключительно с целью качественного анализа, специлаисты не нуждались в (statistical significance) для подтверждения полученных данных. Они последовали лучшим отраслевым практикам и провели свое исследование с участием 5 пользователей. И, наконец, для простоты дизайн-спринта они тестировали сайт Yelp только на стационарном компьютере.

Целью тестирования было выяснить, как эти пользователи справляются с несколькими заданиями общего характера (для определения наиболее важных функций) и, по крайней мере, с одной менее распространенной задачей (чтобы выяснить, умеют ли они пользоваться более продвинутыми функциями).

Задания общего характера включали в себя:

• Сфокусированное задание — найти компанию на основании конкретных параметров
• Открытое задание — найти компанию при наличии очень малого количества директив
• Очень конкретное задание — найти определенное место и узнать конкретную информацию о нем

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

Что касается менее распространенных заданий, они предусмотрели различные варианты для каждой группы пользователей. Так как поступило несколько жалоб от зарегистрированных пользователей Yelp касательно функций «Закладка» и «Списки», специалисты попросили зарегистрированных пользователей (группа 1) сохранить компанию для последующего к ней обращения. Для пользователей без учетных записей (группа 2) задачей было найти мероприятие. Важно было увидеть, воспользуются ли они функцией поиска или нет при выполнении этого задания и как они будут принимать решение о том, какое событие посетить.

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

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

Качественный анализ пользовательского исследования

После того как исследование было завершено, настало время проанализировать результаты и определить основные проблемы, с которыми сталкивались пользователи на сайте Yelp. И вот что удалось выяснить:

1. Функция поиска была основной отправной точкой для любой задачи.

Все пять участников воспользовались панелью поиска (search bar) даже в тех заданиях, где можно было легко обойтись и без нее.

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

2. Вкладка «События» не была достаточно заметной.

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

Как ни странно, никто не воспользовался вкладкой «События». Один из участников теста обратился к панели поиска, а другой перешел в категорию «Искусство и Развлечения».

3. Функция закладок оказалось непонятной, а также никто не использовал списки.

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

Из трех участников:

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

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

4. Поиск конкретного места оказалось очень быстрым и легким заданием.

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

5. Пользователи руководствовались фотографиями для определения атмосферы ресторана.

В ответ на просьбу найти ресторан с определенной атмосферой ни один из пяти участников не попытался воспользоваться панелью поиска. Вместо этого трое просмотрели фотографии ресторана на Yelp, один посетил сайт ресторана, а последний посчитал, что символы стоимости ($,$$,$$$,$$$$) — достаточный показатель того, обладает ли ресторан нужной атмосферой.

6. Фильтры использовались участниками, но могут быть улучшены.

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

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

Когда участники искали ресторан по определенным параметрам, одним из требований было найти ресторан в пределах $ 20/чел. Двое из пяти пользователей были сбиты с толку, в какую категорию следует отнести ресторан с таким бюджетом: $, $$, или $$$ категорию. Один из них заявил, что не знает, что означают эти символы, а другой выбрал неверную категорию. Остальные трое пользователей верно выбрали $$ категорию.

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

Сбор количественных данных о поведении пользователя

Следующей целью стал более подробный анализ . Для этого специалисты провели тестирование первого клика и тестирование с закрытыми картами.

1. Сортировка закрытыми картами с помощью инструмента OptimalSort.

Сортировка закрытыми картами предполагает выдачу участникам карт, содержащих названия, которые затем участники должны сопоставить с имеющимися категориями (в отличие от сортировки с открытыми картами, где пользователи должны сами создать категории). При назывании карт следует придерживаться принципа «чем проще, тем лучше». Несколько рекомендаций, применимых к сортировке как закрытыми, так и открытыми картами:

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

Применяемая в описываемом тесте сортировка картами имела три простые цели:

• Определить, как часто люди используют поисковые фильтры на сайте Yelp
• Определить, какие фильтры являются наиболее важными
• Определить, какие фильтры являются наименее важными

В общей сложности у разработчиков было 47 карт, отображающих все 47 фильтров поиска Yelp (цена, расстояние и т.д.). Затем участников попросили рассортировать их по категориям важности: «очень важный», «довольно важный», «не важный», и «я не знаю, для чего нужен этот фильтр»:

2. Тестирование первого клика с помощью инструмента Chalkmark

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

1. Пропишите четко задачи. Убедитесь, что участник думает о том, как решить проблему, а не просто о том, где кликнуть.
2. Определите лучшие пути для выполнения задачи. Начиная с домашней страницы, постройте все возможные пути для достижения каждой цели.
3. Отведите определенное время на выполнение задач.

Данное тестирование должно было:

• Определить, дает ли информационная архитектура возможность быстрого выполнения задачи
• Определить, ясны ли навигационные ярлыки

Специалисты попросили пользователей выполнить определенные задачи, снабдив их скриншотами страниц Yelp. Затем они проанализировали результаты (heatmap) и скорость выполнения этих задач участниками.

Количественный анализ пользовательского исследования

После проведения качественного анализа были проанализированы данные двух дистанционных исследований с помощью инструмента Optimal Workshop.

1. Результаты тестирования фильтров поиска на сайте Yelp с помощью сортировки закрытыми картами

92,5% участников сказали, что регулярно используют фильтры поиска на этом сайте.

Наиболее важными фильтрами для пользователей оказались «Отрыто сейчас», «Принимают кредитные карты» и «Специальные предложения».

Более 88% участников решили, что 7 фильтров вовсе не важны.

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

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

Результаты тестирования первого клика на домашней странице Yelp

2. 30% участников посчитали сайт «перенасыщенным» или «сбивающим с толку».

Тепловая карта продемонстрировала значительные различия того, где именно кликали пользователи. Участников попросили найти ресторан с умеренными ценами, который мог бы вместить компанию до 20 человек. Выполнение задания заняло в среднем 15 секунд — что в условиях интернета много. На изображении ниже вы видите, что 55% кликнули по пункту меню «Рестораны» в верхнем правом углу. Остальные 45% кликнули в совершенно разных местах. Наличие потенциальных ответов в нескольких местах на странице увеличивает когнитивную нагрузку пользователей и вероятность неверного первого клика:

24% участников использовали панель поиска, когда искали механика из их города (одно из заданий). Большинство участников перешли к категориям услуг, расположенных в левой части сайта. Но вторым по популярности действием все же стало использование панели поиска.

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

В результате 37% людей проигнорировали обе эти вкладки и перешли сразу же к строке поиска. 37% людей кликнули по нужной вкладке «События». 18% нажали на вкладку, находящуюся в главной панели навигации.

На основе полученных количественных данных были определены следующие задачи для редизайна:

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

Дизайн, ориентированный на пользователя, и Итерация

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

Якоб Нильсен (Jakob Nielsen), соучредитель Nielsen Norman Group, классифицирует большинство процессов проектирования, включающих юзабилити-тестирование, по двум категориям: итерационное проектирование (iterative design) и параллельное проектирование (parallel design).

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

1 схематично изображенный каркас, несколько итераций → бумажный / интерактивный каркас, несколько итераций → визуальные дизайны, несколько итераций

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

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

3 разных одновременно сделанных дизайна → Пользовательское тестирование (соединяются лучшие идеи дизайна) → 1 дизайн → Итерационый процесс проектирования

Один большой раунд пользовательского тестирования приводит к одному унифицированному дизайну. Для дальнейшего его усовершенствования лучше использовать итерационный процесс, при котором небольшие изменения тестируются небольшими группами по 5-10 пользователей до тех пор, пока дизайн не станет окончательным.

Описанный процесс редизайна Yelp был по существу параллельным процессом совместно с UX-тестированием, проведенного в самом начале. Так как это был лишь гипотетический редизайн, разработчики остановились после шага «1 дизайн». Если бы это был настоящий редизайн, следующим шагом стало бы проведение дальнейшего тестирования для улучшения прототипа.

Составление эскиза

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

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

Эскиз был выполнен с учетом некоторых основных проблем юзабилити, выявленных в ходе тестирования домашней страницы:

• Повышение видимости панели поиска
• Сделать вкладку «События» более заметной
• Оптимизировать категории

Кроме того, был добавлен футер и «Отзыв дня» перемещен с правой части страницы в низ.

2. Страница результатов поиска Yelp

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

В этом эскизе были учтены следующие моменты:

• Фотографии должны быть более заметными
• Обозначить категории цен

Создание каркаса

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

Учитывая сложность текущей домашней страницы Yelp, специалистам потребовалось 4 итерации. В добавок к устранению проблем юзабилити, они также хотели сохранить
SEO-аспекты (например, список других городов). Ниже мы сосредоточимся на последней итерации.

• Улучшение панели поиска

Текущий дизайн:

Панель поиска находится в верхней части страницы.

Измененный каркас:

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

• Оптимизировать перечень категорий

Текущий дизайн:

Измененный каркас:

Новая конструкция является более визуальной и представляет только 8 категорий одновременно. Чтобы увидеть больше, пользователям надо просто нажать на кнопку «Другие компании», которая была перемещена ближе к верхней ⅓ страницы для более сильного визуального акцента.

• Облегчить нахождение вкладки «События»

Текущий дизайн:

«События» либо скрыты в дальнем правом углу в верхней панели навигации (не показано здесь), либо отодвинуты на боковую панель в середине прокрутки.

Измененный каркас:

Измененный макет помещает «События» в центр прокрутки. Можно либо вставить функцию «Фото» слева от текста, либо добавить видео, проигрывающееся в фоновом режиме.

• Уменьшение общего хаоса

Текущий дизайн:

Измененный каркас:

Любые вторичные элементы, такие как «Популярные события» или «Списки» (которые по результатам юзабилити-тестирования ни разу не были даже использованы) были перенесены в футер.

2. Страницы результатов поиска Yelp

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

Текущий дизайн:

Фильтры и сортировка Yelp испытывают недостаток иерархии.

Измененный каркас:

Новый каркас выделяет наиболее важные фильтры и перестраивает всю область на квадраты. Каждая категория фильтра включает в себя только четыре варианта, что дает визуальную упорядоченность.Так как 90% пользователей посчитали фильтр «Открыто сейчас» важным, разработчики выделили его как отдельный элемент. Цены прояснены диапазонами доллара, а 7 неважных фильтров скрыты.

• Улучшение макета результатов поиска

Текущий дизайн:

Большинство пользователей опирались на фотографии для определения атмосферы места, но иконки изображений в списках слишком малы. Также нет возможности сохранить компанию в закладки .

Измененный каркас:

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

Прототипирование: низкая и высокая точность

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

1. Прототипирование с низкой точностью

Поскольку такие прототипы являются по своей сути незавершенными, люди дают более объективную обратную связь по основным функциям и общему дизайну.

Разработчики из UXPin, UserTesting и Optimal Workshop хотели, чтобы просмотр категорий, выбор фильтров, и переключение между главной страницей и страницей с результатами поиска было беспроблемным опытом для участников. Если бы это был настоящий редизайн, их следующим шагом было бы пользовательское тестирование этого прототипа, а затем повторная итерация.

2. Прототипирование с высокой точностью

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

Специалисты добавили точности, задействовав свою библиотеку элементов пользовательского интерфейса. Что нельзя было сделать в браузере, было создано в Photoshop или Sketch, а затем импортировано непосредственно в UXPin с помощью функции drag & drop. Слои были сохранены, так что надо было только нажимать на элементы и добавлять взаимодействия.

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

Заключение

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

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

К слову, дизайн сайта Yelp, описанный в данной статье, все же претерпел некоторые изменения и теперь выглядит так:

Не исключено, что его разработчики использовали перечисленные выше принципы, чтобы добиться результата, отчасти напоминающего тот, к которому пришли специалисты из UXPin, UserTesting и Optimal Workshop

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

Каких результатов можно добиться при помощи юзабилити-тестирования сайта?

В первую очередь притока новых пользователей или клиентов. Качественное юзабилити-тестирование с последующим устранением выявленных недочетов позволяет моментально получить положительный результат!

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

Разновидности тестирования юзабилити

В зависимости от поставленных целей различают следующие виды исследований:

Качественное тестирование.

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

Количественное тестирование.

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

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

Цель - провести прямое сравнение с более успешными конкурентами в нише. Это один из самых важных и результативных методов, позволяющих не повторить чужих ошибок юзабилити.

Кросс-культурное тестирование.

Цель - адаптировать зарубежный продукт для российского покупателя или наоборот.

Пользовательское тестирование

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

Айтрекинг-тестирование

Цель - оценить эффективность расположения и видимость блоков сайта. Проводится с помощью специального устройства, которое оценивает, куда и как долго смотрит пользователь.

Тестирование методом персонажей

Цель - понять поведение на сайте типичных представителей различных групп ЦА и на основе полученных знаний об их предпочтениях удовлетворить наиболее широкую группу пользователей.

Экспертный анализ

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

A/B-тестирование

Цель - предложить пользователям несколько вариантов дизайна и сравнить реакцию. Выделяются последовательные и параллельные A/B-тесты. При последовательном тестировании usability правки сразу вносятся на сайт и замеряются периоды до и после изменений. При параллельном делается несколько версий, которые сравниваются с основной.

Все перечисленные методики тестирования так или иначе влияют на повышение юзабилити, но компания Demis Group, основываясь на своем большом опыте, использует два направления:

• оценку удобства использования;
• сравнение с сайтами-конкурентами.

Подготовка к юзабилити-тестированию и получение отчета

Подготовка состоит из 4 основных этапов:

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

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

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

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

Как подобрать респондентов для тестирования юзабилити?

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

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

Как создать сценарий для респондентов?

Чтобы создать сценарий пользователя, важно понять 3 вещи:

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

Какие трудности могут возникнуть у пользователей при решении проблем. Например, на сайте имеется непонятное меню, обязательная регистрация, неудобная форма записи к мастеру и т. д.

С какими проблемами уже сталкивались пользователи. Возможно, об этом писали в службу поддержки.

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

Вот в качестве примера два варианта задания:

Близится отпуск с 10 по 17 сентября, и уже куплены билеты. Вы летите вдвоем. Мужу хочется, чтобы отель располагался недалеко от моря, а жене важен интернет и сервис. Выберите отель в Италии так, чтобы все были довольны, и забронируйте его на неделю с 10 по 17 сентября.

Забронируйте номер в отеле Италии.

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

Примеры наших кейсов по юзабилити-тестированию

Проведение юзабилити-тестирования сайта

Процедура состоит из двух этапов.

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

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

Анализ результатов тестирования юзабилити

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

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

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

Примерное описание удобного ресурса

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

Ресурс говорит на языке целевой аудитории и использует понятные термины.

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

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

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

Ресурс понятен и для новичков, и для опытных пользователей.

Сообщение об ошибке пишется понятным языком, и посетитель понимает, как решить проблему, если она возникла.

Информацию на сайте легко найти, и она соответствует запросам аудитории.

«Шеф-редактор блога GetGoodRank, веб-аналитик, блоггер.
Пошаговая инструкция, как провести юзабилити тест самостоятельно с минимальными вложениями. Как анализировать результаты и какие есть альтернативы.»

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

Зачем проводить юзабилити тест?

Оптимизированный интерфейс, удобный для пользователя, создает положительное первое впечатление.

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

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

Удобный сайт вызывает доверие, повышает лояльность к бренду.

Как проводить юзабилити тест самостоятельно?

Кто будет тестировать сайт и где найти пользователей для теста?

В идеале тестировать сайт должны пользователи, близкие вашей целевой аудитории. Чем точнее будет соответствие, тем репрезентативнее станут результаты теста. Кто может стать тестировщиком:

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

Преимущества: максимальное соответствие тестировщика целевому пользователю.
Недостатки: пользователи уже знакомы с сайтом, а так, уже умеют обходить «косяки».

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

Преимущества: это новые пользователи, которые не знакомы с сервисом, сайтом, приложением, компанией, услугой, товаром.

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

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

Преимущества: быстрый способ получить достаточное количество целевых пользователей для тестов.

Недостатки: часто высокая стоимость.

Как провести юзабилити тест?

Существует два типа тестирования:

Модерируемое или контролируемое - вы непосредственно принимаете участие в тесте, инструктируете участника, задаете вопросы, делаете пометки. Для проведения контролируемого юзабилити теста вам понадобится любое приложение с поддержкой видеозвонков и совместного доступа к интерфейсу сайта (Skype, Google Hangouts). Чтобы получить возможность записать тест, вам потребуются платные инструменты как GoToMeeting или Zoom.

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

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

Как написать сценарий теста

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

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

Основные правила сценария проверки сайта:

1. Тест должен имитировать реальный путь пользователя, заинтересованного в товаре/услуге. Для этого можно использовать данные из системы аналитики.

2. Тест должен быть понятным, логичным и простым для выполнения.

3. Тест должен предоставлять пользователю предысторию: кто, что, когда, зачем, почему.

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

5. Не используйте термины и профессиональный жаргон для постановки задач. Они должны быть простыми и ясными.

Какие данные собирать

В проведении юзабилити теста важно получить две записи:

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

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

Другие полезные данные, которые вы сможете извлечь из записей:

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

Сколько проводить тестов

Эксперты NNGroup указывают, что для проведения теста достаточно привлечь всего 5 пользователей. Этого будет достаточно, чтобы выявить до 80% ошибок юзабилити сайта или приложения. Чтобы получить более точную выборку по количественным данным, для теста понадобится до 20 пользователей.

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

Как анализировать полученные результаты

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

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

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

Подготовка, интервью и сбор данных

В закладки

Руководитель направления 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 исследования (или дизайнерские исследования) имеют множество целей в зависимости от этапа работы. Они помогают определить, а после чего доказать или опровергнуть наши предположения, найти общие черты среди членов целевой аудитории, понять их нужды, цели и ментальные модели. Исследования дают нам необходимые для работы данные, улучшают понимание и подкрепляют наши решения.

Что такое UX исследования?

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

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

Исследования состоят из двух частей: сбор данных и их обработка с целью улучшить юзабилити. В начале проекта дизайнерские исследования посвящены определению требований к проекту от руководителей, а также целей и нужд конечных пользователей. Сюда входит проведение интервью, опросов, изучение потенциальных или существующих пользователей, анализ имеющейся литературы и данных. Затем исследования начинают ориентироваться на юзабилити и мнения о продукте. На данном этапе проводятся A/B тестирования, интервью с пользователями о процессе взаимодействия и тестирование предположений, которые способны улучшить дизайн.

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

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

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

Общие методики

Все разнообразные типы UX исследований от личных интервью до A/B тестирования основываются на трех методиках: наблюдении, понимании и анализе.

Наблюдение

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

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

Понимание

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

Ментальная модель – это представление о мыслях людей об определенной фразе или ситуации. Например, ментальная модель автомобиля владельцев внедорожников будет отличаться от ментальной модели водителей электромобилей. Ментальная модель влияет на решения. Если спросить у автомобилистов: «Сколько времени занимает дорога из Москвы до Санкт-Петербурга», помимо всех прочих данных, они будут ориентироваться и на характеристики своего автомобиля.

Исследователи должны понимать ментальные модели людей, с которыми они проводят интервью, по двум причинам:

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

Анализ

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

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

Виды исследований

Все UX проекты разные, поэтому и список задач может существенно различаться. Самые популярные формы исследования: интервью, опросы и анкетирования, сортировка карточек, тестирование юзабилити, тестирование иерархии и A/B тестирование.

Интервью

Личное интервью – проверенный и доказавший свою эффективность метод коммуникации между исследователем и пользователем или руководителем. Существует три основных типа интервью, каждый из которых преследует разные цели:

• Стандартизированное интервью – самый распространенный тип. Это типичные интервью вопрос-ответ, когда исследователь задает конкретные вопросы. Оно может быть полезно при общении с большим количеством пользователей, когда необходимо сравнить и сопоставить ответы.
• Свободное интервью – отличный способ лучше узнать пользователей или руководителей. Исследователь устанавливает определенные рамки и начинает разговор. В течение интервью говорить должен в основном пользователь (или руководитель), ведущий же может только попросить объяснить что-либо или рассказать подробнее.
• Этнографическое интервью позволяет узнать привычки людей и понять их типичное поведение. Пользователь рассказывает, как он совершает то или иное действие. Такое интервью позволяет оценить разрыв между тем, что люди говорят, и тем, что они делают.

Опросы и анкетирование