Использование основных сценариев использования для разработки ориентированного на пользовательский интерфейс приложения
Я прошу новый проект (о, как мне нравится свежий вкус нового проекта!), И мы только начинаем его проектировать. Вкратце: приложение представляет собой пользовательский интерфейс, который позволит пользователям моделировать поток выполнения (интерфейс перетаскивания в стиле Visio). Поэтому нашей главной заботой являются удобство использования и функции, которые помогут пользователям быстро и четко моделировать поток выполнения.
Наша установленная методология широко использует варианты использования для того, чтобы создать гармоничное представление о приложении между программистами и пользователями. На самом деле это деловая проблема: я бы предпочел использовать Agile-метод с пользовательскими историями, а не с пользовательскими примерами, но нам нужно определить четкие рамки для продажи продукта нашим клиентам.
Тем не менее, варианты использования имеют ряд недостатков, большинство из которых связаны с тем, что они включают технические детали, такие как пользовательский интерфейс и т. Д., Как это может показаться здесь. Но поскольку мы не можем использовать пользовательские истории и полностью интерактивный дизайн, я решил пойти на компромисс: я буду использовать основные сценарии использования, чтобы скрыть эти детали.
Теперь у меня есть еще одна проблема: важно (без каламбура) иметь четкое описание взаимодействия с пользовательским интерфейсом, так как я должен это документировать? Другими словами, как мне указать приложение с помощью основных сценариев использования, где взаимодействие с пользовательским интерфейсом жизненно важно для него?
Я вижу несколько альтернатив:
- Откажитесь от использования вариантов использования, поскольку они неправильно представляют проблему
- Не включайте описания интерфейсов в сценарий использования, но создайте другую документацию (Доски рассказов) и свяжите их тогда с Основными сценариями использования
- Включите описание взаимодействия с пользовательским интерфейсом в основные сценарии использования, поскольку они являются частью бизнес-правил с точки зрения пользователей и самого приложения.
2 ответа
Получение отзывов пользователей с помощью прототипов пользовательского интерфейса важно для создания пользовательского интерфейса, с которым ваше пользовательское сообщество будет понимать и работать с ним. Лучший способ сделать это ИМО с бумажным прототипом. Ваши варианты использования могут инициировать первоначальное создание этих прототипов, а сеансы взаимодействия с клиентами с вашими клиентами могут улучшить дизайн пользовательского интерфейса.
Если вы предпочитаете электронные прототипы, вы можете использовать что-то вроде PowerPoint для их быстрого прототипирования.
Также смотрите http://www.codinghorror.com/blog/2008/04/ui-first-software-development.html и http://www.codinghorror.com/blog/2007/01/low-fi-usability-testing.html
Сначала соберите информацию о рабочих процессах и целях пользователей. Лучше всего это сделать, физически посмотрев, как пользователи выполняют свою работу сегодня (например, с помощью контекстного запроса). Документируйте эти цели как варианты использования на основе целей (см. Ссылку ниже), которые содержат только цель - они не должны содержать каких-либо подробностей о том, как будет использоваться система, потому что эти детали - это то, что мы только начинаем разрабатывать на основе случаи применения.
На основе сценариев использования создайте быстрый бумажный прототип пользовательского интерфейса и попробуйте пошагово узнать, как пользователи смогут достичь своих целей с помощью прототипированной системы. Если варианты использования не могут быть выполнены достаточно хорошо с помощью прототипа пользовательского интерфейса, продолжайте улучшать его, пока не будут поддержаны все варианты использования. Покажите прототип пользователям и используйте юзабилити-тестирование и другие методы для выявления проблем с пользовательским интерфейсом.
Когда дизайн пользовательского интерфейса достаточно хорош (~85% готов - некоторые тонкие детали лучше всего настраивать после реализации), вы можете задокументировать это, например, взяв последовательности изображений прототипа, которые показывают, как варианты использования могут быть выполнены с системой. Но лучше донести информацию о дизайне пользовательского интерфейса до программистов, показав вручную, как работает прототип, и ответив на их вопросы. Не просто "перебросьте документацию через стену", но проследите, как она реализована, и проверьте, соответствует ли реализация тому, что было разработано.
Более подробное описание процесса см. На http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe.pdf