Тестирование удобства пользования прихожей: Сколько из UI Вы на самом деле делаете функциональными?
Otto сделал хорошее предложение . Это работает на Debian также, а также любую другую производную Debian. Недостающая часть - то, что сделать, когда поиск способного кэша не находит что-то.
$ sudo apt-get install dh-make-perl build-essential apt-file
$ sudo apt-file update
Тогда каждый раз, когда у Вас есть случайный модуль, Вы хотите установить:
$ cd ~/some/path
$ dh-make-perl --build --cpan Some::Random::Module
$ sudo dpkg -i libsome-random-module-perl-0.01-1_i386.deb
Это даст Вам deb пакет, который можно установить для получения Некоторых:: Случайный:: Модуль. Одно из больших преимуществ здесь является страницами справочника, и демонстрационные сценарии в дополнение к самому модулю будут помещены в предпочтительное местоположение Вашего дистрибутива. Если дистрибутив когда-нибудь выпускает официальный пакет для более новой версии Некоторых:: Случайный:: Модуль, это будет автоматически установлено, когда Вы склонный - получите обновление.
6 ответов
Для юзабилити-тестов, проходных или других, нужны только те функции, которые вам нужно протестировать. В большинстве тестов юзабилити вам следует ответить на конкретных вопросов дизайна, чтобы ответить на и разработать свой прототип до такой степени, чтобы он мог ответить на эти вопросы. Например, если вам нужно проверить, понимают ли пользователи ваше указание порядка сортировки для таблицы, все, что вам нужно, это бумажное изображение таблицы с указанием сортировки (с размытым содержимым) и спросить их, как сортируется таблица. . Если вам нужно протестировать IA , все, что вам нужно, - это связка пустых веб-страниц, за исключением заголовка, которые связаны через меню навигации.
Вам нужны только те страницы, которые соответствуют задачам, которые вы даете своим пользователям. Если вы просто тестируете IA, тогда вам нужны только страницы нормативного пути. Если вы также тестируете восстановление после ошибок, вам понадобятся страницы вне нормативного пути вместе с полными элементами управления навигацией. Если вы также тестируете обнаружение ошибок, вам также понадобится контент на страницах.
Вы также можете моделировать функциональность, когда это проще сделать. Например, при тестировании, могут ли пользователи выяснить, как получить желаемый порядок сортировки, когда пользователь нажимает на нефункционирующий элемент управления для сортировки таблицы, вы можете сказать: «Хорошо, это даст вам это», и вы возьмите мышь и выберите закладку, которая показывает таблицу в новом порядке сортировки.
При тестировании в коридоре, если пользователи нарушают конверт точности, вы можете просто сказать: «Я еще не сделал эту часть. Вернемся к А и продолжим оттуда ». Конечно, Обратите внимание, что пользователь ошибся в поставленной вами задаче. У меня не было проблем с пользователями, жаловавшимися на нефункциональные функции, когда я заранее говорил им, что это неполный прототип, и на данный момент мы тестируем пользовательский интерфейс только для функций x, y и z.
Для прототипов с низкой точностью я часто называю их «мокапами» или «чертежами» для пользователей, а не «прототипами», чтобы указать на низкую функциональность. Вы можете вставить очевидные заполнители для отсутствующего содержимого (например, «Бла, бла, бла…», «TODO: Изображение продукта здесь»). Если пользователь комментирует что-то за пределами диапазона точности (например, «Этот символ должен быть красным, чтобы выделяться больше»), просто отметьте это и скажите, что эта тема находится в стадии разработки (например, «Спасибо. Мы еще не начали работу над цветов пока нет. Мы просто пытаемся понять, как организовать сайт прямо сейчас. »).
Юзабилити-тестирование с прототипами с ограниченной точностью действительно необходимо для того, чтобы итеративный дизайн был осуществим для большинства проектов. В противном случае вы потратите слишком много времени на разработку вещей, которые придется переделывать.
Пара вещей, которые следует запомнить:
- Тестируйте раньше и чаще.
- юзабилити-тестирование заключается в поиске проблем с пользовательским интерфейсом , а не с вопросами / ответами вашего кода.
Следовательно, если пользователи могут видеть части вашего пользовательского интерфейса, которые вы заинтересованы в тестировании, и взаимодействовать с ними реалистично (например, нажимая кнопки и ссылки), вы сможете собирать полезные данные. Если некоторые ссылки тупиковые, это нормально, если у пользователей есть способ восстановиться и продолжить работу. В принципе, с прототипами «правильный» путь должен работать, но ничего страшного, если неправильные пути не работают (при условии, что есть достаточно быстрый способ вернуться на правильный путь).
Я бы предложил пару раундов юзабилити-тестирования. Сначала на бумаге, возможно, позже на экране, как правило, на протяжении всего жизненного цикла приложения (используйте гибкий подход к этому).
Есть хороший аргумент в пользу бумажных прототипов. Когда пользователи видят экран, даже с ограниченной функциональностью, они могут не решаться предложить изменения, поскольку он выглядит «готовым».
Не заблуждайтесь, записать все это на бумаге нетривиально, но я бы начал с этого. Наверное, начнем с одного или двух разделов приложения. И убедитесь, что кто-то с хорошими навыками работы с людьми и / или объяснениями присутствует, чтобы провести пользователя через это. Попросите второго человека делать заметки. Попробуйте задавать открытые вопросы и т. Д.
Я бы сделал UI функциональным, чтобы пользователь мог реально с ним поиграть, это будет намного лучше, чем статическое изображение. Люди могут сказать вам, комфортно ли они себя чувствуют, с помощью пользовательского интерфейса.
, я бы убедился, что все в пользовательском интерфейсе работает, или, по крайней мере, приведет вас к четкому, недвусмысленному сообщению, указывающему на то, что функция еще не реализована .
Показ прототипов клиентам с заявлением об отказе от ответственности о том, как функция X еще не работает, обычно игнорируется. Они попробуют прототип, нажмут на Featuree X и возмущенно ответят " Функция X не работает! Это действительно должно работать в финальной версии! Почему это не работает? ». Клиент смущен и недоволен продуктом, и это разочаровывает себя, потому что затмевает положительные отзывы. Кроме того, вы сказали им, что это не сработало , почему это можно «Разве они не используют свое воображение, чтобы представить, как это будет работать в окончательной версии?
Заставить это работать, будь то грубая версия, фиктивные данные или даже простое сообщение, в котором говорится:« Теперь результаты будут отсортированы в алфавитном порядке ».
Для теста в коридоре я бы тестировал НИКАКОЙ из реализованных функций.
Тестирование по рисункам, выполненным на доске или на бумаге. Вы будете удивлены, узнав много нового в этих минималистичных мокапах. И их изготовление очень недорого!
Функциональные прототипы - на потом. Если вы дадите своему юзабилити-объекту функциональный интерфейс, у них гораздо меньше шансов усомниться в том, что вы изначально реализовали правильный набор функций.