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