Как проверить удобство использования пользовательских интерфейсов

Что мне нравится делать, это дать кому-то пакет установки, попросить их выполнить ряд задач, связанных с тем, как работает приложение, и смотреть.

самое сложное - держать рот на замке.

некоторые из лучших советов по тестированию юзабилити доступны на веб-сайте Якоба Нильсена http://www.useit.com. Он выступает за то, что будет упомянуто - попросите пользователей выполнять различные задачи на вашем сайте или веб-приложении, а затем откиньтесь назад, чтобы посмотреть, что они делают.

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

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

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

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

Если изменения в интерфейсе минимальны, то они идут в прямом эфире и мы собираем отзывы реальный пользователь. Только когда мы вносим большие изменения, мы проходим тесты юзабилити на бета-версии.

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

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

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

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

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

есть много способов проверить удобство использования системы. Пожалуйста, проверьте любую доступную литературу, которую вы можете найти. Я просто хочу настоять на том, что юзабилити-тест не так сложен, как вы или кто-то может подумать. В известной работе под названием "математическая модель поиска проблем юзабилити" в INTERACT'93 и CHI'93, J. Нильсен и т. к. Ландауэр показали, что только пяти пользователей достаточно, чтобы найти большинство проблем в небольшой системе.

Если у вас нет возможности прочитать эту статью, попробуйте эту статью на сайте автора : http://www.useit.com/alertbox/20000319.html

Z'been некоторое время, так как этот вопрос был последним активным, но здесь все равно.

из опыта :

• всегда используйте объективно измеримые, чтобы решить, является ли удобство использования лучше или нет (время для выполнения тщательно выбранной задачи, неактивное время, метрики типа KLM) здесь ключ-мышь регистратор может быть ценным союзником
• никогда не заходите слишком далеко перед консультацией и измерением снова с вашим клиентом (не заключайте себя в бумажный прототип и не появляйтесь с готового продукта... это просто никогда не работает)
• читать, читать, читать, пробовать, развиваться
• держите вещи простыми и всегда помните задачу в had (почему пользователю нужен интерфейс)
• тест, тест и еще раз тест...
• всегда переходите к нижней части запросов пользователя. Хотя флажок запрос пользователя в этом конкретном месте может быть лучшим, он почти всегда скрывает более фундаментальный недостаток
• пользователь системы (с помощью он... в отличие от того, кто платит за это) - ваш лучший союзник, держите его на своей стороне

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

рекомендуемое чтение (кроме ранее предложенных):

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

• внимательно следите за Sneiderman и Nielsen этого мира и других, которые могут arrise

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

самый распространенный и простой в исполнении называется

Оценка

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

в этой статье by Нильсен!--12-->

когнитивное пошаговое руководство

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

Регистрация этой бумага для деталей.

Думай Вслух Анализ

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

Регистрация этой статье для сведения.

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

этой ссылке приведет вас к статье.

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

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

далее он классифицируется на основе того, участвуют ли пользователи или эксперты проводят тестирование.

чтобы назвать несколько методов,

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

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

Я твердо верю в то, что я называю 3-мартини юзабилити-тестирование. При проектировании системы представьте, что человек, который будет ее использовать, только что выпил 3 мартини.

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