Делает ли большинство из вас, проводя тесты юзабилити в коридоре, свои приложения полностью или почти полностью функциональными? Или вы просто проверяете правильность звеньев или цепочки? Или вы просто рисуете на бумаге и используете это?
Я хотел бы на раннем этапе протестировать прототип и пытаюсь найти хороший баланс. Но в то же время меня беспокоит, что некоторые нефункциональные части могут на самом деле не давать репрезентативных результатов.
Спасибо.
Юзабилити-тесты, проходные или другие, нуждаются только в той функциональности, которую вам нужно протестировать. В большинстве тестов юзабилити вы должны ответить на конкретные вопросы дизайна и разработать свой прототип для точка, где он может ответить на эти вопросы. Например, если вам нужно проверить, понимают ли пользователи ваше указание порядка сортировки для таблицы, все, что вам нужно, это бумажное изображение таблицы с указанием сортировки (с размытым содержанием таблицы) и спросить их, как сортируется таблица. . Если вам нужно протестировать IA, все, что вам нужно, - это набор веб-страниц, пусто, за исключением заголовка, на который есть ссылки в меню навигации.
Вам нужны только те страницы, которые соответствуют задачам, которые вы даете своим пользователям. Если вы просто тестируете IA, вам нужны только страницы на нормативном пути. Если вы также тестируете восстановление после ошибок, вам понадобятся страницы вне нормативного пути вместе с полными элементами управления навигацией. Если вы также тестируете обнаружение ошибок, вам также понадобится контент на страницах.
Вы также можете моделировать функциональные возможности, когда это проще сделать. Например, при тестировании, могут ли пользователи выяснить, как получить желаемый порядок сортировки, когда пользователь нажимает на нефункционирующий элемент управления для сортировки таблицы, вы можете сказать: «Хорошо, это даст вам это», и вы возьмите мышь и выберите закладку, которая показывает таблицу в новом порядке сортировки.
При тестировании в коридоре, если пользователи нарушают конверт верности, вы можете просто сказать: «Я еще не сделал этого. Давай вернемся к А и продолжим оттуда. Конечно, следует учитывать, что пользователь ошибся в поставленной вами задаче. У меня не было проблем с пользователями, которые жаловались на нефункциональные функции, когда я заранее говорил им, что это неполный прототип, и на данный момент мы тестируем пользовательский интерфейс только для функций x, y и z.
Для прототипов с низкой точностью я часто называю их «мокапами» или «рисунками» для пользователей, а не «прототипами», чтобы указать на низкую функциональность. Вы можете вставить очевидные заполнители для отсутствующего контента (например, «Бла, бла, бла…», «TODO: Изображение продукта здесь»). Если пользователь комментирует что-то за пределами диапазона точности (например, «Этот символ должен быть красным, чтобы выделяться больше»), просто отметьте это и скажите, что эта тема находится в стадии разработки (например, «Спасибо. Мы еще не начали работу над цветов пока нет. Мы просто пытаемся понять, как организовать сайт прямо сейчас »).
Юзабилити-тестирование с прототипами ограниченной верности действительно необходимо для того, чтобы итеративный дизайн был возможен для большинства проектов. В противном случае вы потратите слишком много работы на разработку вещей, которые придется переделывать.
Пара вещей, которые следует запомнить:
Следовательно, если пользователи могут видеть части вашего пользовательского интерфейса, которые вы заинтересованы в тестировании, и взаимодействовать с ними реалистично (например, нажимая кнопки и ссылки), вы сможете собирать полезные данные. Если некоторые ссылки тупиковые, это нормально, если у пользователей есть способ восстановиться и продолжить работу. В принципе, с прототипами «правильный» путь должен работать, но ничего страшного, если неправильные пути не работают (при условии, что есть достаточно быстрый способ вернуться на правильный путь). Даже статические раскадровки (неработающие чертежи пользовательского интерфейса) могут предоставить вам некоторую информацию, если вы зададите правильные вопросы, например: «Что бы вы сделали на этом экране, если бы захотели просмотреть свою корзину покупок?»).
Я бы посоветовал провести пару раундов юзабилити-тестирования. Сначала на бумаге, возможно, позже на экране, как правило, на протяжении всего жизненного цикла приложения (используйте гибкий подход к этому).
Есть хороший аргумент в пользу бумажных прототипов. Когда пользователи видят экран даже с ограниченной функциональностью, они могут не решаться предлагать изменения, поскольку он выглядит «готовым».
Не заблуждайтесь, записать все на бумаге - нетривиально, но я бы начал с этого. Наверное, начнем с одного или двух разделов приложения. И убедитесь, что есть кто-то с хорошими навыками работы с людьми и / или способностями объяснения, чтобы провести пользователя через это. Попросите второго человека делать записи. Попробуйте задавать открытые вопросы и т. Д.
Для теста в коридоре я бы тестировал НИКАКУЮ из реализованных функций.
Проверьте дизайн, сделанный на доске или на бумаге. Вы удивитесь, сколько всего узнаете в этих минималистичных мокапах. И они очень недорогие в изготовлении!
Функциональные прототипы - позже. Если вы дадите своему юзабилити-объекту функциональный интерфейс, у них гораздо меньше шансов усомниться в том, что вы изначально реализовали правильный набор функций.
Я бы сделал UI функциональным, чтобы пользователь действительно мог с ним поиграть, это будет намного лучше, чем статическое изображение. Люди могут сказать вам, чувствуют ли они себя комфортно в пользовательском интерфейсе.
Я бы удостоверился, что все в пользовательском интерфейсе работает или, по крайней мере, приведет вас к четкому, недвусмысленному сообщению, указывающему на то, что эта функция еще не реализована.
Показ прототипов клиентам с заявлением об отказе от ответственности о том, что функция X еще не работает, обычно игнорируется. Они опробуют прототип, нажмут на featuree X и возмущенно ответят: «Feature X не работает! Это действительно должно работать в финальной версии! Почему не работает?». Клиент смущен и недоволен продуктом, и это расстраивает вас, потому что это затмевает положительные отзывы. Кроме того, вы сказали им, что это не сработало, почему они не могут использовать свое воображение, чтобы представить, как это будет работать в окончательной версии?
Сделайте так, чтобы он работал, будь то грубая версия, фиктивные данные или даже простое сообщение, в котором говорится, что «теперь результаты будут отсортированы в алфавитном порядке».
