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

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

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

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

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

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

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

Нас окружают свидетельства эффективности повествования как средства проектирования. Знаменитые инженеры-затейники студии 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. Осн овы проектирования: сценарии и требования

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

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

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

Проектирования

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

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

Выработка требований с использованием персонажей и сценариев 153

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

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

Выработка требований с использованием персонажей и сценариев

Как мы вкратце уже говорили в главе 1, процесс перехода от достоверных моделей к интерфейсным решениям в действительности состоит из двух основных этапов. Этап выработки требований дает ответы на общие вопросы о сущности и задачах продукта, а этап формирования инфраструктуры отвечает на вопрос о том, как ведет себя продукт и каким образом его структура соответствует целям пользователя. В этом разделе мы подробно обсудим этап выработки требований, а в главе 7 -формирование инфраструктуры. Описываемые методы опираются на методологию сценариев, основанных на персонажах, созданную в компании Cooper Робертом Рейманом, Ким Гудвин, Дейвом Кронином (Dave Cronin), Уэйном Гринвудом (Wayne Greenwood) и Лэйн Хэлли (Lane Halley).

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

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

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

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

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

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

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

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

часть всего процесса, и здесь не стоит срезать углы. Далее представлены подробные описания каждого из пяти шагов.

Шаг 1: постановка задачи и определение образа продукта

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

Говоря в общем, постановка задачи определяет цель самого проекти- рования (Newman and Lamming, 1995). Постановка задачи проектирования кратко отражает ситуацию, требующую изменения, как с точки зрения персонажей, так и с точки зрения бизнеса, который создает для этих персонажей продукт. Часто между интересами бизнеса и персонажа существует причинно-следственная связь. К примеру:

Рейтинг удовлетворенности клиентов компании X низок, а доля на рынке уменьшилась на 10% за последний год, потому что у пользователей нет адекватных инструментов, позволяющих посредством решения задач X, Y и Z достичь цели G.

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

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

В новой версии продукт X поможет пользователям достичь G, поскольку даст им возможность выполнять X, Y, и Z с большей [точностью, эффективностью и т. п.], при этом избавляя от существующих сейчас про-ОлемА, В и С. Это резко повысит удовлетворенность клиентов компании А и приведет к увеличению присутствия на рынке.

Как постановка задачи, так и определение образа продукта опираются на данные исследований и модели пользователей. Цели и потребности

Выработка требований с использованием персонажей и сценариев 155

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

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

Шаг 2: мозговой штурм

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

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

Мозговой штурм должен происходить без ограничений, без критики -выкладывайте все те сумасшедшие идеи, которые вы уже обдумывали ранее, а также те, которые не обдумывали, и будьте готовы записать их и убрать на хранение до гораздо более поздней стадии процесса. Далеко не все их них могут оказаться в конечном итоге полезными, однако в них может быть зерно чего-то прекрасного, что отлично впишется в общую структуру продукта, которую вы построите позднее. Карен Хольцблат и Хью Вейер описывают удобную для мозгового штурма методику, которая может быть полезна для «расшевеливания» мозгового штурма, особенно если в команду входят не только проектировщики (Beyer and Holtzblatt, 1998).

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

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

Шаг 3: выявление ожиданий персонажей

Как уже обсуждалось в главе 2, ментальная модель - это внутреннее представление человека о реальности, то, как он думает о чем-либо или как объясняет себе это. Ментальные модели глубоко встроены в сознание и часто являются итогом продолжительного жизненного опыта. Ожидания людей относительно продукта и того, как он работает, в большой степени зависят от ментальных моделей.

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

Чтобы этого добиться, необходимо записать ожидания пользователей в формальном виде. Это важный источник требований. Для каждого ключевого или второстепенного персонажа необходимо выявить:

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

• Общие ожидания и желания, которые может иметь персонаж в свя
зи с использованием продукта.

• Ожидаемое или желаемое персонажем поведение продукта.

• Что персонаж думает о базовых единицах информации (скажем,
в приложении для электронной почты базовой единицей информа
ции будет сообщение или корреспондент).

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

• Что респонденты упоминают в первую очередь?

• Какие глаголы - слова, обозначающие действия, - они используют?

• Какие промежуточные шаги, задачи или объекты, относящиеся
к процессу, они не упоминают? (Намек: такие шаги, задачи, объек
ты могут быть не особенно важны для их ментальных моделей.)

Выработка требований с использованием персонажей и сценариев 157

Шаг 4: разработка контекстных сценариев

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

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

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

Контекстные сценарии отвечают на вопросы, подобные этим:

• В какой обстановке будет использоваться продукт?

• Будет ли он использоваться в течение долгого времени?

• Часты ли прерывания в работе персонажа?

• Работает ли с компьютером/устройством более чем один пользова
тель?

• Какие еще продукты используются вместе с проектируемым?

• Какие основные действия должен выполнить персонаж, чтобы дос
тичь своих целей?

• Каков ожидаемый конечный результат применения продукта?

• Какова допустимая сложность продукта исходя из частоты его ис
пользования и навыков персонажа?

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

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

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

Пример контекстного сценария

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

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

2. Вивьен видит письмо от последнего клиента, Фрэнка, который хотел
бы днем посмотреть дом. Контакт Фрэнка уже есть внутри устройст
ва, поэтому Вивьен может позвонить Фрэнку при помощи единст
венного действия непосредственно с экрана электронного письма.

3. Разговаривая с Фрэнком, Вивьен включает громкую связь, чтобы
иметь возможность в ходе разговора смотреть на экран. Она изучает
назначенные встречи, чтобы понять, в какое время она свободна.
Когда она создает новую запись о встрече, смартфон автоматически
отмечает ее как встречу с Фрэнком, потому что знает, с кем она сей
час разговаривает. Заканчивая беседу, она быстро вносит адрес до
ма в запись о встрече.

4. Отправив Алису в школу, Вивьен направляется в агентство недви
жимости, чтобы собрать документы, которые требуются для другой
встречи. Ее смартфон уже синхронизировал новые встречи с Out
look, так что остальные сотрудники офиса знают, где она будет днем.

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

Выработка требований с использованием персонажей и сценариев 159

и смартфон автоматически связывает ее с Фрэнком, поскольку знает о скорой встрече с ним. Вивьен сообщает Фрэнку, что будет на месте через двадцать минут.

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

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

8. Вивьен принимает звонок и выясняет, что Алиса опоздала на авто
бус и ее нужно забрать из школы. Вивьен звонит мужу, чтобы выяс
нить, сможет ли он это сделать, однако попадает в голосовую почту -
вероятно, муж находится за пределами действия сети. Она сообщает
мужу, что она на встрече с клиентом, и спрашивает, сможет ли он
забрать Алису. Через пять минут смартфон издает короткий звук,
по которому Вивьен узнает, что это муж; она видит, что он прислал
ей короткое сообщение: «Алису заберу, удачи со сделкой!»

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

⇐ Предыдущая11121314151617181920Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: