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

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

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

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

 

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

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

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

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

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

 

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

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

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

сонажей). Здесь имеется в виду не только функциональность системы, но также приоритет функций, то, как эти функции выглядят для поль' зователя и как он взаимодействует посредством них с системой.

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

 

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

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

 

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

 

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

 

 

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

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

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

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

 

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

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

 

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

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

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

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

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

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

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

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

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

 

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