Как вы оцениваете, если изменение интерфейса улучшило или уменьшило удобство использования?

Question

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

Answer 1

Многофакторное тестирование и отчетность - отличный способ реально измерить подобные вещи.

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

Google Web Optimizer поддерживает это.

Answer 2

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

• Количество действий, необходимых для выполнения сценария, меньше? (Если да, то это улучшилось). Измерение: число шагов уменьшено / добавлено.

• Уменьшает ли изменение количество видов используемых устройств ввода (даже если число шагов одинаково)? Под этим я подразумеваю, что если вы возьмете что-то, опирающееся как на мышь, так и на клавиатуру, и измените его на использование только для мыши или только на клавиатуре, то вы повысите удобство использования. Измерение: изменение количества используемых устройств.

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

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

Как только вы получите эти приблизительные значения для улучшения работы пользователя, а затем соберете более долгосрочные данные, вы сможете увидеть, есть ли какая-либо прогнозирующая способность для улучшения удобства использования на уровне проекта для реакции конечного пользователя (например, за последние 10 проектов). мы видели в среднем на 1% более быстрые сценарии для каждого удаленного действия (диапазон 0,25% и стандартное отклонение 0,32%).

Answer 3

Подобные методы, которые вы использовали для определения проблем с юзабилити для начала - юзабилити-тестирование. Обычно вы определяете свои варианты использования, а затем проводите лабораторное исследование, оценивающее, как пользователи выполняют определенные задачи. Лабораторные тесты обычно хороши для 8-10 человек.

Более подробная методология, которую мы приняли, чтобы понять наших пользователей, заключается в том, чтобы собирать анонимные данные (вам может потребоваться разрешение пользователя, прояснить политику конфиденциальности и т. Д.) пользователи что-то удаляют (т.е. меняют количество - больше пользователей вводят 0 и обновляют количество или нажимают X)? Это немного сложнее в настройке; Вы должны разработать инфраструктуру для хранения этих данных (которая на самом деле является просто счетчиками, т. е. "Times нажал x: 138838383, Times ввели 0: 390393") и позволяет создавать точки данных, необходимые для подключения к проекту.

Answer 4

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

Кроме того, если есть способ записать количество отмен, это также сработает.

Answer 5

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

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

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