Основы проектирования: сценарии и требования

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

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

Сценарии: повествование как средство проектирования

Повествование, или рассказывание историй, - один из древнейших видов деятельности человека. О силе повествования как средства передачи

Сценарии: повествование как средство проектирования

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

Нас окружают свидетельства эффективности повествования как средства проектирования. Знаменитые инженеры-затейники студии Disney¹ не знали бы, что делать, не будь у них современных мифов, которые они используют в качестве основы создаваемого опыта. Об этой идее писали многие: Бренда Лорел (Brenda Laurel) исследовала идею структурирования взаимодействия посредством театральных техник в своей книге «Computers as Theater» (Laurel, 1991), где призывала «...сосредоточиться на проектировании действий. Проектирование объектов, среды и ролей второстепенно в сравнении с этой главной целью». Джон Рейнфранк (John Rheinfrank) и Шелли Ивенсон (Shelley Even-son) также говорили об огромной пользе «историй о будущем» для разработки концептуально сложных интерактивных систем (Rheinfrank and Evenson, 1996), а из-под пера Джона Кэрролла (John Carroll) вышло значительное количество работ, посвященных сценарному проектированию, которое мы обсудим далее в этой главе.

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

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

Walt Disney Imagineering - отделение студии Disney, создающее диснеевские парки аттракционов, курорты, отели, аквапарки, круизные корабли и т. п. Несмотря на «инженерное» происхождение слова imagineer среди затейников есть и художники, и дизайнеры, и писатели. - Примеч. перев.

148 Глава 6. Основы п роектирования: сценарии и требования

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

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

Сценарии проектирования

В девяностые годы сообществом HCI (Human-Computer Interaction -взаимодействие человека и компьютера) была проделана значительная работа в области проектирования программ, ориентированных на варианты использования. Здесь находятся истоки понятия сценария, которое широко используется как указание на метод решения задач проектирования через конкретизацию - использование специально составленного рассказа, чтобы одновременно конструировать и иллюстрировать проектные решения. Джон Кэрролл пишет об этих идеях в своей книге «Making Use» (Carroll, 2000):

Парадоксально, но сценарии одновременно и конкретны, и приблизительны, и осязаемы, и гибки <...> они неявным образом поощряют все стороны мыслить в стиле «А что, если?..» Они позволяют определять рамки возможностей проектировщиков, не препятствуя инновациям. <...> Сценарии привлекают внимание к тому, как будет использоваться проектируемый продукт. Они могут описывать ситуации с разной степенью детализации, с различными целями, способствуя координации различных аспектов проектирования.

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

• Действующее лицо как абстрактная, ролеориентированная модель в представлении Кэрролла недостаточно конкретно, чтобы обеспечить понимание пользователей или вызвать эмпатию по отноше-

Сценарии: повествование как средство проектирования 149

нию к ним. Невозможно адекватно спроектировать поведение системы, не имея подробного знания о пользователях системы.

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

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

Использование персонажей в сценариях

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

Сценарии способны фиксировать ход невербального диалога (Buxton, 1990) между пользователем и продуктом, средой или же системой, а также структуру и поведение интерактивных функций. Цели выступают в роли фильтров для задач и обусловливают размещение информационных и управляющих элементов в ходе итеративного процесса проектирования сценариев.

В основе контекста и содержания сценария лежит информация, собранная на этапе исследований и подвергнутая анализу на этапе моделирования. Подобно участвующим в импровизации актерам, проектировщики проигрывают роли персонажей, выступающих героями этих сценариев (Verplank, et al, 1993). Такой процесс приводит к немедленному синтезу структуры и поведения продукта (как правило, на доске), которые позже прорабатываются более детально. Наконец, на протяжении всего процесса проектирования персонажи и сценарии при-

150 Глава 6. Основы проектирования: сценарии и требования

меняются для проверки разумности допущений и пригодности выдвигаемых идей.

Разновидности сценариев

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

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

В ходе всего процесса команда проектировщиков применяет проверочные сценарии для тестирования проектных решений в различных ситуациях. Как правило, эти сценарии менее подробны и обычно принимают форму набора вопросов «а что, если?..», касающихся предложенных решений. Более подробно о разработке и применении сценария ключевого пути и проверочных сценариев можно прочитать в главе 7.

Сценарии, основанные на персонажах, и варианты использования

Как сценарии, основанные на персонажах, так и варианты использования (use cases) представляют собой методы описания взаимодействия пользователя с системой. Однако они решают очень разные задачи. Це-леориентированные сценарии суть средство для итерационного определения поведения продукта с позиции конкретных пользователей (пер-

Требования: информационное обеспечение проектировани я взаимодействия 151

сонажей). Здесь имеется в виду не только функциональность системы, но также приоритет функций, то, как эти функции выглядят для пользователя и как он взаимодействует посредством них с системой. Варианты использования, в спою очередь, - это методика, основанная на исчерпывающем описании функциональных требований к системе, часто носящем транзакционный характер и ориентированном на низкоуровневые действия пользователя и соответствующие реакции системы (Wirfs-Brock, 1993). Точное поведение системы (как именно реагирует система), как правило, не является частью обычного, или конкретного, варианта использования; многие предположения относительно формы и поведения проектируемой системы остаются неявными (Constantine and Lockwood, 1999). Варианты использования позволяют провести исчерпывающую каталогизацию пользовательских задач для различных классов пользователей, однако мало или совсем ничего не говорят о том, как эти задачи должны быть представлены пользователю и какие приоритеты они получают в интерфейсе. По нашему опыту, самый серьезный недостаток традиционных вариантов использования как основы для проектирования взаимодействия состоит в том, что все возможные взаимодействия с пользователем считаются одинаково важными и одинаково вероятными. Это и понятно: ведь свое начало варианты использования берут скорее в разработке программного обеспечения, нежели в проектировании взаимодействия. Они могут быть полезны для выявления исключительных ситуаций и для определения степени функциональной завершенности продукта, однако их следует применять лишь на поздних стадиях проверки проектных решений.

Требования: информационное обеспечение проектирования взаимодействия

На стадии выработки требований мы отвечаем на вопросы, начинающиеся со слова «что»: что за функции нужны персонажам и что за информация должна быть им доступна, чтобы они могли достичь своих целей. Крайне важно ответить на эти вопросы и добиться консенсуса относительно ответов, прежде чем переходить к тому, как продукт выглядит, ведет себя, работает, какое оставляет впечатление. Смешение этих двух вопросов (что и как) может стать одной из серьезнейших ошибок при проектировании интерактивного продукта. Многие проектировщики испытывают соблазн сразу перейти к активному проектированию и отрисовать возможные решения. Независимо от творческих и профессиональных навыков, которыми вы обладаете, мы настоятельно советуем этого не делать. Вы рискуете попасть в бесконечный цикл итераций. Предлагать решение, не располагая четким согласованным определением проблемы, значит лишить себя способа оценить качество проектных решений. В отсутствие такого метода вам, заинтересованным лицам, а также вашим клиентам придется

₁₅₂ Глава 6. Осн овы проектирования: сценарии и требования

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

Определите, что должен делать продукт, прежде чем про-

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

Дата добавления: 2015-10-24