Варианты использования (use case) и сценарии использования (usage scenarios) как основа для проектирования графического интерфейса пользователя (graphical user interface, GUI)
Поскольку понимание потребностей пользователей (User Centered Design philosophy) позволяет разрабатывать более удобные, востребованные и эффективные программные продукты (а следовательно, ведёт к всеобщему счастью и удовлетворённости =), необходимо найти инструменты, позволяющие эффективно извлекать и обрабатывать информацию о требованиях пользователей.
В свете вышесказанного предлагаю обсудить такие методы, как Варианты использования и Сценарии использования (Use case and Usage scenarios). Вышеназванные методологии отлично зарекомендовали себя (Karl E. Wiegers, 2004), в их эффективности и чрезвычайной пользе я убедился на собственном опыте.
Предупреждение!
Для того, чтобы достичь валидности вариантов и сценариев использования необходимо проводить регулярные уточняющие сессии с представителями пользователей продукта. Сценарии использования являются оптимальным инструментом для извлечения и обработки уточняющей информации о требованиях, но их использование как единственного инструмента для извлечения пользовательских требований сопряжено с риском. Важно понимать, что обсуждаемые методологии являются средством моделирования, которое, в свою очередь, должно быть основано на реальных фактах.
На сегодняшний день я вижу два взаимодополняющих (но не альтернативных) способа формализации вариантов использования:
a) используя семантику UML, и
b) в текстовом виде.
Первый способ позволяет кратко описать систему или частный вариант использования на концептуальном уровне. Второй способ позволяет произвести низкоуровневое описание, и, что самое главное, более понятен неподготовленным представителям пользователей, и заказчику продукта. Оба способа имеют преимущества и недостатки и обладают способностью синергетически дополнять друг друга.
Мои комментарии с точки зрения проектировщика
1. Сам факт описания алгоритма взаимодействия пользователей с системой расширяет сознание, происходит эффект «влезания в шкуру пользователя», я увидел целую уйму возможностей усовершенствовать интерфейс.
2. Увеличился уровень «целостности» документации, появилось приятное ощущение порядка, когда ты знаешь почему такая-то фича обязательно должна быть именно в этом месте и какой акцент следует ей придать.
3. Будьте готовы к тому, что в ходе формализации текстового описания возникнут сложности с разметкой, таблицами, формулировками и терминологией, у меня на их преодоление ушёл примерно день.
Мои впечатления с точки зрения руководителя проекта
1. Всплыли забытые экраны (wireframes), которые необходимо описать (а это позволило оптимальнее спланировать ход реализации проекта и избежать лишних итераций).
2. Использование данных методологий требует временных и ресурсных затрат, но в итоге окупается сторицей:
— качество продукта повышается в разы;
— уровень удовлетворённости заказчика также заметно возрастает;
— проект становится более прогнозируемым и управляемым (случается гораздо меньше «потерь» функциональности и элементов интерфейса);
— появляется дополнительная аргументация, которая может потребоваться в ходе проведения презентаций wireframes, дизайна UI и продукта в целом.
Более подробно о моей точке зрения и практическом опыте применения описываемых методик я расскажу в следующих публикациях.
В User Experience Russia велось интересное обсуждение, можете продолжить.
Также буду рад увидеть Ваши комментарии.
Поскольку понимание потребностей пользователей (User Centered Design philosophy) позволяет разрабатывать более удобные, востребованные и эффективные программные продукты (а следовательно, ведёт к всеобщему счастью и удовлетворённости =), необходимо найти инструменты, позволяющие эффективно извлекать и обрабатывать информацию о требованиях пользователей.
В свете вышесказанного предлагаю обсудить такие методы, как Варианты использования и Сценарии использования (Use case and Usage scenarios). Вышеназванные методологии отлично зарекомендовали себя (Karl E. Wiegers, 2004), в их эффективности и чрезвычайной пользе я убедился на собственном опыте.
Предупреждение!
Для того, чтобы достичь валидности вариантов и сценариев использования необходимо проводить регулярные уточняющие сессии с представителями пользователей продукта. Сценарии использования являются оптимальным инструментом для извлечения и обработки уточняющей информации о требованиях, но их использование как единственного инструмента для извлечения пользовательских требований сопряжено с риском. Важно понимать, что обсуждаемые методологии являются средством моделирования, которое, в свою очередь, должно быть основано на реальных фактах.
На сегодняшний день я вижу два взаимодополняющих (но не альтернативных) способа формализации вариантов использования:
a) используя семантику UML, и
b) в текстовом виде.
Первый способ позволяет кратко описать систему или частный вариант использования на концептуальном уровне. Второй способ позволяет произвести низкоуровневое описание, и, что самое главное, более понятен неподготовленным представителям пользователей, и заказчику продукта. Оба способа имеют преимущества и недостатки и обладают способностью синергетически дополнять друг друга.
Мои комментарии с точки зрения проектировщика
1. Сам факт описания алгоритма взаимодействия пользователей с системой расширяет сознание, происходит эффект «влезания в шкуру пользователя», я увидел целую уйму возможностей усовершенствовать интерфейс.
2. Увеличился уровень «целостности» документации, появилось приятное ощущение порядка, когда ты знаешь почему такая-то фича обязательно должна быть именно в этом месте и какой акцент следует ей придать.
3. Будьте готовы к тому, что в ходе формализации текстового описания возникнут сложности с разметкой, таблицами, формулировками и терминологией, у меня на их преодоление ушёл примерно день.
Мои впечатления с точки зрения руководителя проекта
1. Всплыли забытые экраны (wireframes), которые необходимо описать (а это позволило оптимальнее спланировать ход реализации проекта и избежать лишних итераций).
2. Использование данных методологий требует временных и ресурсных затрат, но в итоге окупается сторицей:
— качество продукта повышается в разы;
— уровень удовлетворённости заказчика также заметно возрастает;
— проект становится более прогнозируемым и управляемым (случается гораздо меньше «потерь» функциональности и элементов интерфейса);
— появляется дополнительная аргументация, которая может потребоваться в ходе проведения презентаций wireframes, дизайна UI и продукта в целом.
Более подробно о моей точке зрения и практическом опыте применения описываемых методик я расскажу в следующих публикациях.
В User Experience Russia велось интересное обсуждение, можете продолжить.
Также буду рад увидеть Ваши комментарии.
