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

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

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

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

• ключевой

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

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

• покупатель

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

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

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

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

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

 

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

 

При проектировании каждого интерфейса сосредотачивай- тесь на единственном ключевом персонаже.

 

 

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

 

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

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

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