Использование основных приложений для создания пользовательского интерфейса

Question

Я прошу нового проекта (о, как я люблю свежий вкус нового проекта!), И мы только начинаем его разрабатывать. Вкратце: приложение представляет собой пользовательский интерфейс, который позволит пользователям моделировать поток выполнения (интерфейс Visio, такой как drag &). Поэтому наша самая большая проблема - удобство и функции, которые помогут пользователям быстро и четко исполнять поток выполнения.

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

Однако, используйте случаи have a number of flaws, большинство из которых связано с тем, что они включают технические детали, такие как пользовательский интерфейс и т. Д., Как может показаться here. Но, поскольку мы не можем использовать Истории пользователей и полностью интерактивный дизайн, я решил, что мы скомпрометируем: я буду использовать Случаи использования основных средств, чтобы скрыть эти детали.

Теперь у меня есть еще одна проблема: важно (не каламбур) иметь четкое описание взаимодействия с пользовательским интерфейсом, так как я должен его документировать? Другими словами, Как указать приложение с помощью приложений Essential Use Cases, в которых взаимодействие UI жизненно важно для него?

Я вижу несколько вариантов:

• ABANDON использования Use Cases, так как они не правильно представляют проблему
• Не включать описание интерфейса в случае использования, но создать другую документацию (Story Boards), а затем ссылку на основные случаи использования
• Включить описание взаимодействия с пользовательским интерфейсом в Случае основного использования, поскольку они являются частью бизнес-правил в перспективе пользователей и самого приложения

Answer 1

Получение отзывов пользователей с помощью прототипов пользовательского интерфейса имеет важное значение для создания пользовательского интерфейса, которое ваше сообщество пользователей будет понимать и быть продуктивным. Лучший способ сделать это IMO - paper prototyping. Ваши варианты использования могут привести к первоначальному созданию этих прототипов, а сеансы взаимодействия с вашими клиентами могут улучшить дизайн пользовательского интерфейса.

Если вы предпочитаете электронные прототипы, вы можете использовать что-то вроде 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

Answer 2

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

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

Когда дизайн пользовательского интерфейса достаточно хорош (~ 85% готовы - некоторые мелкие детали лучше всего подстраиваются после реализации), вы можете документировать его, например, с помощью последовательности изображений прототипа, которые показывают, как можно использовать варианты использования с системой. Но общение с дизайнером пользовательского интерфейса с программистами лучше всего сделать лицом к лицу, показывая вручную, как работает прототип и отвечает на их вопросы. Не просто «бросьте документацию через стену», но проследите, как она реализована, и проверьте, соответствует ли реализация тем, что было разработано.

Смотрите более подробное описание процесса на http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe.pdf