Глава 5. Модели пользователей: персонажи и цели

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

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

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

Рис. 5.5. Такие коллажи в сочетании с проработанными повествованиями -эффективный способ передать эмоциональные и эмпирические аспекты персонажа

Разработка персонажей

Ш аг 7: назначить персонажам типы

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

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

• ключевой

• второстепенный

• дополнительный

• покупатель

• обслуживаемый

• отрицательный

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

Ключевые персонажи

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

•]42 Глава 5. Модели пользователей: персонажи и цели

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

При проектировании каждого интерфейса сосредотачивай-

принцип тесь на единственном ключевом персонаже.

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

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

Второстепенные персонажи

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

Дополнительные персонажи

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

Персонажи покупателей

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

Прочие модели 143

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

Обслуживаемые персонажи

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

Отвергаемые персонажи

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

Прочие модели

Персонажи - крайне полезный инструмент, однако они не являются единственным инструментом, помогающим моделировать пользователей и их окружение. В работе «Contextual Design» Хольцблат и Бейера содержится огромный объем информации о моделях, кратко рассмотренных ниже.

Модели бизнес-процессов

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

144 Глава 5. Модели пользователей: персонажи и цели

• ц ель или желаемый результат процесса;

• частота и важность процесса и каждого действия;

• событие, инициирующее процесс в целом и каждое действие;

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

• участники процессов, их роли и ответственности;

• конкретные действия;

• принимаемые решения;

• информация, используемая при принятии решений;

• что может пойти не так - ошибки и исключительные ситуации;

• как исправляются ошибки и обрабатываются исключения.

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

Модели артефактов

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

Физические модели

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

Прочие модели

145

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

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

₆

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

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

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

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

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

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

147

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

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

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

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

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

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

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

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

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

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

На ранних стадиях проектирования считайте интерфейс

принцип волшебным.

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

Ш аг 5: выявление требований

Получив первый удовлетворяющий вас набросок контекстного сценария, вы можете приступить к его анализу с целью извлечения потребностей персонажей - требований. Эти требования могут включать в себя объекты, действия и контексты (Shneiderman, 1998). Помните: мы предпочитаем не отождествлять требования с возможностями или задачами. Таким образом, из приведенного выше сценария можно определить, например, такую потребность:

Звонок (действие) человеку (объект) непосредственно из записи о встрече (контекст).

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

Информационные требования

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

Функциональные требования

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

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

П рочие требования

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

• Требования бизнеса могут включать в себя сроки разработки, стан дарты, структуры ценообразования и бизнес-модели.

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

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

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

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

₇

От требований к пользовательскому интерфейсу: общая инфраструктура и детализация

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

Общая инфраструктура пользовательского интерфейса

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

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

Общая инфраструктура пользовательского интерфейса 163

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

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

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

Исследования в области восприятия архитектурных чертежей и визуализаций говорят в пользу такого подхода. Результаты изучения реакции людей на различные изображения, созданные в CAD-системах, приводят к заключению, что карандашные наброски стимулируют обсуждение предложенного дизайн-проекта, а также дают ясное понимание того, что представленная работа еще не закончена (Schumann et al., 1996). Кэролин Снайдер (Carolyn Snyder) подробно описывает данный эффект в своей работе «Paper Prototyping» (Snyder, 2003), где речь идет о ценности слабо детализированных представлений с точки зрения получения реакции от пользователей. Мы считаем, что юзабилити-тести-

₁₆₄ Глава 7. От требований к пользовательскому интерфейсу

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

Создание инфраструктуры взаимодействия

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

1. Определение форм-фактора, типа приложения и способов управле ния.

1. Определение функциональных и информационных элементов.

2. Определение функциональных групп и иерархических связей меж ду ними.

2. Макетирование общей инфраструктуры взаимодействия.

3. Создание ключевых сценариев.

4. Выполнение проверочных сценариев для верификации решений.

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

Шаг 1: определение форм-фактора, типа приложения и способов управления

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

Общая инфраструктура пользовательского интерфейса 165

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

Способ управления определяет, каким образом пользователь взаимодействует с продуктом. Этот способ в некоторой степени диктуется форм-фактором и типом приложения, а также предпочтениями, взглядами и навыками персонажа. Вариантов здесь множество: клавиатура, мышь, панель с клавишами, клавиатура типа thumb-board (клавиатура для больших пальцев обеих рук), сенсорный дисплей, голосовое управление, джойстик, пульт дистанционного управления, специализированные кнопки и прочее, и прочее. Какое сочетание способов подходит вашим ключевым и второстепенным персонажам? Если для продукта уместно сочетание нескольких способов управления (так обычно бывает с веб-сайтами или компьютерными приложениями, рассчитанными на мышь и клавиатуру), выберите для продукта один ключевой способ управления.

Шаг 2: определение функциональных и информационных элементов

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

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

166 . Глава 7. От требований к пользовательскому интерфейсу

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

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

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

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

• Голосовая активация (голосовые данные, привязанные к контакту из телефонной книги)

• Программируемые кнопки быстрого набора

• Выбор человека из записной книжки

• Выбор на основе заголовка сообщения электронной почты, записи о встрече или заметки

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

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

Общая инфраструктура пользовательского интерфейса 167

• П озволит пользователям эффективно достигать целей?

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

• Окажется в рамках бюджета и технологических возможностей?

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

Продукт как человеческое существо

Как вы уже знаете из главы 6, существует мощный способ представить идеальный опыт пользователя (который необходимо отразить в контекстных сценариях концептуального уровня) - притвориться, что инструмент, продукт или система - волшебные. Точно так же, притворившись, что система - это человек, мы получим мощный инструмент для структурирования деталей уровня взаимодействия. Подробно мы обсудим этот простой принцип в главе 12, а в двух словах - взаимодействие с цифровой системой должно по тону и приносимой пользе напоминать общение с вежливым и внимательным человеком (Cooper, 1999). Определяя варианты взаимодействия и поведения наряду с функциональными элементами и группами, спросите себя: что сделал бы человек, который рад помочь? На что похоже тщательно продуманное и взвешенное взаимодействие? Гуманно ли продукт поступает с ключевым персонажем? Какими способами программа может информировать пользователя, не мешая ему при этом работать? Как она может свести к минимуму усилия персонажа в достижении его целей?

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

Применяйте принципы и шаблоны

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