Прототип пользовательского опыта — это гипотеза, вариант дизайнерской разработки, который вы рассматриваете в качестве возможного решения проблемы. Самый простой способ проверить гипотезу — посмотреть на то, как рядовые пользователи будут с ней работать. Существуют разные классификации прототипов:
- одностраничный сайт, или мультистраничный с достаточным количеством меню и экранов, с помощью которых пользователь выполняет свои задачи;
- реалистичный и подробный прототип или схематичный, существующий в виде наброска на бумаге;
- интерактивный (кликабельный) или статичный (действия компьютера имитирует человек).
Выбор того или иного варианта зависит от целей тестирования, завершенности дизайна, использованных при создании прототипа инструментов и ресурсов для поддержки до и во время проведения юзабилити-тестирования. Но какой бы прототип вы ни использовали, его тестирование расскажет многое об эффективности пользовательского опыта, качестве взаимодействия аудитории с интерфейсом — и позволит внести требуемые корректировки.
Зачем тестировать прототип?
Коррекция кода готового продукта или сайта стоит дорого, а изменить прототип куда дешевле, особенно если он изображен на листе бумаги. Но часто против тестирования прототипов приводят следующие доводы:
- финальная версия дизайна предпочтительнее для проведения тестов, поскольку она представляет собой рабочую систему, и пользователи, взаимодействуя с ней, будут чувствовать себя гораздо естественнее и спокойнее, а значит и результаты испытаний будут более достоверными;
- некоторые сторонники концепции Lean Startup отмечают, что без тестирования прототипа не понадобится избавляться от него, если он провалит тесты, а значит — не будет и дополнительных расходов;
- отсутствие настроек в гибкой или каскадной модели разработки при согласовании UX и итеративного дизайна.
Эти аргументы только первый взгляд кажутся убедительными. Но бросать тесты продукта до финальной стадии довольно рискованно. Опытные разработчики найдут время на прототип продукта, его тестинг и совершенствование до оптимального состояния. При этом тестирование продукта на финальной стадии также обязательно: для оценки юзабилити, рентабельности, проведения конкурентного анализа и окончательной проверки проекта.
Интерактивные и статичные прототипы
Любой прототип должен реагировать на действия пользователя. Вы можете затратить немало времени, но все же имплементировать интерактивные элементы до начала тестов, либо просто имитировать реакцию системы. Оба метода имеют преимущества и недостатки.
Интерактивные (кликабельные) прототипы
При выборе интерактивного прототипа дизайнеру придется установить отклик системы на каждое возможное действие пользователя еще до проведения теста. Даже при наличии всех необходимых инструментов это займет много времени.
Статичные прототипы
Здесь реакция системы на действия пользователя имитируется человеком, хорошо знакомым с дизайном. Существует несколько методов имитации, пригодные в статических прототипах:
1. «Волшебник страны Оз»
Метод назван в честь популярной книги Фрэнка Баума (Frank Baum). В произведении, как вы помните, волшебником оказался обычный человек. В опыте «волшебник» (роль которого играет дизайнер, хорошо знакомый с прототипом) удаленно контролирует экран участника, находясь в другой комнате. Ни один из кликов пользователя на самом деле ничего не значит. Когда человек совершает действие, «волшебник» за стенкой решает, что должно произойти дальше, и вносит изменения в экран пользователя. При этом испытуемым неизвестен источник изменений и откликов системы. И как правило, они возмущаются, что система постоянно тормозит и долго реагирует.
Этот метод полезен при тестах систем на основе искусственного интеллекта — до его имплементации, поскольку «волшебник», управляющий компьютером, имитирует реакции ИИ на основе естественного интеллекта.
2. Бумажный прототип компьютера
Дизайн создается на бумаге. Человек, хорошо знакомый с макетом, играет роль компьютера и кладет бумаги на стол возле пользователя, но не в зоне его видимости. Как только пользователь касается пальцем бумажного «экрана», лежащий перед ним, «компьютер» подбирает правильную страницу и помещает ее перед пользователем.
3. «Захваченная» мышь (Steal-the-Mouse)
Версия «Волшебника страны Оз», где «волшебник» сидит в той же комнате, что и пользователь (роль «волшебника» может сыграть ведущий). Прототип демонстрируется пользователю на экране компьютера. Как только участник совершает клик, ведущий просит его отвернуться, а сам вносит изменения на экране. Затем человек продолжает работу с прототипом.
Советы
1. «Компьютер» должен оповещать о завершении каждой операции, чтобы пользователь продолжал взаимодействие с системой. Таким сигналом можно выбрать специальный жест или распечатанную на бумаге иконку (например, песочных часов), возникающую каждый раз, когда «компьютер» подбирает наиболее подходящий ситуации отклик, и исчезающий, когда операция завершается.
2. Ведущий должен удерживаться от комментариев и объяснения дизайна пользователю.
Чтобы определить наиболее подходящий вам прототип, ответьте на вопросы:
- есть ли у вас время и необходимые навыки для имплементирования в систему откликов на все возможные действия пользователя?
- есть ли у вас время для проведения пилотных тестов и исправления всех найденных ошибок?
- вы можете сказать, что ваш дизайн завершен и вам не придется вносить изменения между сессиями?
- для дизайнера возможно играть роль компьютера во всех проводимых тестах?
- переход от одного экрана к другому является важной частью исследования?
- реакция пользователя на динамические изменения является важной частью испытаний?
Если большинство ответов утвердительные, то попробуйте кликабельный вариант, если — нет, то подойдет и статичный.
Прототипы бывают точные и неточные. Точность прототипа означает, насколько сильно он соответствует конечному виду системы. Точным модель может быть в плане интерактивности, внешнего вида, содержания и управления.
Прототип может иметь высокую или низкую точность по всем или некоторым перечисленным компонентам. Ниже объяснено, в чем выражена высокая и низкая точность этих элементов:
Точный прототип | Неточный прототип | |
Интерактивность | ||
Кликабельные ссылки и меню | Их много. Большинство из них кликабельны. | Нет. Интерактивные элементы не работают. |
Автоматический отклик на действия пользователя | Да, ссылки в прототипе нужны для работы посредством инструмента прототипирования | Отсутствует. Экраны сменяются человеком, играющим роль компьютера |
Внешний вид | ||
Реалистичная визуальная иерархия, приоритет элементов экрана и размер экрана | Да, вся графика и макет выглядят как в готовом продукте (даже если прототип реализован на бумаге). | Нет, с финальной версией системы могут совпасть только отдельные элементы. Размещение и приоритет элементов может быть сохранен, а может и нет. |
Контент и иерархия навигации | ||
Контент | Прототип включает весь контент, который появится в финальном дизайне (все статьи, описания продуктов, изображения). | Нет, в прототипе представлено лишь краткое содержание материалов и плейсхолдеры вместо изображений. |
Преимущества высокоточных прототипов
1. Прототипы, точные в плане интерактивности, показывают более высокий отклик на тестах. Нередко поиск правильного экрана или отклика на действие пользователя у человека, играющего роль компьютера, может занять дополнительное время. Слишком длинные задержки между действием пользователя и реакцией «компьютера» нарушают плавное взаимодействие с интерфейсом и отвлекают участника от последнего события и ожидаемого отклика системы.
Задержка также дает дополнительное время на изучение страницы. Поэтому при работе с медленным прототипом участники юзабилити-тестов охватывают больше деталей и контента, чем при работе с реальной системой. Конечно, это вносит определенную долю искажения в итоговые результаты. Уменьшить отрицательное воздействие задержек можно, если во время ожидания ответа системы просить пользователя уводить взгляд в сторону или помещать перед ним пустой белый лист.
Как только новый экран будет готов, следует в течение нескольких секунд демонстрировать предыдущий экран, чтобы пользователь освежил в памяти свои прошлые действия, и только потом показывать новый. Посильную помощь может оказать и ведущий эксперимента, словесно указывая пользователю на его прошлые действия. Например, подсказав: «Здесь вы кликнули по ссылке «О компании».
2. Если прототип близок к финальному виду системы в плане интерактивности или ее визуальной стороны, вы сможете протестировать рабочие процессы (workflow), конкретные компоненты пользовательского интерфейса (например, мега-меню, раскрывающиеся меню), такие графические элементы, как affordance («очевидности» в дизайне), иерархию страниц, читаемость шрифта, качество изображений и даже степень вовлечения (engagement).
3. Высокоточные прототипы воспринимаются как действующие версии программ и сайтов. Это значит, что участники эксперимента поведут себя реалистичнее, как если бы они взаимодействовали с настоящей системой. А схематичный прототип может вызвать неясные ожидания возможностей системы. В итоге поведение пользователей перестает быть стопроцентно естественным.
4. Точные в плане интерактивности прототипы освобождают от необходимости имитировать работу системы и дают сосредоточиться на ходе эксперимента.
5. При тестировании интерактивных прототипов вероятность ошибки меньше. Имитация работы системы — ответственная задача, а человеку свойственно ошибаться. Спешка, стресс, нервное напряжение, необходимость пристально следить за кликами пользователя — все это станет причиной нелогичной работы «компьютера» и исказит результаты испытаний.
Преимущества прототипов низкой точности
1. Меньше времени на подготовку статичного прототипа, больше времени на работу над дизайном до начала экспериментов
Создание кликабельного прототипа требует времени. Но его разумнее потратить на создание большего числа страниц, меню или контента. (Вам все равно придется расположить страницы в правильном порядке, чтобы обеспечить нормальную работу «компьютера», но это обычно занимает куда меньше времени, чем создание интерактивного прототипа).
2. Проще корректировать дизайн в ходе эксперимента
Дизайнер может набросать быстрый план изменений и внести их между тестовыми сессиями, не тратя время на адаптацию и связь новых элементов с существующей системой, как при интерактивном прототипе.
3. Неточные прототипы не оказывают давления на пользователей
Если дизайн кажется незавершенным, пользователи не станут задаваться вопросом, сколько времени ушло на его разработку, месяц или пара дней. Они будут убеждены, что вы действительно тестируете систему, а не самих участников, не почувствуют себя обязанными справиться со всеми заданиями и станут охотнее проявлять негативные эмоции.
4. Дизайнеры относятся к прототипам без лишнего трепета
Вносить корректировки в готовую систему, интерактивную и не лишенную эстетики, не всегда приятно. Инвестировав в дизайн время и силы, от него гораздо сложнее отказаться, даже если он работает неудовлетворительно. Дизайн, существующий в виде наброска на бумаге, корректируется без лишних разговоров и сантиментов.
5. Инвесторы и прочие заинтересованные стороны не докучают вам
Когда люди видят сырой прототип, они не ожидают получить готовый продукт на следующий день. Каждый член команды разработчиков будет готов к любым изменениям в проекте до его завершения.
Взаимодействие с пользователем в ходе испытаний любого прототипа
При тестировании прототипа ведущий, как правило, общается с участниками гораздо больше, чем при испытаниях готовой системы. Главным образом, это происходит по следующим причинам:
- ведущему необходимо объяснить природу прототипа (но не то, как работает дизайн);
- иногда ведущему необходимо объяснить текущее состояние системы (например, «Эта страница пока не работает») или спросить «Что, как вы ожидали, должно было произойти?»;
- бывает, что ведущему необходимо выяснить, по какой причине участник эксперимента прекратил работу: потому что ожидает отклика или потому что думает, что он выполнил задачу.
Даже несмотря на то, что ведущему приходится время от времени взаимодействовать с участником тестирования, его основная цель — спокойно наблюдать за человеком, работающим с дизайном, а не разговаривать с ним.
Советы
1. Если пользователь кликнул по элементу, для которого еще не был разработан соответствующий отклик:
- сказать: «Этот элемент не работает»;
- спросить: «Что, как вы ожидали, должно было произойти?»;
- попросить пользователя щелкнуть по следующему элементу.
Например: «Вы нажали на ссылку «компактные автомобили». К сожалению, мы еще не подготовили соответствующий экран. Попробуйте выбрать категорию «среднеразмерные автомобили». После того, как пользователь выберет этот пункт, старайтесь говорить как можно меньше, оставайтесь безучастным.
2. Если после клика перед пользователем открывается неправильная страница, «компьютер» должен убрать ее из поля зрения участника как можно быстрее, вместо нее загрузив предыдущую страницу. Ведущий должен незамедлительно сообщить, что открылась неверная страница, затем словесно проговорить действия участника на текущей странице. Уже потом «компьютер» показывает правильную страницу.
Ошибки «компьютера» искажают данные
Обратите внимание, что неточности, допускаемые «компьютером», могут оказать сильное влияние на результаты теста. Как только появляется экран, пользователи формируют ментальную модель того, как работают система и метод исследования. Если выводится не та страница, не думайте, что пользователи тут же исключат из памяти увиденное.
Даже если вы откатите процесс и попытаетесь объяснить ошибку, участники сделают вывод, что неверный экран все же как-то связан с задачей, и извлекут еще больше полезной информации из ваших объяснений, которые затем повлияют на их выбор и поведение. Демонстрация неверной страницы также нарушает последовательность действий и путает пользователей. Они могут решить, что прототип неисправен. Это повлияет на ожидания, доверие к методу исследования и способность образовывать последовательную ментальную модель.
Поскольку компьютерные ошибки негативно сказываются на исследовании, потратьте время на проведение пилотного теста и исправьте все неточности до запуска основных тестов.
Заключение
Отказаться от тестов прототипа нельзя. Ваш дизайн так или иначе будет протестирован, хотите вы того или нет. Как только система запустится и люди смогут ею пользоваться, они и протестируют ее. И вместо нужных сведений о качестве пользовательского опыта и интерфейса, вы получите: плохие отзывы и потерянные продажи, брошенные заказы, возвраты, отсутствие понимания контента и продуктов, звонки в службу поддержки, рост затрат на обучение, ухудшение имиджа.
И вам придется исправлять эти ошибки, что, разумеется, обойдется безумно дорого. А потому тестирование прототипов — интерактивных или нарисованных на бумаге — обязательный этап выхода на рынок.
Высоких вам конверсий!
По материалам: nngroup.com Image source Stefano Bertolotti
