Как измерить удобство использования в документе с техническими требованиями?

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

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

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

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


person cwap    schedule 27.02.2009    source источник


Ответы (3)


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

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

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

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

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

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

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

person Theo Lenndorff    schedule 27.02.2009
comment
Я ненавижу, когда я задаю вопрос, а кто-то отвечает чем-то, что звучит настолько просто, что заставляет меня выглядеть глупо - думаю, это просто означает, что это отличный ответ :) Тай - person cwap; 28.02.2009
comment
Я как раз выдумывал твой ответ в твоей голове ;-) - person Theo Lenndorff; 28.02.2009
comment
ИМО, это только половина ответа. Если у вас есть эти функциональные требования, как вы тестируете нефункциональные требования? К этому ответу обращается Аарон Маенпаа, который предложил тесты на удобство использования. - person Thomas Owens; 01.07.2009

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

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

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

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

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

person Aaron Maenpaa    schedule 27.02.2009
comment
Использовать друзей - плохая идея. Ваши тестировщики должны попадать в целевую аудиторию. Но общая идея верна - тесты юзабилити можно использовать для выявления проблем с пользовательским интерфейсом. - person Thomas Owens; 01.07.2009
comment
@Thomas Я предлагаю использовать своих друзей, потому что, будучи студентом, вы не собираетесь найти кого-либо еще за время курса и с нулевым бюджетом. В реальности есть кто-то, кто угодно, кроме разработчиков сесть и попытаться использовать систему, которую вы разрабатываете, так намного лучше, чем не делать этого, даже если у вас нет денег и времени, вам нужно попробовать и приспособить ее. - person Aaron Maenpaa; 01.07.2009

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

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

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

person cdonner    schedule 27.02.2009