Тестирование удобства использования коридора:Какую часть пользовательского интерфейса вы на самом деле делаете функциональной?

Question

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

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

Спасибо.

Answer 1

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

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

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

При тестировании в коридоре, если пользователи нарушают условия верности, вы можете просто сказать: “Я еще не сделал эту часть.Давайте вернемся к A и продолжим оттуда ”. Конечно, вы должны отметить, что пользователь ошибся в выполнении задачи, которую вы для него предназначили.У меня не было никаких проблем с пользователями, жалующимися на нефункциональные функции, когда я заранее сообщаю им, что это неполный прототип, и на данный момент мы тестируем пользовательский интерфейс только для функций x, y и z.

Что касается прототипов с низкой точностью воспроизведения, я часто называю их для пользователей “макетами” или “чертежами”, а не “прототипами”, чтобы указать на низкую функциональность.Вы можете поместить очевидные заполнители для отсутствующего контента (например, “Бла-бла-бла ...”, “ЗАДАЧА:Фотография продукта примерно здесь ”).Если пользователь прокомментирует что-то за пределами fidelity envelope (например, “Этот символ должен быть красным, чтобы больше выделяться”), просто отметьте это и скажите, что тема находится в стадии разработки (например, “Спасибо.Мы еще не приступили к работе над цветами.Мы просто пытаемся выяснить, как организовать сайт прямо сейчас ”.).

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

Answer 2

Несколько вещей, которые следует запомнить:

1. Тестируйте заранее и часто.
2. Целью юзабилити-тестирования является выявление проблем с пользовательский интерфейс, а не задавать вопросы по вашему коду.

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

Answer 3

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

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

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

Answer 4

Для коридорного теста я бы протестировал НИ ОДИН реализованный функционал.

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

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

Answer 5

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

Answer 6

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

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

Заставьте его работать, будь то черновая версия, фиктивные данные или даже простое сообщение о том, что «теперь результаты будут отсортированы в алфавитном порядке».