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

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

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

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

Самое сложное - держать язык за зубами.

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

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

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

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

Мне нравится ответ Пауля Бухейта на это из школы стартапов. Краткая версия того, что он сказал, слушайте своих пользователей. Слушать не означает подчиняться своим пользователям. Отфильтруйте данные, отфильтруйте все плохие советы и последовательно очищайте сайт. Вспенить, промыть, повторить.

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

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

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

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

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

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

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

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

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

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

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

Из опыта:

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

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

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

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

• внимательно следите за Снейдерманом и Нильсеном этого мира и других, которые могут появиться

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

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

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

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

Эвристическая оценка

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

Проверьте эту статью по Nielsen

Когнитивное прохождение

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

За подробностями обращайтесь к статье это.

Думайте вслух анализ

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

Подробности см. В Эта бумага.

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

Этот связь переносит вас к статье.

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

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

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

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

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

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