
- •Isbn 978- 0-470-08411-3 (англ)
- •19. Указание, выделение, непосредственное
- •Глава 1. Проектирование, ориентированное на цели
- •Глава 1. Проектирование, ориентированное на цели
- •64 Глава 2. Модели реализации и ментальные модели
- •Глава 2. Модели реализации и ментальные модели
- •Глава 3. Новички,эксперты и середняки
- •Глава 5. Модели пользователей: персонажи и цели
- •Глава 5. Модели пользователей: персонажи и цели
- •Глава 5. Модели пользователей: персонажи и цели
- •Глава 5. Модели пользователей: персонажи и цели
- •Глава 5. Модели пользователей: персонажи и цели
- •Глава 5. Модели пользователей: персонажи и цели
- •168 Глава 7. От требований к пользовательскому интерфейсу
- •Глава 7. От требований к пользовательскому интерфейсу
- •Глава 7. От требований к пользовательскому интерфейсу
- •Глава 7. От требований к пользовательскому интерфейсу
- •Глава 7. От требований к пользовательскому интерфейсу
- •Глава 9. Техническая платформа и тип интерфейса
- •Глава 9. Техническая платформа и тип интерфейса
- •2 26 Глава 9. Техническая платформа и тип интерфейса
- •Глава 9. Техническая платформа и тип интерфейса
- •Глава 9. Техническая платформа и тип интерфейса
- •Глава 9. Техническая платформа и тип интерфейса
- •240 Глава 9. Техническая платформа и тип интерфейса
- •Глава 9. Техническая платформа и тип интерфейса
- •Глава 10. Оркестровка и состояние потока
- •246 Глава 10. Оркестровка и состояние потока
- •Глава 10. Оркестровка и состояние потока
- •Глава 11. Оптимизация налогообложения
- •Глава 11. Оптимизация налогообложения
- •Глава 11. Оптимизация налогообложения
- •Глава 11. Оптимизация налогообложения
- •Глава 11. Оптимизация налогообложения
- •Глава 12. Проектирование хорошего поведения
- •302 Глава 12. Проектирование хорошего поведения
- •Глава 12. Проектирование хорошего поведения
- •Глава 12. Проектирование хорошего поведения
- •318 Глава 13. Метафоры, идиомы, ожидаемое назначение
- •Глава 13. Метафоры, идиомы, ожидаемое назначение
- •330 Глава 13. Метафоры, идиомы, ожидаемое назначение
- •Глава 13. Метафоры, идиомы, ожидаемое назначение
- •Глава 14. Визуальный дизайн интерфейсов
- •346 Глава 14. Визуальный дизайн интерфейсов
- •Глава 14. Визуальный дизайн интерфейсов
- •360 Глава 14. Визуальный дизайн интерфейсов
- •Глава 14. Визуальный дизайн интерфейсов
- •Глава 14. Визуальный дизайн интерфейсов
Глава 5. Модели пользователей: персонажи и цели
П осле того как персонажи были представлены в качестве инструмента моделирования пользователей в книге «The Inmates Are Running The Asylum»1 (Cooper, 1999), они приобрели огромную популярность в сообществе людей, занимающихся проектированием опыта взаимодействия, но вместе с тем стали предметом некоторого недопонимания. Нам хотелось бы прояснить и более подробно изложить некоторые понятия и соображения, касающиеся персонажей.
Цели Марж
► Чувствовать себя в безопасности ► Ехать с комфортом
Цели Дейла
► Перевозить тяжелые грузы ► Ощущать надежность
Рис. 5.2. Упрощенная демонстрация полезности персонажей. Проектируя для разных людей с разными целями разные автомобили, мы способны создавать машины, удовлетворяющие и других людей, потребности которых аналогичны потребностям «целевых» водителей. То же самое верно для проектирования цифровой техники и программного обеспечения
Преимущества персонажей как средства проектирования
Персонажи - мощное и универсальное средство проектирования, способствующее преодолению ряда проблем, которые в настоящее время неотступно преследуют разработчиков цифровых продуктов. Персонажи помогают проектировщикам:
• Определять, что должен делать продукт и каким должно быть его поведение. Цели и задачи персонажей образуют фундамент для проектирования.
А . Купер «Психбольница в руках пациентов. Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие», дополненное издание. - Пер. с англ. - СПб: Символ-Плюс, 2009.
Персонажи 113
О бщаться с заинтересованными лицами, разработчиками и други ми проектировщиками. Персонажи задают общий язык для обсуж дения проектных решений, а также помогают удерживать фокус на пользователях на каждом шаге процесса.
Достигать взаимопонимания и согласия в вопросах проектирова ния. С общим языком приходит и общее понимание. Персонажи со кращают потребность в подробных моделях-диаграммах: многочис ленные нюансы поведения пользователей проще понять благодаря повествовательным средствам, на которых основана работа с пер сонажами. Проще говоря, поскольку персонажи напоминают жи вых людей, они воспринимаются легче, чем диаграммы и списки функций.
Оценивать эффективность решений. На персонажах можно испы тывать проектные решения в процессе их формирования так, слов но вы показываете их реальным пользователям. Хотя этот метод не отменяет необходимость тестирования на реальных пользователях, он является мощным средством проверки найденных при проекти ровании решений на соответствие реальности. Это позволяет быст ро и недорого выполнять итерации проектирования, пользуясь лишь набросками на доске, и при этом подойти к моменту тестиро вания на реальных пользователях с более сильными интерфейсны ми решениями.
Вносить вклад в работу других подразделений, связанных с продук том, например в планы по маркетингу и продажам. Авторы сталки вались с тем, что клиенты начинают применять персонажей внутри своей организации в иных целях, например в качестве источника информации для маркетинговых кампаний, развития структуры организации и других задач стратегического планирования. Под разделения, не имеющие непосредственного отношения к разработ ке продукта, жаждут подробной информации о пользователях про дукта и обычно проявляют к персонажам огромный интерес.
Кроме того, персонажи позволяют решить три ключевые проблемы проектирования, возникающие при разработке продукта. Вот эти проблемы:
Проблема пластилинового пользователя
Проектирование под себя
Проектирование в расчете на исключительные ситуации
Мы коротко опишем каждую из них в последующих подразделах.
Проблема пластилинового пользователя
Наша цель состоит в удовлетворении пользователя, однако слово «пользователь» вызывает проблемы при решении конкретных вопросов в конкретных контекстах проектирования. Нечеткость термина делает его опасным в качестве средства проектирования: у каждого
114 Глава 5. Модели пользователей: персонажи и цели
ч еловека в команде разработчиков есть свое представление о пользователе и его потребностях. Когда наступает момент принятия решений по продукту, этот «пользователь» становится пластилиновым: он всегда прогибается так, чтобы соответствовать мнениям и предположениям конкретного говорящего.
Если разработчикам удобно использовать для представления информации устрашающий элемент управления с деревом папок, они определяют пластилинового пользователя как сведущего в компьютерах «продвинутого» пользователя. Когда же им удобнее пошагово провести пользователя через сложный процесс при помощи мастера (wizard), они определяют пластилинового пользователя как неподготовленного новичка. Проектируя в расчете на пластилинового пользователя, разработчик сам себе выдает индульгенцию на то, чтобы программировать продукт так, как ему заблагорассудится, не переставая при этом якобы «служить пользователю». Но ведь наша цель - проектировать программное обеспечение, которое удовлетворяет потребности реальных пользователей. Реальные пользователи - и представляющие их персонажи - не пластилиновые, у них есть конкретные требования, основанные на их целях, способностях и контексте использования продукта.
Даже использование ролей пользователей или названий должностей вместо конкретизированных архетипов способно внести в процесс проектирования неопределенность. К примеру, при проектировании медицинских продуктов может оказаться соблазнительным счесть, что у всех медсестер одинаковые потребности. Как известно любому, кто бывал в больнице, есть медсестры из отделения травматологии, из отделения детской реанимации, из операционной - и у каждой группы собственные взгляды, способности, потребности, мотивы. Нехватка точности в определении пользователя может привести к недостаточно ясному представлению о требуемом поведении продукта.
Проектирование под себя
Проектирование под себя имеет место тогда, когда проектировщики или разработчики отражают в проектных решениях собственные цели, мотивацию, навыки и ментальные модели. В эту категорию попадает большинство «смелых дизайнерских решений»: аудитория продукта мыслится состоящей из людей, подобных самому проектировщику, что приемлемо для узкого спектра продуктов и совершенно недопустимо для большинства других. Программисты, создавая продукты на основе модели реализации, также занимаются проектированием для себя. Они прекрасно понимают, как структурированы данные и как устроен программный код, и поэтому находят такие продукты удобными. А вот те, кто не занимается программированием, вряд ли с ними согласятся.
Персонажи 115
П роектирование в расчете на исключительные ситуации
Еще один синдром, который помогают предотвратить персонажи, -проектирование в расчете на исключительные ситуации. Такие ситуации в принципе могут возникнуть, но целевые персонажи, как правило, с ними не сталкиваются. Разумеется, исключительные ситуации следует учитывать при проектировании и программировании, но нельзя строить вокруг них весь процесс проектирования. Персонажи дают возможность проверять решения на соответствие реальности. Мы можем спросить себя: «Насколько часто Джули захочет выполнять это действие? Захочет ли вообще?» Вооруженные этим знанием, мы можем очень четко назначать приоритеты различным функциям.
Персонажи основаны на исследованиях
Как любая модель, персонажи должны основываться на наблюдениях за реальностью. В предыдущей главе мы говорили, что основным источником данных при синтезе персонажей служат интервью, основанные на этнографических методах, контекстное исследование либо другие формы обсуждений с действительными и потенциальными пользователями и наблюдения за ними. Качество данных, собранных в ходе этого процесса (описанного в главе 4), напрямую определяет действенность персонажей как средства, позволяющего упростить и направить процесс проектирования. Прочие данные, способные помочь в процессе создания персонажей и уточнить информацию о них, включают в себя (в примерном порядке убывания эффективности):
данные интервью с пользователями вне контекста использования;
информацию о пользователях, предоставленную заинтересованны ми лицами и экспертами в предметной области (ЭПО);
данные исследований рынка, таких как фокус-группы и опросы;
модели сегментации рынка;
результаты обзора литературы и более ранних исследований.
При этом никакие вспомогательные данные не могут заменить прямое взаимодействие и наблюдение за пользователями в привычной для них среде. Практически каждое слово из описания хорошо проработанного персонажа можно поставить в соответствие некоторой цитате из интервью или наблюдавшемуся поведению.
Персонажи представляются как отдельные личности
Персонажи - это модели пользователей, представленные в виде отдельных, конкретных людей. Они не являются реальными людьми, но синтезируются непосредственно по результатам наблюдений за реальными людьми. Успех персонажей как моделей пользователей во многом определяется тем, что персонажи олицетворяют личности (Соп-stantine and Lockwood, 2002). Такое представление является уместным и действенным благодаря уникальным особенностям персонажей как
116 Глава 5. Модели пользователей: персонажи и цели
м оделей: они вызывают эмпатию (сопереживание) проектировщиков и разработчиков по отношению к людям, ради которых выполняется проектирование. Чувство эмпатии абсолютно необходимо проектировщикам, которым предстоит при проектировании принимать концептуальные и детальные решения исходя как из когнитивных, так и из эмоциональных свойств персонажей, представленных целями этих персонажей. (О важных связях между пользовательскими целями, поведением пользователей и персонажами мы поговорим далее в этой главе.) Однако возможности эмпатии не следует сбрасывать со счетов и тогда, когда речь идет о других участниках команды. Персонажи не только помогают проектировщикам найти решения, лучше отвечающие действительным потребностям пользователей, но и делают эти решения более обоснованными в глазах заинтересованных в реализации лиц. Если персонажи разработаны тщательно и корректно, заинтересованные лица и инженеры начинают думать о них как о настоящих пользователях и проявляют гораздо больший интерес к созданию продукта, который станет источником положительного опыта для этих персонажей.
Известно, какой властью над читателями и зрителями обладают вымышленные персонажи книг, фильмов и телепрограмм. Джонатан Грудин (Jonathan Grudin) и Джон Прюит (John Pruitt) рассмотрели эту особенность применительно к проектированию взаимодействия (Grudin and Pruitt, 2002). Среди прочего они отметили важность методики вживания в роль, применяемой актерами для понимания и воссоздания реалистичных действующих лиц. Процесс создания персонажей на основе наблюдений за пользователями и последующего проигрывания ролевых сценариев в роли этих персонажей во многом аналогичен методике вживания в роль. (Нам доводилось даже слышать, как целеориентированное применение персонажей называют системой Станиславского в проектировании взаимодействия.)
Персонажи являются представителями групп пользователей
Хотя персонажи изображаются как конкретные личности (поскольку выполняют функцию архетипов), каждый из них является представителем класса или типа пользователей конкретного интерактивного продукта. Персонаж вбирает в себя уникальный набор шаблонов поведения, связанных с использованием определенного продукта (или с аналогичной деятельностью в предметной области, если продукт еще не существует), которые выявляются посредством анализа данных интервью и при необходимости подкрепляются дополнительными количественными данными. Наряду с конкретными мотивами и целями эти шаблоны задают персонажей. Иногда персонажей называют также составными архетипами пользователей, поскольку они создаются путем группировки родственных шаблонов использования, наблюдавшихся в ходе фазы исследований у пользователей, играющих сходные роли (Mikkelson and Lee, 2000).
Персонажи 147
П ерсонажи и повторное использование
Организации, выпускающие несколько продуктов, часто желают повторно использовать тех же персонажей. Но чтобы быть эффективными, персонажи должны быть четко привязаны к контексту - то есть ориентированы на особенности поведения и цели, связанные с конкретной предметной областью определенного продукта. Поскольку персонажи конструируются на основе наблюдений за пользователями, работающими с определенными продуктами в уникальном контексте, их не получится легко перенести на другие продукты, даже если эти продукты относятся к одному узкому семейству (Grudin and Pruitt, 2002).
Чтобы набор персонажей был эффективным средством проектирования для нескольких продуктов, персонажей следует создавать на основе исследований, охватывающих контексты использования всех этих продуктов. Это приведет не только к увеличению масштаба исследований, но и к более сложной проблеме выявления управляемых и связных наборов шаблонов поведения, действительных для всех контекстов. Ошибкой будет считать, что два пользователя, проявляющих сходное поведение в отношении одного продукта, будут сходно вести себя и в отношении другого. Таким образом, чем больше продуктов вы пытаетесь охватить, тем сложнее сохранять четкость и связность набора персонажей, представляющего разнообразие настоящих пользователей. Мы считаем, что в большинстве случаев для различных продуктов следует изучать и создавать самостоятельных персонажей.
Архетипы и стереотипы
Не путайте архетипы, которыми, по сути, являются персонажи, со стереотипами. Стереотипы во многих отношениях являются противоположностью хорошо проработанных персонажей, так как представляют предубеждения и предположения проектировщиков и исследователей, а не фактические данные. Персонажи, созданные на основе неадекватных исследований (или составленные без должной степени эмпатии и участия по отношению к участникам интервью), рискуют деградировать до уровня карикатурных стереотипов. Персонажи должны создаваться и использоваться с уважением и почтением к тем людям, которых они представляют. Если проектировщик не уважает своих персонажей, другие люди тоже не будут их уважать.
Кроме того, персонажи выводят на передний план вопросы социальной и политической ответственности (Grudin and Pruitt, 2002). Поскольку персонажи четко задают цели проектирования и выступают в качестве средства коммуникации в команде разработчиков, проектировщик должен особенно осторожно выбирать демографические характеристики. В идеальном случае демография персонажа должна отражать сочетание характеристик, наблюдавшихся в выборке респондентов, уточненное широкоохватными исследованиями рынка. Персонажи должны быть типичными и правдоподобными, но не стереотипными. Если
118 Глава 5. Модели пользователей: персонажи и цели
д анные недостаточно точны или же характеристика не является важной для проектирования либо его результатов, мы предпочтем ошибиться в пользу полового, этнического, возрастного и географического разнообразия.
Персонажи описывают варианты поведения
Целевой рынок продукта задает демографию, стиль жизни людей, а иногда и их рабочие роли. Однако целевой рынок не определяет весь спектр вариантов поведения его участников, связанный с самим продуктом и контекстом его использования. Варианты поведения - это не описание «среднего» поведения: смысл персонажей не в определении среднего пользователя, а в выявлении образцов поведения в рамках определенного спектра.
Поскольку любой продукт обязан учитывать варианты поведения пользователей, спектр их принципов и склонностей, проектировщики должны для каждого продукта определить набор персонажей. Множественные персонажи разбивают спектр вариантов поведения на дискретные кластеры. Каждый персонаж представляет набор взаимосвязанных шаблонов поведения. Эти связи выявляются при анализе результатов исследований. Более подробно процесс кластеризации вариантов поведения будет описан далее в этой главе.
Персонажи должны обладать мотивацией
Поведение каждого человека определяется его мотивами; некоторые очевидны, но многие скрыты. Крайне важно, чтобы персонажи отражали эти мотивы - в виде описания целей. Перечисление целей наших персонажей (их мы более подробно обсудим в оставшейся части главы) -это краткое описание мотивов, не только отсылающее к определенным шаблонам использования, но и объясняющее существование определенных шаблонов поведения. Понимание того, почему пользователь выполняет те или иные задачи, дает проектировщикам хорошую возможность усовершенствовать способы решения этих задач или даже вовсе исключить эти задачи на пути достижения все тех же целей.
Персонажи могут представлять не только пользователей
Для проектировщика взаимодействия пользователи и потенциальные пользователи продукта всегда стоят на первом месте, однако иногда бывает полезно иметь представление целей и потребностей людей, которые не пользуются продуктом, но должны быть приняты во внимание в процессе проектирования. Так часто происходит с программным обеспечением для бизнеса (и с детскими игрушками): пользуется продуктом не тот человек, который его приобретает. В таких случаях в дополнение к персонажам пользователей могут оказаться полезными один или несколько персонажей покупателей. Разумеется, как
Персонажи
и в случае с пользователями, эти персонажи должны создаваться на основе шаблонов поведения, выявленных в ходе этнографических исследований.
Еще один пример: во многих медицинских продуктах пациенты не взаимодействуют непосредственно с пользовательским интерфейсом, однако обладают собственными мотивами и целями, которые могут значительно отличаться от мотивов и целей использующих эти продукты врачей. В таких случаях бывает полезно создавать обслуживаемого персонажа, представляющего потребности пациента. Обслуживаемых персонажей и персонажей покупателей мы более подробно обсудим далее в этой главе.
Персонажи и другие модели пользователей
При проектировании интерактивных продуктов применяется ряд других моделей пользователей - в частности, роли пользователей, профили пользователей и сегменты рынка. Эти модели похожи на персонажей в том смысле, что направлены на описание пользователей и их связей с продуктом. Однако персонажи, а также способы их создания и применения в процессе проектирования значительно отличаются от других моделей рядом важных моментов.
Роли пользователей
Роли пользователей, или ролевые модели, в определении Ларри Конс-тантайна, являются абстракцией - определенным соотношением между классом пользователей и их задачами, включая потребности, интересы, ожидания и шаблоны поведения (Constantine and Lockwood, 1999). Будучи абстракциями (принимающими обычно форму списка атрибутов), роли не визуализируются в виде людей, а потому обычно неспособны передавать более широкие человеческие мотивы и контексты.
Сходным образом используют роли Хольцблат и Бейер при объединении потоковых, культурных, физических моделей и диаграмм последовательностей - они пытаются абстрагировать различные атрибуты и типы отношений, отделив их от людей, которые обладают этими атрибутами и отношениями (Beyer and Holtzblatt, 1998).
Эти подходы представляются нам не слишком удачными ввиду следующих причин:
Абстрагирование и работа в отрыве от конкретных людей мешают должным образом передавать другим особенности поведения поль зователей и их отношения - человеческая эмпатия плохо работает с абстрактными классами людей.
Оба подхода практически полностью сосредотачиваются на задачах и пренебрегают целями как полезным способом организации про цессов мышления и синтеза.
120 Глава 5. Модели пользователей: персонажи и цели
• Объединенные модели Хольцблат и Бейера, несмотря на их полезность и широкий охват, недостаточно хороши как целостный инструмент, который можно применять при выработке, передаче и оценке проектных решений.
Персонажи решают все эти проблемы. Хорошо проработанные персонажи охватывают все те же виды отношений, что и роли, но выражают их в виде целей и дают примеры в повествовательной форме. В итоге как проектировщикам, так и заинтересованным лицам становится проще понимать последствия проектных решений в «человеческой» перспективе. Описание целей персонажей задает контекст и структуру для задач, указывая, как культурная среда и рабочий процесс влияют на поведение.
Кроме того, сосредоточение на ролях пользователей вместо более сложных шаблонов поведения может привести к чрезмерному выхолащиванию отличительных признаков, определяющих похожесть и непохожесть пользователей. Можно создать персонажа, представляющего потребности нескольких ролей (скажем, при проектировании мобильного телефона путешествующий коммивояжер может представлять также потребности занятого руководителя, который постоянно находится в разъездах). Может оказаться также, что одну роль выполняют разные люди, которые по-разному мыслят и действуют (скажем, сотрудник отдела закупок в химической промышленности может думать о своей работе совсем иначе, чем такой же сотрудник в производстве бытовой электроники). В случае потребительских товаров роли практически бесполезны. Если вы проектируете веб-сайт для автомобильной компании, роль «покупатель автомобиля» не имеет смысла как средство проектирования: разные люди очень по-разному подходят к вопросу приобретения автомобиля.
В общем, персонажи дают более целостную модель пользователей и контекста, в котором эти пользователи находятся, тогда как многие другие модели, напротив, стремятся к большей схематичности. Персонажей, конечно же, можно применять в сочетании с другими методиками моделирования, и, как мы увидим в конце главы, некоторые модели становятся крайне полезными дополнениями к персонажам.
Персонажи и профили пользователей
Многие юзабилити-специалисты считают термины персонаж и профиль пользователя синонимами. Здесь нет проблемы, если профиль действительно создан на основе этнографических данных и содержательно отражает всю глубину описанных выше характеристик. К сожалению, слишком часто нам приходилось видеть профили пользователей, соответствующие определению «профиля» в словаре Вебстера: «краткий биографический очерк». Иначе говоря, профиль пользователя - это зачастую просто его имя (и, возможно, фотография) плюс краткие, как правило, демографические данные, а также небольшой абзац
Персонажи 121
с вымышленным описанием того, на какой машине человек ездит, сколько у него детей, где он живет и чем зарабатывает на жизнь. Такого рода профиль пользователя с большой вероятностью окажется стереотипом и будет бесполезным в качестве средства проектирования. Хотя мы придумываем для своих персонажей имена, а иногда даже автомобили и членов семьи, все это используется осторожно, как средство повествования, позволяющее лучше передавать стоящие за этим реальные данные. Вспомогательные вымышленные детали играют минимальную роль в создании персонажа и служат лишь для того, чтобы оживить персонажа в глазах проектировщиков и разработчиков продукта.
Персонажи и рыночные сегменты
Маркетологам может быть знаком процесс, сходный с созданием персонажа, - процесс определения рынка. Основное различие между сегментами рынка и персонажами для проектирования состоит в том, что первые основаны на демографии, каналах распространения и поведении потребителей, а вторые - на шаблонах использования и мотивах пользователей. Это разные модели, которые служат различным целям. Маркетинговые персонажи проливают свет на процесс продажи, а персонажи проектировщиков - на процесс определения и разработки продукта.
Тем не менее сегменты рынка играют свою роль в создании персонажей: они помогают задавать демографический диапазон, в рамках которого определяется гипотеза о персонажах (см. главу 4). Персонажи сегментируются соответственно вариантам поведения, а не по демографическим данным или потребительскому поведению, поэтому сегменты рынка и персонажи редко совпадают один в один. Скорее, сегменты рынка способны послужить первичным фильтром, ограничивающим масштабы выборки респондентов для интервью рамками целевого рынка (рис. 5.3). Кроме того, мы обычно назначаем персонажам приоритеты, помогающие принимать стратегические решения по определению продукта (о типах персонажей мы поговорим чуть позже). Эти решения должны основываться в том числе и на результатах анализа рынка; понимание связи между персонажами и сегментами рынка может оказаться весьма важным.
Условный персонаж:
что делать, если нет точного персонажа
Крайне желательно, чтобы персонажи основывались на подробных качественных данных, однако в некоторых случаях просто не хватает времени, ресурсов или поддержки со стороны руководства, чтобы выполнить всю необходимую работу «в поле». В таких случаях полезными риторическими инструментами, ясно выражающими предположения относительно того, какие пользователи являются важными и каковы их потребности, а также вынуждающими участников процесса
122