Определите, что должен делать продукт, прежде чем проектировать, каким образом он это будет делать.

Рассмотрим в качестве примера проектирование инструмента для анализа данных, помогающего руководителю лучше понимать состояние своего бизнеса. Если начать сразу с вопроса «как?», не разобравшись сначала с вопросом «что?», можно предположить, что на выходе этого инструмента должны появляться отчеты. Прийти к такому заключению очень легко: проводя исследование пользователей, вы, вероятно, обратили бы внимание на то, что отчеты являются очень распространенным и популярным решением. Однако обдумав некоторые сценарии и проанализировав действительные требования пользователей, можно прийти к пониманию того, что руководителю на самом деле нужен способ распознавать исключительные ситуации до того, как возникнут проблемы или будет упущена благоприятная возможность, а также способ уяснять проявляющиеся в анализируемых данных тенденции. Отсюда один шаг до осознания того, что просто статичные отчеты – вряд ли лучший вариант удовлетворения таких потребностей. Располагая подобным решением, человек будет вынужден самостоятельно выполнять тяжелую работу по анализу отчетов в поисках значимых данных, указывающих на исключительные ситуации и тенденции. Более качественными решениями были бы такие, которые предоставляют пользователю отчеты, основанные на замеченных исключениях, или же предлагают мониторинг тенденций в реальном времени.

И наконец: такой подход дает максимальную гибкость в условиях постоянно меняющихся технологических возможностей и ограничений. Четко определив, что нужно пользователю, проектировщики могут приступить к поиску лучших решений в сотрудничестве с технологами, не ставя под удар способность продукта помогать людям в достижении их целей.

Из чего черпать требования. У требований может быть несколько источников:

Ø имеющийся опыт персонажей

Ø ментальные модели

Ø анализ сценария идеального использования,

Ø требования бизнеса и технические (из интервью с заинтересованными лицами).

Процесс выработки требований состоит из следующих пяти шагов

1. Постановка задач и определение образа продукта.

2. Мозговой штурм.

3. Выявление ожиданий персонажей.

4. Разработка контекстных сценариев.

5. Выявление требований.

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

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

Совет*Игра в волшебство

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

На ранних стадиях проектирования считайте интерфейс волшебным.

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