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

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

Сначала — дизайн, затем — прототип

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

Используйте наполнение, связанное с реальным проектом

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

Не используйте «Lorem Ipsum»

Каждый раз при появлении текста «Lorem Ipsum» (как на Рисунке 1), кто-нибудь из участников спрашивает «Почему здесь всё на испанском?». Кроме того, что текст приводит в недоумение и может спровоцировать ошибки, он лишён какого-либо контекста и не даёт ни малейшего представления о финальном наполнении. Иногда для понимания назначения страницы контекст просто необходим. Старайтесь всегда использовать актуальное наполнение или найти подходящую рыбу.

Избегайте вымышленных имён

Не используйте в прототипах имена известных людей или персонажей. Однажды мне довелось тестировать прототип, где в качестве авторизованного пользователя выступал Джек Воробей (Рисунок 2). Уверен, вы бы не хотели, чтобы в разгар сессии участники забыли о поставленных задачах и погрузились в мысли о Джонни Деппе или о том, как ужасны последние «Пираты Карибского моря». Лучше использовать правдоподобные, но стандартные имена — здесь поможет генератор случайных имён, каких много в интернете.

Аккуратно используйте стандартные заготовки

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

Используйте подходящее оформление

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

Будьте внимательны, если прототип разрабатывает другая сторона

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

Убедитесь, что прототип точно соответствует дизайну

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

Исправления ошибок в прототипе не должны касаться проектной части

Несмотря на всеобщие усилия, ошибки в прототипе неизбежны, и тестирование их выявит. Естественно, клиенты захотят исправить всё между сессиями. Имея доступ к прототипу, они могут не удержаться и попытаться решить все выявленные при тестировании проблемы. Результат поспешных выводов может быть удручающим. В худшем случае «ошибки» исправят без вашего ведома, пока вы заняты тестированием. Будьте начеку и объясните клиенту, почему не стоит вносить изменения до окончания исследования.

Приведите прототип к соответствию с инструкцией

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

1. Определите, какие функции вы будете тестировать.
2. Создайте прототип.
3. Разработайте инструкцию для тестирования.
4. Используя прототип, проработайте все задачи в инструкции. Убедитесь, что всё работает.
5. Внесите необходимые исправления в прототип и инструкцию.

Проводите тестирование в несколько этапов с прототипами разной степени детализации

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

Тестируйте без прототипа

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

Тестируйте грубые прототипы

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

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

Если невозможно провести больше одной сессии, тестируйте прототипы средней степени детализации

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

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

Тестируйте сложные механизмы взаимодействия с помощью точных прототипов

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

Учитывайте ограниченные возможности прототипа

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

Прототип нуждается в пояснениях

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

Покажите образец

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

Опишите предполагаемую реакцию системы

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

Остерегайтесь тупиков

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

Используйте прототип для демонстрации решения клиентам

Кроме юзабилити-тестирования, прототипы играют важную роль в демонстрации дизайна клиентам. Заказчикам бывает сложно понять работу сайта или приложения на основе одних только статичных изображений. Я помню много случаев, когда клиенты вроде бы разбирались в блок-схемах, но в действительности не понимали ничего, пока им не удавалось испытать работающую модель. Интерактивные прототипы имитируют взаимодействие и позволяют быть уверенным, что у всех сложилось верное представление о работе сервиса. Объяснение того, как система работает, и демонстрация её работы — не одно и то же.

Другие рекомендации?

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

Оригинал: http://www.uxmatters.com/mt/archives/2012/10/tips-on-prototyping-for-usability-testing.php