Как вы тестируете удобство использования ваших пользовательских интерфейсов?
Как вы проверяете удобство использования пользовательских интерфейсов ваших приложений - будь то веб или настольный компьютер? Вы просто складываете все это вместе, а затем настраиваете, основываясь на опыте пользователя, как только приложение будет запущено? Или вы передаете его определенной группе юзабилити для тестирования перед выпуском?
Мы небольшая компания по разработке программного обеспечения, но мне интересны лучшие методы измерения юзабилити.
Любая помощь приветствуется.
11 ответов
Мне нравится ответ Пола Бюхейта на это из стартап-школы. Краткая версия того, что он сказал, слушает ваших пользователей. Слушать не значит подчиняться вашим пользователям. Возьмите в фильтр данных все плохие советы и итеративно очистите сайт. Вспенить, промыть, повторить.
Если вы небольшой магазин, у вас, вероятно, нет команды QA или юзабилити-специалистов или что-то еще, чтобы пройти через сайт. Ваши пользователи будут теми, кто действительно использует сайт. Их отзывы могут быть неоценимы.
Если что-то слишком сложное для использования одним из ваших пользователей или слишком сложное, чтобы понять, почему они должны это использовать, то это может быть так же для 1000 других пользователей. Найдите более простой способ сделать то же самое.
Как только вы соберете все эти отзывы и составите список того, что нужно сделать, сделайте сначала самые простые. Таким образом, вы продвигаете прогресс юзабилити.
Что мне нравится делать, так это дать кому-то пакет установки, попросить его выполнить ряд задач, связанных с работой приложения, и посмотреть.
Самое сложное - держать рот на замке.
Некоторые из лучших советов по юзабилити-тестированию доступны на веб- сайте Якоба Нильсена http://www.useit.com/. Он защищает то, что упомянул Уилл: попросите пользователей выполнить различные задачи на вашем веб-сайте или в веб-приложении, а затем бездельничайте, чтобы посмотреть, что они делают.
Не перебивайте пользователей, задавая вопросы или направляя их. Просто наблюдайте за ними и документируйте их поток. Вы также можете получить аппаратное и программное обеспечение для отслеживания и понимания того, что привлекает внимание пользователей.
Однако удобство использования не должно начинаться с этапа тестирования. У вас должно быть общее представление о том, что пользователям обычно нравится, а что нет, когда вы занимаетесь разработкой. Существует множество веб-сайтов и книг, в которых изложены общепринятые стандарты и принципы юзабилити.
Обычно мы проверяем удобство использования новых интерфейсов, предлагая небольшому кругу пользователей опробовать бета-версию.
Мы даем небольшое количество инструкций относительно того, что должны делать новые функции / экраны, и позволяем им погрузиться прямо в него. Очень интересно посмотреть, где они смотрят и щелкают. Мы никогда не демонстрируем новые функции - мы говорим только о том, что он делает.
Если изменения пользовательского интерфейса минимальны, то они запускаются, и мы собираем отзывы от реальных пользователей. Только когда мы делаем большие изменения, мы проходим тесты юзабилити на бета-версии.
При разработке новых экранов, как правило, чертовски важно, чтобы коллеги сидели перед пользовательским интерфейсом и спрашивали их, что он делает. В каких областях они нажимают? Куда они смотрят первыми? Какие разделы привлекают их внимание? и т.п.
Я согласен с Адамом; использование очень компьютерного неграмотного человека очень полезно. Однако то, с чем я столкнулся раньше с этой программой, это программа, которую я хочу, чтобы они попробовали, просто не "в тупике", а то, что они когда-либо хотели бы сделать.
Хороший способ начать с бумажного прототипа. Есть конкретные задачи, которые вы хотите, чтобы ваш "пользователь" выполнял, и пусть они это делают. Для больше на бумажном прототипе, начните здесь.
Есть много способов проверить удобство использования системы. Пожалуйста, проверьте любую доступную литературу, которую вы можете найти. Я просто хочу настаивать на том, что юзабилити-тест не так сложен, как вы или кто-либо может подумать. В известной статье под названием "Математическая модель нахождения проблем юзабилити" в INTERACT'93 и CHI'93 Дж. Нильсен и Т. К. Ландауэр показали, что для обнаружения большинства проблем в небольшой системе достаточно всего пяти пользователей.
Если у вас нет возможности прочитать эту статью, попробуйте эту статью на веб-сайте автора: http://www.useit.com/alertbox/20000319.html
Существует ряд методов для проверки или оценки юзабилити приложения. Разбиты на качественные и количественные методы и основаны на том, когда вы планируете тестировать.
Кроме того, он классифицируется в зависимости от того, участвуют ли пользователи или эксперты проводят тестирование.
Чтобы назвать несколько методов,
- Обзоры экспертов - пользовательский интерфейс или юзабилити эксперты оценивают юзабилити интерфейса на основе определенных эвристик и принципов
- Формирующее юзабилити-тестирование - выполняются потоки задач, и пользователям предоставляются задачи для выполнения. Качественная обратная связь собирается на основе того, что пользователи чувствуют болевые точки во время тестирования. Эта форма тестирования выполняется во время разработки, чтобы обеспечить обратную связь с разработчиком приложения.
- Итоговое юзабилити-тестирование - выполняются потоки задач, и пользователям предоставляются задачи для выполнения. Производительность приложений по эффективности, результативности и удовлетворенности измеряется на основе выполнения пользователями задач.
Разница в важности заключается в том, привлекаете ли вы пользователя или эксперта, чтобы сказать вам разницу в удобстве использования. Далее, когда вы делаете оценку - в конце проекта или на этапе проектирования.
Поскольку проверка юзабилити идет, есть несколько жизнеспособных методов. Они требуют различного количества ресурсов в отношении людей, анализа и оборудования.
Самый распространенный и самый простой для выполнения называется
Эвристическая оценка
Вы в основном проходите через каждый экран, чтобы проверить, соответствует ли он эвристике, установленной вами или вашим клиентом.
Проверьте эту статью Nielsen
Когнитивное прохождение
Этот метод требует, чтобы вы попросили пользователя выполнить шаги в приложении. Вы готовите шаги для пользователя. Проблемы, возникающие во время этого пошагового руководства, учитываются при завершении приложения.
Проверьте эту бумагу для деталей.
Думай вслух Анализ
Я использовал этот метод в основном на ранних стадиях прототипирования. Я позволяю пользователю свободно говорить о системе, пока она используется. Задавайте вопросы об использовании, дизайне и т. Д. Вы можете получить действительно хорошее представление об общих чертах системы и о том, какие функции отсутствуют.
Проверьте эту бумагу для деталей.
Анализ взаимодействия Это более сложный анализ. Я использовал только технику сбора данных, предложенную этим. Этот метод учитывает контекст, активность, язык тела и т. Д. Анализ взаимодействия обычно сосредоточен на исследованиях, а не на коммерческих оценках.
Эта ссылка приведет вас к статье.
Имейте в виду, что эти методы совершенствуются на практике. Я бы начал с HE, продолжал CW и THA. И используйте анализ взаимодействия, только если у вас много ресурсов и времени.
Прошло немного времени с тех пор, как этот вопрос был последним активным, но все равно идет.
Из опыта:
- Всегда используйте Объективно измеримый, чтобы решить, лучше ли юзабилити или нет (время для выполнения тщательно отобранной задачи, неактивное время, метрики типа KLM), здесь регистратор нажатий клавиш может быть ценным союзником
- Никогда не заходите слишком далеко, прежде чем снова проконсультироваться и провести измерения с вашим клиентом (не зацикливайтесь на бумажном прототипе и не получайте готовый продукт... который просто никогда не работает)
- читать, читать, читать, пробовать, развиваться
- Сохраняйте вещи простыми и всегда помните задачу, которая была у пользователя (зачем пользователю нужен интерфейс)
- тестируй, тестируй и тестируй снова...
- Всегда переходите к нижней части пользовательских запросов. Хотя флажок пользовательский запрос в данном конкретном месте может быть лучшим, он почти всегда скрывает более существенный недостаток
- пользователь системы (тот, кто его использует... в отличие от того, кто за него платит) - ваш лучший союзник, держите его / ее на своей стороне
Никогда не бойтесь рефакторинга вашего дизайна и развития вашей системы. Также развивайте свои метрики и измерения, но будьте осторожны, чтобы не нарушить непрерывность измерений, поскольку это лучший знак объективного прогресса в ОЧЕНЬ субъективном мире.
Рекомендуемое чтение (кроме ранее предложенного):
Справочник по юзабилити-тестированию Джеффа Рубина. Немного экстремально, но мы разобрались с гибкой версией его подхода и обнаружили, что, если мы проводим 30 минут в неделю с пользователями, мы получим ОЧЕНЬ много полезных отзывов, но при этом не будем завалены слишком большой информацией.
внимательно следите за Снейдерманом и Нильсеном этого мира и других, которые могут возникнуть
Я часто передаю любой новый интерфейс, над которым работаю, одному из наших сотрудников службы технической поддержки. Они слышали каждую жалобу об интерфейсах, которую вы когда-либо могли себе представить, поэтому, если кто-нибудь собирается придумать потенциальные проблемы, они это сделают.
Кроме того, и я не шучу об этом, я часто беру наименее грамотного человека из всех, кого я знаю (твоя мать часто хороший выбор... но они должны были использовать компьютер раньше, иначе это будет бессмысленно) и дайте им потеряться на интерфейсе без инструкции. Если они не могут понять, где все находится интуитивно, то ваш GUI, вероятно, нуждается в работе. Помните, не заставляйте их думать! (да, я знаю, что это для веб-дизайна, но это относится)
Я твердо верю в то, что я называю тестированием юзабилити 3-мартини. При проектировании системы представьте, что у человека, который будет ее использовать, только что было 3 мартини.
Прежде чем передать систему коллегам (другим программистам, специалистам по обеспечению качества, технической поддержке) или юзабилити-тестерам, неофициальный тест с парой друзей и бутылкой водки (вне работы, конечно) может оказаться поучительным.