Как измерить «удобство использования» в документе с требованиями спецификации? - PullRequest
1 голос
/ 28 февраля 2009

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

Наши учителя всегда проповедовали, что любое требование, предъявляемое к проекту, должно быть «способным к тестированию», но как вы проверяете, насколько легко доступен ваш пользовательский интерфейс?

Скажем, у меня запущено приложение в реальном времени. Здесь нетрудно сказать, что «запись должна быть удалена менее чем через 100 мс после первоначального вызова». Но гораздо сложнее сказать: «Интерфейс пользователя должен быть интуитивно понятен на 86%».

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

Ответы [ 3 ]

2 голосов
/ 28 февраля 2009

... как проверить, насколько легко доступен ваш пользовательский интерфейс?

С юзабилити-тестами.

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

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

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

1 голос
/ 28 февраля 2009

Попробуйте определить юзабилити в терминах «тестируемых» требований.

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

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

Может быть, вы получите список функций, таких как:

  • Организация отдела должна быть показано в иерархическом древовидном представлении.
  • В этом древовидном представлении перетаскивание должно быть возможно.
  • Размер шрифта должен быть настраивается и сохраняется для каждого пользователя.
  • В верхней части экрана должно быть быть список важных ссылок. каждый Пользователь может настроить и сохранить свой собственный личный список.
  • ...

Установите требования из этих функций. Они «проверяемы» и, следовательно, «измеримы». Если в приемочных тестах выясняется, что 17 из 20 функций работают, у вас 85% успеха.

РЕДАКТИРОВАТЬ: Это работает в проектной среде, где вам нужно проводить измерения (как во многих коммерческих проектах). Если у вас есть «более мягкая» форма проектной среды, в которой не все подсматривают цифры, то слишком частое использование этого формализма может привести к обратным результатам, поскольку от этого могут пострадать гибкость и ловкость.

0 голосов
/ 28 февраля 2009

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

  • Чтобы найти y на сайте, человеку не больше x секунд, или
  • коэффициент конверсии магазина должен быть выше, чем z%
  • и т. Д. И т. П.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...