31021

Алан Купер об интерфейсе. Основы проектирования взаимодействия

Книга

Информатика, кибернетика и программирование

Проектирование ориентированное на цели 38 Цифровым продуктам необходимы более качественные методы проектирования 33 Эволюция проектирования в промышленности 41 Планирование и проектирование поведения 43 Выявление целей пользователей 44 Целеориентированный процесс проектирования 48 2. Новички эксперты и середняки 73 Вечные середняки 73 Проектирование для пользователей с различной подготовкой 76 4. Как понять пользователей: качественные исследования 81 Качественные н количественные исследования 81 Этнографические интервью: интервьюирование и...

Русский

2013-08-25

2.21 MB

38 чел.

Алан Купер об интерфейсе

Основы проектирования взаимодействия

Алан Купер, Роберт Рейман, Дэвид Кронин

Санкт- Петербург ~ Москва 2010


Серия «Профессионально» Алан Купер, Роберт Рейман, Дэвид Кронин

Алан Купер об интерфейсе Основы проектирования взаимодействия

Перевод М.Зислиса

Главный редактор А. Галунов

Зав. редакцией Я. Макарова

Научный редактор А. Копылов

Редактор В. Подобед

Художник О.Макарова

Корректор С. Минин

Верстка Д- Орлова

Купер А. Рейман Р., Кронин Д.

Алан Купер об интерфейсе. Основы проектирования взаимодействия. - Пер.

с англ. - СПб.: Символ-Плюс, 2010. - 688 с, ил.

ISBN 978-5-93286-132-5

Когда в 1995 году увидело свет первое издание «About Face», идея проектировать продукты исходя из целей людей казалась революционной. Благодаря работам Алана Купера и других первопроходцев, проектирование взаимодействия получило сегодня широкое признание как уникальная и крайне важная дисциплина, однако эта работа далека от завершения.

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

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

ISBN 978-5-93286-132-5

ISBN 978- 0-470-08411-3 (англ)

© Издательство Символ-Плюс, 2009

Authorized translation of the English edition © 2007 Wiley Publishing, Inc. This translation is published and sold by permission of Wiley Publishing, Inc., the owner of all rights to publish and sell the same.

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

Издательство «Символ-Плюс». 199034, Санкт-Петербург, 16 линия, 7,

тел. (812) 324-6353, www.symbol.ru. Лицензия ЛП N 000054 от 25.12.98.

Подписано в печать 17.12.2009. Формат 70х100'ле . Печать офсетная.

Объем 43 печ. л. Доп. тираж 1500 экз. Заказ N 1494 Отпечатано о готовых диапозитивов в ГУП «Типография «Наука» 199034, Санкт-Петербург, 9 линия, 12.


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

Максвеллу Аарону Рейману.

Гретхен.

А также куперистам прошлого, настоящего и будущего

и тем умеющим мечтать практикам, чьими усилиями

проектирование взаимодействия превратилось в профессию.


Оглавление

Об авторах 12

Предисловие. Постиндустриальный мир 13

Введение к третьему изданию 19

I. Введение в целеориентированное проектирование 31

1. Проектирование, ориентированное на цели 38

Цифровым продуктам необходимы

более качественные методы проектирования 33

Эволюция проектирования в промышленности 41

Планирование и проектирование поведения 43

Выявление целей пользователей 44

Целеориентированный процесс проектирования 48

2. Модели реализации и ментальные модели 59

Модели реализации 59

Пользовательские ментальные модели 60

Модели представления 61

Большинство программных продуктов следуют

модели реализации 64

Модели представления механической и информационной эры 67

3. Новички, эксперты и середняки 73

Вечные середняки 73

Проектирование для пользователей с различной подготовкой 76

4. Как понять пользователей: качественные исследования 81

Качественные н количественные исследования 81

Этнографические интервью: интервьюирование

и наблюдение за пользователями 90

Прочие виды исследований 102


Оглавление

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

Для чего нам модели? 110

Персонажи 111

Цели 123

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

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

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

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

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

взаимодействия 151

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

и сценариев 153

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

общая инфраструктура и детализация 162

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

Детализация формы и поведения 179

Проверка результата проектирования

и юзабилити-тестирование 181

II. Проектирование облика и поведения 187

8. Создание качественного интерфейса:

принципы и шаблоны 189

Принципы проектирования взаимодействия 189

Ценности проектирования 191

Шаблоны проектирования взаимодействия 196

9. Техническая платформа и тип интерфейса 200

Тип интерфейса 201

Проектирование настольных приложений 202

Проектирование в среде Всемирной паутины 214

Прочие платформы 223

10. Оркестровка и состояние потока 243

Состояние потока и прозрачность        243

Проектирование гармоничного взаимодействия 245

11. Оптимизация налогообложения 266

Налоги в графическом пользовательском интерфейсе  267

Прекращение работы  271

Распространенные налоговые ловушки  274

Навигация как налог  275

Улучшение навигации  281


Оглавление

12. Проектирование хорошего поведения 293

Проектирование тактичных продуктов  294

Проектирование интеллектуальных продуктов 304

13. Метафоры, идиомы, ожидаемое назначение 315

Парадигмы интерфейса 316

Еще об ограничениях метафор          322

Построение идиом          327

Ожидаемые физические назначения 329

14. Визуальный дизайн интерфейсов 333

Изобразительное искусство, визуальный дизайн интерфейсов

и прочие дисциплины дизайна 334

Строительные блоки визуального дизайна интерфейсов 336

Принципы визуального дизайна интерфейса 339

Принципы визуального информационного дизайна 361

Единство и стандарты 365

III. Детальное проектирование взаимодействия 369

15. Совершенствуем поиск и извлечение данных 371

Системы хранения и извлечения информации 372

Хранение и извлечение в физическом мире 372

Хранение и извлечение в цифровом мире 374

Реляционные базы данных и «цифровой бульон» 379

Вывод на естественном языке: идеальный интерфейс

для извлечения по атрибутам 382

16. Отмена 384

Пользователи и отмена 384

Проектирование функции отмены 386

Типы и варианты отмены 387

Прочие модели для механизмов, схожих с отменой 392

Необратимые действия 398

17. Новый взгляд на файлы и операцию сохранения 399

Что не так с сохранением файлов? 400

Проблемы модели реализации 402

Модель реализации против ментальной модели 405

Прощаемся с моделью реализации 406

Проектирование с унифицированной файловой моделью 408

Являются ли диски и файловые системы важным

конструктивным элементом? 414

416

Время перемен


10 Оглавление

18. Улучшаем ввод данных 417

Целостность данных и информационный иммунитет 417

Аудит и редактирование 422

19. Указание, выделение, непосредственное

манипулирование 425

Непосредственное манипулирование  425

Устройства указания 427

Указание и курсор 437

Выделение 441

Перетаскивание 449

Манипулирование элементами управления 461

Инструменты палитры 462

Манипулирование объектами 465

Связывание объектов 474

20. Поведение окон 476

PARC и Alto 476

Принципы PARC 478

Microsoft и окна плиткой 480

Полноэкранные приложения 481

Многопанельные приложения 482

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

Состояния окон 490

MDI против SDI 491

21. Элементы управления 494

Нет окнам, перегруженным элементами управления! 494

Командные элементы управления 495

Элементы управления выбором 498

Элементы ввода 514

Элементы управления отображением 527

22. Меню 532

Немного истории 532

Современные меню: средство обучен и я 538

Необязательные меню   543

Идиомы меню   545

23. Панели инструментов  . 554

Панели инструментов: наглядные, мгновенно

исполняемые команды  . 554

Панели инструментов и меню . 555


Оглавление

Панели инструментов и элементы управления

на панелях инструментов 556

Элементы управления на панели инструментов: обучение 558

Эволюция панели инструментов 560

24. Диалоговые окна 566

Уместное применение диалоговых окон 566

Основы применения диалоговых окон 568

Модальные диалоговые окна 570

Немодальные диалоговые окна 571

Четыре назначения диалоговых окон 578

Управление содержимым диалоговых окон 586

25. Ошибки, уведомления, подтверждения 592

Диалоги сообщений об ошибках 592

Диалоговые окна уведомлений: сообщение об очевидном 602

Диалоговое окно подтверждения 605

Заменяем диалоговые окна обогащенной

немодальной обратной связью 608

26. Проектирование для различных потребностей 615

Командные векторы и рабочие наборы 615

Перевод новичков в середняки 617

Персонализация и настройка 620

Идиосинкратически модальное поведение 623

Локализация и глобализация 624

Коллекции и шаблоны 625

Справка 625

Послесловие: несколько слов о сотрудничестве 630

Приложение. Принципы проектирования 634

Библиография 640

Словарь терминов 646

Алфавитный указатель 649


Об авторах

Алан Купер - новатор в области программного обеспечения, программист, проектировщик и теоретик. Его упоминают как создателя пер-, вых серьезных деловых программ для микрокомпьютеров и часто называют «отцом языка Visual Basic». Последние 15 лет компания Алана, Cooper, занималась консультированием в области проектирования взаимодействия, помогая другим компаниям создавать новые продукты и совершенствовать поведение цифровых технологий. В компании Cooper Алан возглавлял работы по созданию новой методологии проектирования успешного программного обеспечения, которую он называет целеориентированным процессом. В ходе этой работы, в частности, появились персонажи - инструмент, получивший широкое распространение после выхода в 1998 году второй книги Алана «Психбольница в руках пациентов». Купер известен также как писатель, лектор и горячий сторонник гуманизации технологий.

Роберт Рейман посвятил последние 15 лет расширению границ цифровых продуктов в роли проектировщика, писателя, лектора и консультанта. Он возглавлял десятки проектов по проектированию взаимодействия в таких областях, как электронная коммерция, порталы, персональная производительность, среды создания контента, медицинские и научные приборы, беспроводные технологии и портативные устройства, работая как с начинающими компаниями, так и с компаниями из числа Fortune 500. В качестве главы исследовательского отдела в Cooper Рейман руководил разработкой и совершенствованием многих из целеориентированных методов, описанных в данной книге. В 2005 году Рейман стал первым президентом ассоциации проектирования взаимодействия (IxDA, www.ixda.org) - глобальной некоммерческой организации, объединяющей проектировщиков взаимодействия. В настоящий момент он отвечает за проектирование опыта взаимодействия в Bose Corporation.

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


Предисловие. Постиндустриальный мир

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

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

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

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


14

 Предисловие. Постиндустриальный мир

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

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

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

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

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

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


Предисловие, Постиндустриальный мир

 15

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

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

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

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


16 Предисловие. Постиндустриальный мир

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

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

Если вы преданы идее улучшения мира через совершенствование поведенческих аспектов цифровых продуктов и услуг, я рад приветствовать вас во вселенной целеориентированного проектирования!

Алан Купер


Благодарности

Мы хотели бы выразить свою глубочайшую признательность следующим людям, без которых не появилось бы на свет новое издание «About Pace»: Крису Уэббу (Chris Webb) из Wiley, который понял, что настало время для нового издания, Сью Купер (Sue Cooper), которая согласилась с этой мыслью, и Саре Шлейр (Sara Shlaer) из Wiley, которая терпеливо помогала нам в подготовке всех редакций этой книги. Мы хотели бы также поблагодарить наших коллег и проектировщиков из Cooper за их вклад в эту работу и в предыдущие ее воплощения: Ким Гудвин (Kim Goodwin) за серьезный вклад в разработку и описание концепций и методов, представленных на этих страницах; Ребекку Вортман (Rebecca Bortman) и Ника Майерса (Nick Myers) за пересмотр оформления книги и обложки, а также за иллюстрации; Хью Дабберли (Hugh Dubberly) за помощь в разработке принципов, приводимых в конце главы 8, и за иллюстрации к целеориентированному процессу в главе 1; Гретхен Андерсон (Gretchen Anderson), Элейн Монтгомери (Elaine Montgomery) и Дага Лемуана (Doug LeMoine) за их вклад в материал об исследованиях пользователей и рынка в главе 4; Рика Бонда (Rick Bond) за его многочисленные идеи в связи с юзабили-ти-тестированием (глава 7); Эрнеста Кинсолвинга (Ernest Kinsolving) и Йорга Берингера (Joerg Beringer) из SAP за их вклад в описание типов приложений веб-порталов в главе 9; Криса Уилдрайера (Chris Weeldreyer) за идеи по проектированию встроенных систем (глава 9); Уэйна Гринвуда (Wayne Greenwood) за вклад в тему отображения элементов управления (глава 10); Нейта Фортена (Nate Fortin) и Ника Майерса (Nick Myers) за вклад в тему визуального проектирования интерфейсов и брендинга (глава 14). Мы говорим спасибо Элизабет Бей-кон (Elizabeth Bacon), Стиву Калду (Steve Calde), Джону Даннингу (John Dunning), Дэвиду Фору (David Fore), Нейту Фортену (Nate Fortin), Ким Гудвин (Kim Goodwin), Уэйну Гринвуду (Wayne Greenwood), Ноа Гийо (Noah Guyot), Лейн Халли (Lane Halley), Эрнесту Кинсол-вингу (Ernest Kinsolving), Дэниелу Куо (Daniel Kuo), Берму Ли (Berm Lee), Дагу Лемуану (Doug LeMoine), Тиму Маккою (Tim McCoy), Элейн Монтгомери (Elaine Montgomery), Нику Майерсу (Nick Myers), Крису Нойсселу (Chris Noessel), Райану Ольшавски (Ryan Olshavsky), Анджеле Куэйл (Angela Quail), Сьюзи Томпсон (Suzy Thompson), а также Крису Уилдрайеру (Chris Weeldreyer) за их вклад в работы компании Cooper и иллюстрации, представленные в данной книге.


18

 Благодарности

Мы выражаем признательность нашим клиентам - Дэвиду Уэсту (David West) из Shared Healthcare Systems, Майку Кею (Mike Kay) и Виллу Чангу (Bill Chang) из Fujitsu Softek, Джону Чаффинсу (John Chaffins) из Crosscountry, Крису Тугуду (Chris Twogood) из Teradata и Крису Доллару (Chris Dollar) из McKesson - за разрешение использовать проекты, выполнявшиеся для них компанией Cooper, в качестве примеров в этой книге. Мы хотим также поблагодарить многих других клиентов, у которых хватило прозорливости и воображения, чтобы работать с нами и отстаивать наш подход в своих организациях.

Мы хотели бы также засвидетельствовать свое почтение следующим авторам и коллегам, чьи работы много лет служили для нас источником вдохновения и призмой для рассмотрения идей: Кристофер Алек-сандер (Christopher Alexander), Эдвард Тафт (Edward Tufte), Кевин Маллет (Kevin Mullet), Виктор Папанек (Victor Papanek), Дональд Норман (Donald Norman), Ларри Константайн (Larry Constantine), Чаллис Ходж (Challis Hodge), Шелли Ивенсон (Shelley Evenson), Клиффорд Насс (Clifford Nass), Байрон Ривз (Byron Reeves), Стивен Пинкер (Stephen Pinker) и Терри Суок (Terry Swack).

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


Введение к третьему изданию

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

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

Возьмем для примера такую простую вещь, как духовка. До наступления цифровой эры управление духовкой было весьма простым - достаточно было повернуть единственный регулятор в нужное положение. Выключенной духовке соответствовало строго одно положение, каждому из возможных температурных режимов также отвечало одно положение. Всякий раз при повороте регулятора в конкретное положение происходило одно и то же. Это можно назвать «поведением», но это определенно очень простое, механическое поведение. Сравните его с поведением современных микроволновок с микросхемами и жидкокристаллическими экранами. Они изобилуют кнопками с надписями, не имеющими отношения к приготовлению пищи: «Начать», «Отменить», «Программировать», которые соседствуют с более привычными, такими как «Запекать» и «Жарить». Угадать, что случится, если нажать какую-либо из таких кнопок, гораздо сложнее, чем в случае со старым регулятором на газовой плите. Более того, результаты нажатия любой из этих кнопок полностью зависят от текущего состояния микроволновки и того, какие кнопки были нажаты до этого. Вот что мы имеем в виду, когда говорим о сложном поведении. Появление продуктов с таким сложным поведением стало причиной рождения новой дисциплины. Проектирование взаимодействия перенимает теорию и методы из таких областей, как традиционный дизайн, юзабилити и инженерные дисциплины. Но в данном случае целое больше суммы частей и обладает собственными уникальными ме-


20 Введение к третьему изданию

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

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

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

Краткая история проектирования взаимодействия

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


Введение к третьему изданию 21

ютерами в будущем. В Xerox PARC SRI, а потом и в Apple Computer вовсю обсуждали, в чем состоит создание полезных и удобных «гуманных интерфейсов» в применении к цифровым продуктам. В середине восьмидесятых промышленные дизайнеры Билл Могридж (Bill Moggridge) и Билл Верпланк (Bill Verplank), работавшие над первым ноутбуком (GRiD Compass), предложили для описания своей работы термин проектирование взаимодействия, однако понадобилось еще десятилетие, чтобы другие проектировщики заново сформулировали это понятие и сделали его общепринятым.

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

Эти перемены произошли молниеносно благодаря всплеску популярности и лавинообразному росту Интернета. Вдруг у всех на устах оказался термин «простота использования». Традиционные дизайнеры, ваявшие цифровые продукты в краткую эпоху популярности мультимедиа в начале девяностых, дружно перебрались во Всемирную паутину. Как грибы после дождя стали появляться новые, как казалось, названия профессий, связанных с дизайном и проектированием: информационные дизайнеры (information designer), информационные архитекторы (information architect), специалисты по проектированию опыта взаимодействия (user experience strategist) и проектировщики взаимодействия (interaction designer). Впервые возникли руководящие должности, связанные с созданием ориентированных на пользователей продуктов и услуг, например директор по опыту взаимодействия (chief experience officer). Университеты быстро подхватили идею и начали предлагать программы подготовки специалистов по этим дисциплинам. Тем временем юзабилити-специалисты и профессионалы, имеющие дело с человеческим фактором, также получили право голоса и стали признанными борцами за качественное проектирование продуктов.

Хотя Всемирная паутина отшвырнула инструментарий проектирования взаимодействия более чем на десятилетие в прошлое, она, бесспор-


22

 Введение к третьему изданию

но, совершила благое дело, поместив требования пользователей в поле зрения корпораций. Со времени выхода второго издания «About Face» в 2003 году опыт, взаимодействия при общении с цифровыми продуктами стал темой первых полос таких изданий, как журналы Time и BusinessWeek, а такие организации, как Harvard Business School и Стэнфордский университет, признали, что следующее поколение управленцев и технологов должно находить проектированию взаимодействия место в своих бизнес-планах и графиках разработок - и это следует учитывать в программах их подготовки. Люди устали от «технологии ради технологии». Потребители посылают недвусмысленное сообщение: им нужна хорошая технология, то есть такая, опыт взаимодействия с которой будет подкупающе простым и приятным.

В августе 2003 года, через пять месяцев после того, как во втором издании «About Face» было провозглашено существование новой дисциплины проектирования - проектирования взаимодействия,- Брюс «Тог» Тогнаццини (Bruce «Tog» Tognazzini) обратился к зарождающемуся сообществу со страстным призывом, предложив создать некоммерческую профессиональную организацию. Короткое время спустя Чаллис Ходж (Challis Hodge), Дэвид Хеллер (David Heller), Рик Сесил (Rick Cecil) и Джим Джаррет (Jim Jarrett) создали список рассылки и организовали руководящий комитет. В сентябре 2005 года официально родилась организация IxDA - Interaction Design Association (ассоциация проектирования взаимодействия, www.ixda.org). На момент подготовки этой книги в организации уже состояло более 2000 членов из 20 с лишним стран. Нам приятно заявить, что проектирование взаимодействия наконец становится самостоятельной дисциплиной и профессией.

Почему «проектирование взаимодействия»?

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

Как мы уже говорили, проектировщики взаимодействия, заимствуя подходы из других, уже сложившихся дисциплин проектирования,


Введение к третьему изданию 23

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

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

Еще один термин, который приобрел популярность, - опыт взаимодействия (user experience, UX). Многие люди выступают за использование этого термина в качестве «зонтика», под которым объединяется множество различных дисциплин, связанных с проектированием и удобством использования продуктов, систем и услуг. Достойная и заманчивая цель, которая, однако, слабо связана с ключевой проблемой проектирования взанмодействня, обсуждаемой в этой книге: как конкретно следует проектировать поведение сложных интерактивных систем? И хотя поиск сходств и путей взаимного обогащения подходов в проектировании опыта взанмодействня для покупателя в реальном магазине н для пользователя интерактивного продукта - полезное занятие, мы считаем, что существуют особые методы, уместные именно для проектирования в цифровом мире.

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


24

 Введение к третьему изданию

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

При распространении этого подхода на цифровые продукты оказывается полезным считать, что мы воздействуем на опыт пользователей, проектируя механизмы взаимодействия с продуктом. Поэтому мы предпочли термин Могриджа проектирование взаимодействия (многими сокращаемое до IxD - от interaction design) для обозначения вида проектирования, описываемого в настоящей книге. Разумеется, во многих случаях при создании продукта требуется слаженное применение целого ряда дисциплин проектирования, чтобы дать пользователю позитивный опыт (рис. 1). Мы считаем, что именно для таких ситуаций уместен термин проектирование опыта взаимодействия.

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


Введение к третьему изданию 25

Сотрудничество с командой, создающей продукт

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

  1.  Команда проектировщиков отвечает за степень удовлетворенности
    пользователей процессом взаимодействия с продуктом. На теку
    щий момент в большинстве организаций за это никто не отвечает.
    Чтобы  нести такую ответственность,  проектировщики должны
    иметь возможность определять внешний вид продукта, его поведе
    ние и создаваемое им впечатление. Кроме того, им понадобится дос
    туп к информации: они должны наблюдать за потенциальными
    пользователями продукта, обсуждать с пользователями их потреб
    ности, с инженерами - технологические возможности и ограниче
    ния, с маркетологами - возможности и требования, а с руководст
    вом - что из себя должен представлять конечный продукт.
  2.  Команда инженеров отвечает за реализацию и производство про
    дукта. Чтобы проектирование принесло пользу, инженеры должны
    нести ответственность за воспроизведение формы и поведения про
    дукта в том виде, как это задано проектировщиками, уложившись
    при этом в бюджет и выдержав сроки. Следовательно, инженерам
    требуется ясное описание формы и поведения продукта, которое бу
    дет направлять их работу и послужит точкой отсчета при оценке за
    трат времени и средств. Такое описание должно поступать от ко
    манды проектировщиков. Инженеры должны также участвовать
    в обсуждениях технических возможностей и ограничений и оценке
    выполнимости предложенных проектировщиками решений.
  3.  Команда маркетологов несет ответственность за желание клиентов
    заказать продукт, а потому в их ведении должны находиться все ас
    пекты общения с клиентами. У них должна быть также возмож
    ность повлиять на характеристики и дизайн продукта. Для этого
    участники маркетинговой команды должны иметь доступ к инфор
    мации, включая результаты исследований проектировщиков, и рас
    полагать   возможностью   проводить   собственные   исследования.
    (Следует отметить, что клиенты и пользователи - зачастую совсем
    разные люди с разными потребностями. Мы обсудим эту тему более
    подробно в главах 4 и 5.)
  4.  


25 Введение к третьему изданию

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

Что есть и чего нет в этой книге

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

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

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


Введение к третьему изданию 27

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

Эта книга не предназначена для того, чтобы быть руководством по стилю или стандартом по интерфейсам. Более того, в главе 14 вы узнаете, почему применимость подобных инструментов ограничена весьма узким набором ситуаций. Тем не менее мы надеемся, что процессы и принципы, описанные в этой книге, станут полезным дополнением к используемым вами руководствам по стилю. Такие руководства хорошо отвечают на вопрос «что?», однако редко способны ответить на вопрос «почему?». Эта книга пытается дать ответы на вопросы второго типа.

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

Новое в третьем издании

Многое изменилось в мире проектирования интерфейсов с тех пор, как в 1995 году увидело свет первое издание этой книги. В то же время многое осталось прежним. В третьем издании мы сохранили все, что не потеряло актуальности, обновили то, что с тех пор изменилось, и включили новые материалы, которые отражают не только перемены в отрасли за последние одиннадцать лет, но и появление новых концепций, созданных авторами с учетом меняющихся требований времени. Вот некоторые серьезные изменения в «About Face 3.0»:

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


28 Введение к третьему изданию

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

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

Надеемся, что благодаря этим дополнениям и изменениям читатели смогут по-новому взглянуть на рассмотренные темы.

О примерах

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

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

Большинство примеров в этой книге взято из программ пакета Microsoft Office - Word, Excel, PowerPoint, Outlook, а также из Internet Explorer, Adobe Photoshop и Illustrator. Есть две причины, по которым мы старались использовать в качестве источника примеров эти популярные программы. Во-первых, в таком случае примеры будут, вероятно, хотя бы в минимальной степени знакомы читателям. Во-вторых, важно было продемонстрировать, что целеориентированное проектирование позволяет улучшить дизайн пользовательского интерфейса даже самых отточенных продуктов. Мы включили в книгу также некоторое количество примеров из менее распространенных приложений - там, где они были особенно показательны.

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


Введение к третьему изданию 29

Для кого эта книга

Хотя содержание книги в основном ориентировано на тех, кто занимается проектированием взаимодействия на практике либо обучается этой дисциплине, пользу от чтения книги получат все, кого заботит взаимодействие пользователей с цифровыми технологиями. Программисты, дизайнеры и проектировщики, работающие над созданием цифровых продуктов, юзабилити-споциалисты, а также руководители проектов - все они найдут что-либо полезное для себя. Читатели предыдущих изданий книги «About Face» и «The Inmates Aro Running the Asylum»1 найдут свежую и обновленную информацию о методах и принципах проектирования.

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

От редакторов перевода

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

1 А. Купер «Психбольница в руках пациентов. Почему высокие технологии сводят нас с ума и как восстановить душовное равновесие», дополненное издание. - Пер. с англ. - СПб: Символ-Плюс, 2009.


30

 Введение к третьему изданию

щать уточнения к книге и новости мира проектировщиков, обсуждать термины, до хрипоты спорить о принципах... Мы сделали это и приглашаем вас в гости. Наш адрес http://aboutface.gut.ru.

Вселенная проектирования взаимодействия еще так молода, что вы можете успеть в ряды ее демиургов!


I

Введение в целеориентированное

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

Глава 1. Проектирование, ориентированное на цели

Глава 2. Модели реализации и ментальные модели

Глава 3. Новички, эксперты и середняки

Глава 4. Как понять пользователей: качественные исследования

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

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

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


1

Проектирование, ориентированное на цели

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

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

Цифровым продуктам необходимы

более качественные методы проектирования

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

Проектирование, по мнению промышленного дизайнера Виктора Па-панека (Victor Papanek), есть сознательные и интуитивные усилия

2 3ак. 1494


34 Глава 1. Проектирование, ориентированное на цели

по созданию значимого порядка.1 Мы предлагаем несколько более подробное определение проектирования, ориентированного на людей:

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

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

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

Современное проектирование цифровых продуктов

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

В. Папанек «Дизайн для реального мира». - Пер. с англ. - М..  Л. Aронов


2008.


Цифровым продуктам необходимы более качеавенные методы проектирования

 35

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

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

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

Имеется в виду английская пословица You can put lipstick on a pig, but it's still a pig (Свинья есть свинья, сколько ее ни крась). - Примеч. перев.


36

 Глава 1. Проектирование, ориентированное на цели

Рис. 1.1. Эволюция процесса разработки программного обеспечения. На первой диаграмме отражены ранние дни индустрии программного обеспечения, когда умные программисты вынашивали идею продукта, а затем создавали и самостоятельно тестировали его. Разумеется, на каком-то этапе в процесс встроились профессиональные управленцы, которые помогали переводить благоприятные рыночные возможности на язык требований к продукту. Как видно из третьей диаграммы, индустрия повзрослела, и тестирование превратилось в самостоятельную дисциплину, а с распространением графических пользовательских интерфейсов (graphical user interface, GUI) к процессу подключились графические дизайнеры, которые создавали пиктограммы и прочие визуальные элементы. На последней диаграмме отражен целеориентированный подход к разработке программного обеспечения, когда решения о возможностях продукта, его форме и поведении принимаются до начала дорогостоящей и сложной фазы создания продукта

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

Цифровые продукты грубы

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


Цифровым продуктам необходимы более качественные методы проектирования        37

Внимание! Не удалось уведомить библиотеку.

Рис. 1.2. Замечательно, спасибо за откровенность. Почему программа не уведомила библиотеку? О чем она хотела уведомить эту библиотеку? Почему она говорит об этом нам? С чем мы вообще соглашаемся? С какой стати сбой в программе - это «ОК»?

Программы часто допрашивают пользователя, засыпая его маловразумительными вопросами, на которые пользователь не готов или не склонен отвечать: «Куда ты подевал этот файл?» Снисходительные вопросы, вроде «Вы уверены?» и «Вы действительно хотите удалить этот файл или нажали на клавишу Delete по другой причине?», равно унизительны и неприятны.

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

Цифровые продукты навязывают людям компьютерный стиль мышления

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

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


38 Глава 1. Проектирование, ориентированное на цели

вателей («Сколько стоповых битов?»), а иногда и для специалистов («Пожалуйста, укажите IRQ»).

Цифровые продукты ведут себя неподобающим образом

Если бы десятилетний ребенок вел себя так же, как некоторые программы или устройства, его бы заперли в детской и оставили без ужина. Программы забывают закрывать за собой дверь холодильника, оставляют ботинки на ковре посреди комнаты и не способны вспомнить то, что вы говорили им каких-то пять минут назад. К примеру, если вы сохраните документ Microsoft Word, распечатаете его, а затем попытаетесь закрыть, программа снова спросит, желаете ли вы сохранить документ! Очевидно, печать документа заставила программу думать, что документ изменился, хотя этого не произошло. «Не, мам, я тебя не слышал!»

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

Цифровые продукты заставляют человека делать рутинную работу

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

Почему эти продукты столь плохи?

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


Цифровым продуктам необходимы более качественные методы проектирования        39

Отсутствие представления о пользователях

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

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

Конфликт интересов

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

Отсутствие процесса

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


40 Глава 1. Проектирование, ориентированное на цели

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

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

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

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


Эволюция проектирования в промышленности

 41

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

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

Эволюция проектирования в промышленности

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

Сознательное включение проектирования в процесс создания продуктов возвестило о восхождении современной триады задач разработки, озвученных Ларри Кили (Larry Keeley) из Дублинской группы: осуществимость, жизнеспособность, желанность (рис. 1.3). Если один из этих трех столпов значительно слабее двух других, продукт вряд ли выдержит испытание временем.

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


42

 Глава 1. Проектирование, ориентированное на цели

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


Планирование и проектирование поведения 43

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

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

Планирование и проектирование поведения

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

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


44 Глава 1. Проектирование, ориентированное на цели

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

Выявление целей пользователей

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

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

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

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

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

  1.  заставляют пользователей чувствовать себя идиотами;
  2.  заставляют пользователей совершать серьезные ошибки;
  3.  требуют слишком больших трудозатрат для эффективной работы;
  4.  не делают опыт пользователя интересным и приятным.
  5.  


Выявление целей пользователей 45

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

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

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

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

Цели, задачи, деятельность

Цели - не то же самое, что задачи или деятельность. Цель - это предвосхищение конечного состояния, тогда как задачи и деятельность являются лишь промежуточными этапами (на различных уровнях организации), необходимыми для достижения целей. В иерархии, описанной Дональдом Норманом (Donald Norman), деятельность включает задачи, которые состоят из действий, в свою очередь составленных из операций. При помощи этой схемы Норман пропагандирует проектирование, ориентированное на деятельность (Activity-Centered Design, ACD), - подход, в котором внимание уделяется прежде всего пониманию деятельности. Норман утверждает, что человек приспосабливается к имеющимся инструментам и что понимание деятельности, выполняемой человеком при помощи инструментов, может положительно сказываться на дизайне этих инструментов. В основе рассуждений Нормана лежит теория деятельности - советская психологическая теория1, рассматривающая человека через призму того,

Теория деятельности выдвинута советским психологом А. Н. Леонтьевым. Примеч. ред.


46 Глава 1. Проектирование, ориентированное на цели

как он взаимодействует с окружающим миром, и в последние годы получившая применение в области изучения взаимодействия людей и компьютеров - в основном благодаря Бонни Нарди (Bonnie Nardi). Норман делает верный вывод о том, что традиционный подход, сосредоточенный на задачах, при проектировании цифровых продуктов дает неадекватные результаты. Многие разработчики и специалисты по юзабилити по-прежнему начинают проектирование с вопроса: «Каковы задачи?» И хотя работу таким образом сделать можно, результат улучшится максимум на один балл, не станет тем решением, которое выделяет ваш продукт на рынке, и зачастую не будет по-настоящему удовлетворять пользователей.

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

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

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


Выявление целей пользователей 47

\ ' '

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

Проектирование с учетом целей в определенном контексте

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

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

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

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

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


48 Глава 1. Проектирование, ориентированное на цели

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

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

Целеориентированныи процесс проектирования

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

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


Целеориентированный процесс проектирования 49

Мост через пропасть

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

Проектирование как процесс определения продукта

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

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

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

Одна из проблем существующего процесса разработки состоит в том, что роли участников чрезмерно узки: исследователи исследуют, а проектировщики проектируют (рис. 1.4). Результаты исследований поль-

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


50 Глава 1. Проектирование, ориентированное на цели

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

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

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

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

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

От исследований к проектированию: модели, требования, инфраструктура

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

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


Целеориентированный процесс проектирования

 51

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

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

Рис. 1.5. Процесс целеориентированного проектирования

Обзор процесса

Целеориентированное проектирование сочетает в себе методы этнографии, интервью с заинтересованными в проекте лицами, маркетинговые исследования, моделирование пользователей, проектирование на основе сценариев, а также базовый набор принципов и шаблонов проектирования взаимодействия. Оно позволяет создавать решения, соответствующие потребностям и целям пользователей с одной стороны, а также бизнес-требованиям и технологическим ограничениям - с другой. Процесс можно грубо разделить на шесть стадий: исследования, моделирование, выработка требований, определение общей инфраструктуры, детализация и сопровождение (рис. 1.5). Эти стадии соответствуют пяти видам деятельности, составляющим процесс проектирования взаимодействия согласно Джиллиан Крэмптон Смит (Gillian Crampton Smith) и Филипу Тэйбору (Philip Tabor), - понимание, абстрагирование, структурирование, отображение, детализация, - но с более выраженным акцентом на моделировании поведения пользователей и определении поведения систем.


52 Глава 1. Проектирование, ориентированное на цели

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

Исследования

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

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

В главе 4 приводится более подробная информация о целеориентиро-ванных методах исследований.

Моделирование

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


Целеориентированный процесс проектирования

 53

Рис. 1.6. Процесс целеориентированного проектирования в деталях


54 Глава 1. Проектирование, ориентированное на цели

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

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

Подробно о персонажах и разработке целей мы поговорим в главе 5.

Выработка требований

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

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


Целеориентированный процесс проектирования 55

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

Определение инфраструктуры

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

Второй важнейший методологический инструмент - это набор шаблонов проектирования взаимодействия, являющихся решением (вариации здесь зависят от контекста) для соответствующих типов когда-то проанализированных проблем. Принципиально эти шаблоны очень похожи на шаблоны архитектурного проектирования, созданные Кристофером Александером (Christopher Alexander). Позже Эрих Гамма (Erich Gamma) и его коллеги познакомили с шаблонами проектирования и отрасль программирования. Шаблоны проектирования взаимодействия выстроены в иерархию и эволюционируют с появлением новых контекстов. Их функция - не загнать творчество проектировщика в рамки, а дать ему точку опоры для решения сложных задач, снабдив проверенными знаниями о проектировании.

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


56 Глава 1. Проектирование, ориентированное на цели

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

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

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

Детализация

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

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


Целеориентированный процесс проектирования 57

Сопровождение разработки

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

Ключ к успеху продукта - цели, а не возможности

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

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

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

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


58 Глава 1. Проектирование, ориентированное на цели

  ПРИНЦИП проектирования

 Проектирование взаимодействия - не гадание на кофейной гуще.

Целеориентированное проектирование - мощный инструмент, отвечающий на самые важные вопросы, которые возникают при описании и проектировании цифрового продукта:

  1.  Кем являются мои пользователи?
  2.  Чего пытаются достичь мои пользователи?
  3.  Что мои пользователи думают о своих целях сами?
  4.  Какого рода опыт будет для моих пользователей привлекательным
    и полезным?
  5.  Как должен себя вести мой продукт?
  6.  Как должен выглядеть мой продукт?
  7.  Как пользователи будут взаимодействовать с моим продуктом?
  8.  Как наиболее эффективно реализовать функции моего продукта?
  9.  Как начинающие пользователи будут знакомиться с моим продук
    том?
  10.  Каким образом мой продукт сможет придать технологии привлека
    тельный облик и сделать ее понятной и управляемой?
  11.  Как мой продукт может решить проблемы пользователей?
  12.  Как мой продукт поможет в достижении целей тем пользователям,
    которые редко работают с продуктом или имеют мало опыта?
  13.  Каким образом мой продукт сможет удовлетворить запросы опыт
    ных пользователей, которым нужна функциональная мощь и глу
    бина проработки?

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


2

Модели реализации и ментальные модели

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

Модели реализации

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


60 Глава 2. Модели реализации и ментальные модели

Норман (Norman, 1989) и другие называют системной моделью; мы предпочитаем термин модель реализации, поскольку такая модель описывает подробности реализации программы в коде.

Пользовательские ментальные модели

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

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

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

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


Модели представления 61

Модели представления

Лицом программного или цифрового продукта, как его видят люди, является его поведение, создаваемое программистом или проектировщиком. Это представление вовсе не должно быть точным описанием того, что происходит внутри компьютера, но, к несчастью, зачастую именно им и является. Возможность демонстрировать функционирование компьютера в отрыве от производимых им в реальности действий проявляется в программном обеспечении сильнее, чем в любой другой среде. Она позволяет сообразительному проектировщику скрывать некоторые из наиболее малопривлекательных особенностей того, как программа выполняет свою работу. Этот разрыв между реализацией и предлагаемым объяснением служит источником третьей модели, возникающей в цифровом мире, - модели представления. Модель представления - это избранный проектировщиком способ предъявления пользователю функционирования программы. Дональд Норман (Norman, 1989) называет это просто моделью проектирования.

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

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

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


62 Глава 2. Модели реализации и ментальные модели

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

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

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

ПРИНЦИП проектирования

 Пользовательский интерфейс должен следовать пользовательской ментальной модели, а не модели реализации.

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


Модели представления

 63

Рис. 2.2. Adobe Photoshop дает замечательный пример интерфейса, основанного на пользовательской ментальной модели. Диалоговое окно Варианты (Variations) предлагает набор миниатюр, варьирующихся по цветовому балансу и яркости с регулируемым шагом. Пользователю достаточно щелкнуть по миниатюре, наиболее точно представляющей желаемую коррекцию цвета. Выбранное изображение становится точкой отсчета для новых вариантов. Этот интерфейс следует ментальной модели художника, которому требуется получить определенный конечный вид изображения, а не набор абстрактных чисел

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

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

  ПРИНЦИП проектирования I

 Целеориентированное взаимодействие отражает пользовательские ментальные модели.


64 Глава 2. Модели реализации и ментальные модели

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

Большинство программных продуктов следуют модели реализации

Программу, которая отражает собственную модель реализации, спроектировать существенно легче: по кнопке на каждую функцию, по полю на каждую порцию входных данных, по странице на каждый шаг транзакции, по диалоговому окну на каждый модуль кода... совершенно логично с точки зрения разработчика. Адекватно отражая инфраструктуру инженерной деятельности, такой подход, однако, слабо помогает создавать целостные механизмы для достижения пользователями своих целей. Результатом становится интерфейс, отталкивающий и запутывающий пользователя, - примерно как вездесущая паутина труб из фильма-антиутопии Терри Гиллиама (Terry Gilliam) «Бразилия» (фильм, полный замечательных и остроумных примеров ужасных интерфейсов).

Интерфейсы, спроектированные инженерами, следуют модели реализации

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


Большинство программных продуктов следуют модели реализации 65

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

Даже интерфейс Windows временами соскальзывает к модели реализации. Если перетащить мышью файл из одной папки в другую в пределах одного жесткого диска1, система интерпретирует это как команду «Переместить», то есть файл удаляется из первой папки и попадает во вторую, что хорошо соответствует ментальной модели. Однако перетаскивание файла с диска С на диск D будет воспринято как команда «Копировать», то есть файл будет добавлен во вторую папку, но не будет удален из первой. Истоки этого поведения находятся в модели реализации - в том, каким образом работает файловая система. При перемещении файла из одной папки в другую в пределах одного диска операционная система всего лишь переносит запись имени файла в таблице размещения файлов. Стирания и повторной записи файла при этом не происходит. Однако перенос файла на другой диск требует физического копирования данных на целевой диск. Чтобы соответствовать ментальной модели пользователя, система должна после копирования удалить оригинал, хотя это и противоречит модели реализации.

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

Более точно - в пределах одного логического раздела жесткого диска. -Примеч. ред.

ЗЗак. N94


56 Глава 2. Модели реализации и ментальные модели

Математическое мышление приводит к созданию интерфейсов, следующих модели реализации

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

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

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

принцип         Пользователи не понимают булеву алгебру.

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

Например, одним из наиболее надежных и полезных инструментов в арсенале программиста является булева алгебра. Это компактная математическая система, удобно описывающая поведение сугубо двоичной вселенной любого компьютера. В булевой алгебре есть лишь две основных операции: И (AND) и ИЛИ (OR). Сложность в том, что в естественном языке есть слова «и» и «или», которые людьми, не связанными с программированием, обычно трактуются ровно противоположным образом, нежели булевы И и ИЛИ. Если программа использует для общения булеву нотацию, следует ожидать, что пользователь проинтерпретирует ее неверно.

Например, эта проблема часто возникает при обращении к базам данных. Если из файла со списком сотрудников требуется извлечь тех, кто живет в Аризоне, вместе с теми, кто живет в Техасе, человеку мы скажем: «Найди всех моих сотрудников в Аризоне и Техасе». Чтобы правильно объяснить то же самое базе данных на языке булевой алгебры, мы должны сказать: «Найди сотрудников в Аризоне ИЛИ Техасе». Ни один сотрудник не живет сразу в двух штатах, поэтому фраза


Модели представления механической и информационной эры 67

«Найди сотрудников в Аризоне И Техасе» просто не имеет смысла. В булевой системе она практически всегда вернет пустое множество в качестве ответа.

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

Модели представления механической и информационной эры

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

Представления механической эры

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

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


53 ' Глава 2. Модели реализации и ментальные модели

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

Новая технология требует новых представлений

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

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

Представления механической эры ухудшают качество взаимодействия с пользователем

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


Модели представления механической и информационной эры 69

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

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

  принцип

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

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

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

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


70 Глава 2. Модели реализации и ментальные модели

Совершенствуем представления механической эры: пример

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

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

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

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

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

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


Модели представления механической и информационной эры

71

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

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

 принцип

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

 Существенные изменения должны приносить значительные улучшения.

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


72

 Глава 2. Модели реализации и ментальные модели

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


3

Новички, эксперты и середняки

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

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

Вечные середняки

Большинство пользователей - не начинающие и не эксперты; они середняки.


74

 Глава 3. Новички,эксперты и середняки

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

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

Рис. 3.1. Требования, предъявляемые пользователями к цифровым продуктам, очень сильно зависят от их опыта

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


Вечные середняки . 75

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

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

Те, кто находится в левой части кривой распределения, либо смещаются к центральной части «колокола», либо полностью исчезают с графика и ищут себе такой продукт или род деятельности, который позволит им стать середняками. Таким образом, большинство пользователей постоянно обладают адекватными навыками и стремятся к их совершенствованию, а их навыки уходят и вновь возвращаются подобно приливу и отливу, в зависимости от того, как часто они работают с программой. Первым важность проектирования для середняков отметил Ларри Константайн. В своей книге «Software for Use»1 (Constantine, 2004) он называет таких пользователей совершенствующимися середняками (improving intermediates). Авторы этой книги предпочитают термин вечные середняки, ибо хотя начинающие быстро переходят в разряд середняков, они редко продвигаются дальше и становятся экспертами.

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

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

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

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

Л. Константайн, Л. Локвуд  «Разработка программного обеспечения». -Пер. с англ. - СПб: Питер, 2004.


76 Глава 3. Новички, эксперты и середняки

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

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

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

Проектирование для пользователей с различной подготовкой

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


Проектирование для пользователей с различной подготовкой 77

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

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

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

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

принцип        Оптимизируйте для середняков.

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

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

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


78 Глава 3. Новички, эксперты и середняки

Что нужно начинающим

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

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

Считайте пользователей людьми очень умными, но очень

принцип         занятыми.

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

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

Встречаем новичков

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


Проектирование для пользователей с различной подготовкой 79

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

Стандартная встроенная справка - неподходящий способ поддержки начинающих. Более подробно о справочной системе мы поговорим в главе 26, но сейчас стоит сказать, что ее основное назначение - быть источником справочной информации, а начинающим нужна не справочная информация, им нужна обзорная информация, такая как «Знакомство с программой» (guided tour).

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

Новички часто полагаются на меню при изучении и исполнении команд (в главе 22 мы подробно обсудим, почему это так). Каким бы медленным и тяжеловесным инструментом ни были меню- они полны и подробны, и это дает чувство уверенности. Открываемые командами меню диалоговые окна (если таковые имеются) также должны содержать (краткие) пояснения и удобную кнопку отмены (Cancel).

Что нужно экспертам

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

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

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


80 Глава 3. Новички, эксперты и середняки

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

Что нужно вечным середнякам

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

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

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

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

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


4

Как понять пользователей: качественные исследования

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

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

Качественные и количественные исследования

Слово «исследование» у большинства людей ассоциируется с научностью подхода и объективностью. Такие ассоциации не то чтобы непра-


82 Глава 4. Как понять пользователей: качественные исследования

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

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

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

Значение качественных исследований

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

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


Качественные и количественные исследования 83

• способы применения существующих продуктов.

Качественные исследования могут также способствовать ходу проектирования, поскольку:

  1.  обеспечивают доверие и уважение к команде проектировщиков (так
    как источник проектных решений можно проследить вплоть до ре
    зультатов исследований);
  2.  объединяют команду разрабатываемого продукта общим для всех
    пониманием особенностей предметной области и проблем пользова
    телей;
  3.  дают руководителям возможность принимать решения по тем или
    иным вопросам проектирования продукта на основе данных - вме
    сто догадок и личных предпочтений.

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

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

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

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


84 Глава 4. Как понять пользователей: качественные исследования

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

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

Виды качественных исследований

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

  1.  интервьюирование заинтересованных лиц;
  2.  интервьюирование экспертов в предметной области (ЭПО);
  3.  интервьюирование пользователей и покупателей;
  4.  наблюдение за пользователями/этнографические полевые исследо
    вания;
  5.  обзор литературы;
  6.  аудит продукта/прототипа и конкурирующих решений.

Интервьюирование заинтересованных лиц

Исследование, предваряющее проектирование любого нового продукта, должно начинаться с получения представления о техническом окружении и бизнес-контексте продукта. Практически всегда продукт проектируется (или перепроектируется) для достижения одной или нескольких конкретных бизнес-целей (как правило, речь идет об извлечении прибыли). Обязанность проектировщиков - создавать решения, не теряя из виду эти бизнес-цели, поэтому крайне важно, чтобы команда проектировщиков начинала работу с изучения возможностей и ограничений, стоящих за краткой спецификацией проекта. Как метко замечает Дональд Шён (Donald Schbn), «проектирование-это общение с материалом» (Schon and Bennett, 1996). Чтобы проектировщик смог предложить подходящее решение, он должен понимать


Качественные и количественные исследования 85

возможности и ограничения «материала», используемого для создания продукта, будь то строки кода или формованный пластик.

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

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

От заинтересованных лиц важно получить информацию по следующим вопросам:

  1.  Предварительное видение продукта. Может обнаружиться, что,
    как в притче о слоне и слепых мудрецах, каждый из отделов обла
    дает отличным от других и несколько ограниченным представлени
    ем о проектируемом продукте, так что часть усилий в процессе про
    ектирования придется направить на гармонизацию этих представ
    лений с представлениями пользователей и покупателей.
  2.  Бюджет и график проекта. Обсуждение этой темы часто помогает
    проверить адекватность масштабов планируемых работ по проекти
    рованию. Эти данные являются основой для принятия решений
    в тех случаях, когда исследования пользовательской аудитории по
    казывают, что требуется больший (или, наоборот, меньший) мас
    штаб работ.
  3.  Технические возможности и ограничения. Еще один важный фак
    тор, определяющий рамки проектирования, - четкое понимание то
    го, какие технические возможности есть в распоряжении команды
    при имеющемся бюджете, сроках и технологических ограничениях.
    Часто бывает также, что продукт создается для зарабатывания де-
  4.  


86 Глава 4. Как понять пользователей: качественные исследования

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

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

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

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

Интервьюирование экспертов в предметной области (ЭПО)

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


Качественные и количественные исследования 87

тировщикам следует проявлять осторожность и понимать, что точка зрения ЭПО в определенном смысле искажена. Вот некоторые из вещей, которые следует знать о работе с ЭПО:

  1.  ЭПО — это зачастую пользователи-эксперты. Длительный опыт ра
    боты с продуктом или в предметной области продукта означает, что
    они могли привыкнуть к существующим интерфейсам. Они также
    могут предпочитать профессиональные инструменты инструмен
    там, спроектированным для вечных середняков. Часто ЭПО уже не
    являются пользователями продукта и смотрят на вещи скорее с точ
    ки зрения менеджера.
  2.  ЭПО хорошо осведомлены, но они не проектировщики. У них мо
    жет быть множество идей о том, как улучшить продукт. Некоторые
    из идей могут быть верными и ценными, однако наиболее полезная
    часть информации, содержащейся в их предложениях, - это исход
    ные проблемы, побуждающие ЭПО предлагать такие решения. Как
    и в случае с пользователями, получив рацпредложение, спросите:
    «Как это поможет вам или пользователям?»
  3.  ЭПО необходимы в сложных или специализированных предмет
    ных областях, таких как медицина, наука или финансовые службы.
    Когда вы проектируете продукт для технической или какой-либо
    другой специализированной предметной области, вам, вероятно, по
    требуются советы ЭПО, если вы сами не являетесь таковым. Обра
    щайтесь к ЭПО за информацией об имеющихся нормах и о зареко
    мендовавших себя на практике подходах. Знания ЭПО о пользова
    тельских ролях и характеристиках имеют критическое значение при
    планировании исследования пользовательской аудитории в слож
    ных предметных областях.
  4.  Вам понадобится общаться с ЭПО в течение всего процесса проекти
    рования. Если предметная область продукта требует работы с ЭПО,
    у вас должна быть возможность обращаться к ним на различных
    стадиях проектирования, чтобы проверять интерфейсные решения
    на соответствие реальной деятельности. Не забудьте договориться
    о такой возможности на первых же интервью.

Интервьюирование покупателей

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

Покупатели продукта - это люди, принимающие решение о его приобретении. Если речь идет о потребительских продуктах, покупатели за-


88 Глава 4. Как понять пользователей: качеавенные исследования

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

В интервью с покупателями вам необходимо понять:

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

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

Интервьюирование пользователей

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

Мы заинтересованы в том, чтобы получить от пользователей следующую информацию:

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


Качественные и количественные исследования 89

  1.  осведомленность в предметной области с точки зрения пользовате
    ля - что необходимо знать пользователям, чтобы делать свою работу;
  2.  существующие задачи и виды деятельности - как те, которые вы
    полняются при помощи данного продукта, так и те, которые не под
    держиваются им;
  3.  цели и мотивы использования продукта;
  4.  ментальная модель - как пользователи думают о своей работе и дея
    тельности, а также чего они ожидают от продукта;
  5.  проблемы и сложности при работе с продуктом (или с аналогичной
    системой, если продукт еще не создан).

Наблюдение за пользователями

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

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

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

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


90 Глава 4. Как понять пользователей: качественные исследования

Обзор литературы

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

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

Аудит продукта и конкурирующих решений

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

Этнографические интервью: интервьюирование и наблюдение за пользователями

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

Хью Бейер (Hugh Beyer) и Карен Хольцблат (Karen Holtzblatt) создали технику проведения этнографического интервью, которую они назы-


Этнографические интервью: интервьюирование и наблюдение за пользователями       91

вают контекстным исследованием (Contextual Inquiry). Их методика быстро и заслуженно получила широкое распространение в отрасли и является хорошей основой для качественных исследований пользовательской аудитории. Она подробно описывается в первых четырех главах их книги «Contextual Design»1 (Beyer and Holtzblatt, 1998). Методика контекстного исследования по своей сути близка к описываемым здесь методикам, однако имеются тонкие и важные различия.

Контекстное исследование

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

  1.  Контекст. Вместо того чтобы проводить интервью в чистой белой
    комнате, следует взаимодействовать с пользователями и наблюдать
    за ними в естественной рабочей среде или в ином уместном для дан
    ного продукта физическом контексте. Наблюдение за пользовате
    лями, когда они заняты своей деятельностью, и расспросы, проис
    ходящие в привычном для них окружении с множеством артефак
    тов, используемых ими ежедневно, помогают извлечь на поверх
    ность самые важные особенности их поведения.
  2.  Сотрудничество. Интервью и наблюдение должны иметь характер
    совместного с пользователем исследования, в котором наблюдение
    деятельности перемежается обсуждением ее структуры и тонкостей.
  3.  Интерпретация. Работа проектировщика в большой степени сво
    дится к выявлению того, что стоит за словами и поведением пользо
    вателей и особенностями их среды обитания. Задача проектиров
    щика - рассмотреть собранные данные как единое целое и рас
    крыть то влияние, которое они должны оказать на проектирование.
    При этом интервьюер, однако, должен проявлять осторожность
    и не выдвигать предположений, основанных на собственной интер
    претации фактов, не проверив эти предположения вместе с пользо
    вателями.
  4.  Направленность. Вместо того чтобы жестко придерживаться зара
    нее составленного опросника или, наоборот, отпускать интервью
    «в свободное плавание»,  проектировщик должен аккуратно на
    правлять ход беседы в поисках данных, имеющих отношение
    к во
    просам проектирования.

Стоит также обратить внимание на книгу, написанную при участии Карен Хольцблат: «Rapid Contextual Design». - Примеч. науч.ред.


92 Глава 4. Как понять пользователей: качественные исследования

Усовершенствование контекстного исследования

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

  1.  Сокращение продолжительности интервью. Контекстное исследо
    вание предполагает, что интервью с пользователем длится целый
    день. Авторы выяснили, что для сбора необходимых данных доста
    точно даже часовой беседы при условии, что запланировано доста
    точное количество интервью (около шести вдумчиво выбранных
    пользователей на каждую гипотетическую роль или тип). Гораздо
    легче и продуктивнее сделать более разнообразную выборку пользо
    вателей, которые согласятся провести с проектировщиком по часу,
    чем найти пользователей, которые согласятся потратить на интер
    вью целый день.
  2.  Использование компактной команды проектировщиков. Контекст
    ное исследование подразумевает наличие большой команды проек
    тировщиков, проводящей параллельно сразу несколько интервью,
    за которыми следует специальное совещание (дебрифинг) с участи
    ем всей команды. Мы обнаружили, что более эффективно проводить
    сессии интервью последовательно с участием одних и тех же проек
    тировщиков. Тем самым размер команды остается небольшим (два
    или три человека) и, что гораздо важнее, вся команда получает воз
    можность напрямую взаимодействовать с каждым из интервьюи
    руемых пользователей, что позволяет ее членам максимально эф
    фективно анализировать и синтезировать собранные данные.
  3.  Определение целей в самом начале. Контекстное исследование, как
    оно описано Бейером и Хольцблат, рассчитано на процесс проекти
    рования, принципиально ориентированный на задачи. При прове
    дении этнографических интервью мы предлагаем прежде всего вы
    являть цели пользователей и назначать им приоритеты, и только
    затем приступать к выяснению того, какие задачи соответствуют
    этим целям.
  4.  Выход за пределы бизнес-контекста. Лексикон контекстного ис
    следования рассчитан на проектирование бизнес-продуктов, ис
    пользуемых в корпоративной среде. Проведение этнографических
    интервью возможно также и для потребительских продуктов, хотя,
    как будет видно в дальнейшем, направленность вопросов в этом
    случае становится несколько иной.

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


Этнографические интервью: интервьюирование и наблюдение за пользователями      93

Подготовка к этнографическим интервью

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

Выявление кандидатов

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

Построение гипотезы о персонажах

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

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

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


94 Глава 4. Как понять пользователей: качественные исследования

Гипотеза о персонажах пытается дать общие ответы на следующие три вопроса:

  1.  Каковы категории людей, которые могут использовать данный про
    дукт?
  2.  Как могут различаться их потребности и поведение?
  3.  Какие шаблоны поведения и типы рабочей обстановки необходимо
    изучить?

Роли для корпоративных и потребительских рынков

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

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

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

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

Поведенческие и демографические переменные

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


Этнографические интервью: интервьюирование и наблюдение за пользователями      95

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

  1.  частота совершения покупок (часто - нечасто);
  2.  стремление делать покупки (обожает покупать - ненавидит поку
    пать);
  3.  мотивация для совершения покупок (поиск наилучшего по цене
    предложения - поиск наиболее подходящей вещи).

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

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

Компетентность в предметной области и техническая компетентность

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


96 Глава 4. Как понять пользователей: качественные исследования

Соображения, касающиеся рабочей среды

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

  1.  размер компании (малая-транснациональная);
  2.  география компании (Северная Америка, Европа, Азия и т. д.);
  3.  отрасль/сектор (производство электроники, товары массового по
    требления и т. п.);
  4.  использование информационных технологий (применяются произ
    вольно - имеются «драконовские» стандарты);
  5.  уровень обеспечения безопасности (низкий - высокий).

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

Планирование

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

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

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


Этнографические интервью: интервьюирование и наблюдение за пользователями      97

Проведение этнографических интервью

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

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

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

Команды интервьюеров и координация

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

Фазы этнографических интервью

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

4 Зак. 1494


98 Глава 4. Как понять пользователей: качественные исследования

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

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

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

Основные приемы

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

  1.  Проводите интервью там, где происходит взаимодействие пользова
    теля с продуктом.
  2.  Избегайте жесткого следования предопределенным наборам вопро-

сов.

Сначала концентрируйтесь на целях - и лишь потом на задачах.


Этнографические интервью: интервьюирование и наблюдение за пользователями      99

  1.  Не делайте из пользователя проектировщика.
  2.  Избегайте дискуссий по технологическим вопросам.
  3.  Поощряйте пользователей рассказывать истории.
  4.  Просите показывать и рассказывать.
  5.  Избегайте наводящих вопросов.

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

Проводите интервью там, где происходит взаимодействие пользователя с продуктом

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

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

Избегайте жесткого следования предопределенным наборам вопросов

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


100 Глава 4. Как понять пользователей: качеавенные исследования

Вот некоторые заслуживающие внимания целеориентированные вопросы:

  1.  Цели: что делает ваш день хорошим? а плохим?
  2.  Возможности: какие виды деятельности сейчас отнимают у вас
    время?
  3.  Приоритеты: что для вас наиболее важно?
  4.  Информация: что помогает вам принимать решения?

Другой полезный тип вопросов - системоориентированные вопросы:

  1.  Функция: что вы чаще всего делаете при помощи этого продукта?
  2.  Частота: какими модулями продукта вы пользуетесь чаще всего?
  3.  Предпочтения: какие стороны этого продукта вам особенно полю
    бились? что вызывает восхищение?
  4.  Отказы системы: как вы справляетесь с проблемами в функцио
    нировании системы?
  5.  Профессиональность: какие приемы вы используете для ускоре
    ния работы?

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

  1.  Процесс: что вы сделали сегодня на работе первым делом? а что по
    сле этого?
  2.  Повторяющиеся действия и их регулярность: как часто вы это де
    лаете? что вы делаете еженедельно и каждый месяц, но не каждый
    день?
  3.  Исключения: каков типичный рабочий день? что стало бы необыч
    ным событием?

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

  1.  Устремления: чем бы вы хотели заниматься через пять лет?
  2.  Избегание: что вы предпочли бы не делать? что откладываете?
  3.  Мотивация: что вам больше всего нравится в вашей работе (или
    жизни)? какие вопросы вы всегда решаете в первую очередь?

Сначала концентрируйтесь на целях - и лишь потом на задачах

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


Этнографические интервью: интервьюирование и наблюдение за пользователями     101

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

Не делайте из пользователя проектировщика

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

Избегайте дискуссий по технологическим вопросам

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

Поощряйте пользователей рассказывать истории

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

Просите показывать и рассказывать

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


102 Глава 4. Как понять пользователей: качественные исследования

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

Избегайте наводящих вопросов

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

  1.  Вам бы помогла функция X?
  2.  Вам нравится X, верно?
  3.  Как вы думаете, стали бы вы пользоваться X, если бы она была дос
    тупна?

После интервью

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

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

Прочие виды исследований

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


Прочие виды исследований

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

Книга Майка Кунявски (Mike Kuniavsky) «Observing the User Experience» (Kuniavsky, 2003) может послужить отличным путеводителем по разнообразным методам исследования пользователей, применимым на различных стадиях процесса проектирования и разработки. В оставшейся части главы мы рассмотрим лишь некоторые наиболее заметные методы исследований и их вклад в процесс разработки.

Фокус-группы

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

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


104 Глава 4. Как понять пользователей: качественные исследования

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

Демография рынка и сегменты рынка

Маркетинг как род деятельности существенно преуспел в систематическом выявлении стимулов, побуждающих людей покупать. Одним из наиболее мощных инструментов в этой области является сегментирование рынка, разделяющее потенциальных потребителей на классы по демографическим признакам (возраст, пол, уровень образования, почтовый индекс и т. п.) на основании данных фокус-групп и исследований рынка, чтобы определить те группы потребителей, которые будут наиболее восприимчивы к определенному продукту или рекламному сообщению. Более сложные модели пользовательских данных включают также психографические и поведенческие переменные, такие как взгляды и привычки, стиль жизни, ценности, идеология, стремление к стабильности, шаблоны принятия решений. Такие системы классификации, как сегментация VALS (SRI) и геодемографические кластеры PRIZM Джонатана Робина (Jonathan Robbin), способны привнести существенную ясность в данные, предсказывая покупательские способности потребителей, мотивацию, степень ориентации на себя, ресурсы.

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


Прочие виды исследований 105

очень важным углом зрения. Различия между моделями сегментирования и пользовательскими моделями мы рассмотрим более подробно в главе 5.

Юзабилити и пользовательское тестирование

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

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

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

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

Вот аспекты продукта, для оценки которых юзабилити-тестирование особенно эффективно:


106 Глава 4. Как понять пользователей: качественные исследования

  1.  Наименование. Осмысленны ли названия разделов и надписи на
    кнопках? Возможно, какие-то из этих слов воспринимаются легче,
    чем другие?
  2.  Архитектура. Осмысленно ли информация разбита на категории?
    Расположены ли информационные элементы в тех местах, где их
    ожидают найти потребители?
  3.  Первое знакомство и доступность. Легко ли новые пользователи
    находят базовые элементы интерфейса? Понятны ли инструкции?
    Есть ли в них необходимость?
  4.  Эффективность. Могут ли потребители эффективно решать кон
    кретные задачи? Ошибаются ли они? При выполнении каких ша
    гов? Как часто?

Из сказанного видно, что юзабилити-тестирование сосредоточено преимущественно на оценке первого опыта использования продукта. Зачастую очень сложно (и всегда трудоемко) измерять эффективность решения при пятидесятом использовании продукта, то есть, другими словами, для самой интересной целевой аудитории - вечных середняков. Это порождает определенные трудности при оптимизации интерфейса для середняков и экспертов. Один из методов преодоления этих трудностей носит название дневниковые исследования: испытуемые ведут дневники с подробными записями о своем взаимодействии с продуктом. Хорошее описание этого метода дается в книге Майка Кунявски «Observing the User Experience» (Kuniavsky, 2003).

Наконец, при проведении юзабилити-тестирования следует убедиться, что вы тестируете то, что можно измерить, что тестирование выстроено корректно, что результаты будут полезны для выявления проблем проектирования и у вас есть ресурсы, необходимые для исправления этих проблем. Отличным руководством по теме юзабилити-тестирования служит классическая работа Якоба Нильсена (Jakob Nielsen) «Usability Engineering» (Nielsen, 1993).

Карточная сортировка

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


Прочие виды исследований 107

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

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

Анализ рабочих заданий

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

  1.  стоящая за заданием реальная цель - для чего пользователь выпол
    няет задания;
  2.  частота и важность выполнения заданий;
  3.  триггеры - что служит поводом или сигналом для выполнения за
    дания;
  4.  зависимости - что требуется для выполнения задания и что зависит
    от ее выполнения;
  5.  люди, которые вовлечены в выполнение задания, их роли и зоны
    ответственности;
  6.  конкретные действия, которые требуется выполнить;
  7.  решения, которые необходимо принять;
  8.  информация, которая нужна для принятия решений;
  9.  ошибки и исключительные ситуации - что может пойти не так;
  10.  способы исправления ошибок и обработки исключений.

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


108 Глава 4. Как понять пользователей: качественные исследования

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

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

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


5

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

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

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

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


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

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

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

Для чего нам модели?

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

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


Персонажи 111

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

Персонажи

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

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

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

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


112

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

После того как персонажи были представлены в качестве инструмента моделирования пользователей в книге «The Inmates Are Running The Asylum»1 (Cooper, 1999), они приобрели огромную популярность в сообществе людей, занимающихся проектированием опыта взаимодействия, но вместе с тем стали предметом некоторого недопонимания. Нам хотелось бы прояснить и более подробно изложить некоторые понятия и соображения, касающиеся персонажей.

Цели Алесандро ► Ехать быстро ► Получать удовольствие

Цели Марж

► Чувствовать себя в безопасности ► Ехать с комфортом

Цели Дейла

► Перевозить тяжелые грузы ► Ощущать надежность

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

Преимущества персонажей как средства проектирования

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

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

А. Купер «Психбольница в руках пациентов. Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие», дополненное издание. - Пер. с англ. - СПб: Символ-Плюс, 2009.


Персонажи 113

  1.  Общаться с заинтересованными лицами, разработчиками и други
    ми проектировщиками. Персонажи задают общий язык для обсуж
    дения проектных решений, а также помогают удерживать фокус на
    пользователях на каждом шаге процесса.
  2.  Достигать взаимопонимания и согласия в вопросах проектирова
    ния. С общим языком приходит и общее понимание. Персонажи со
    кращают потребность в подробных моделях-диаграммах: многочис
    ленные нюансы поведения пользователей проще понять благодаря
    повествовательным средствам, на которых основана работа с пер
    сонажами. Проще говоря, поскольку персонажи напоминают жи
    вых людей, они воспринимаются легче, чем диаграммы и списки
    функций.
  3.  Оценивать эффективность решений. На персонажах можно испы
    тывать проектные решения в процессе их формирования так, слов
    но вы показываете их реальным пользователям. Хотя этот метод не
    отменяет необходимость тестирования на реальных пользователях,
    он является мощным средством проверки найденных при проекти
    ровании решений на соответствие реальности. Это позволяет быст
    ро и недорого выполнять итерации проектирования, пользуясь
    лишь набросками на доске, и при этом подойти к моменту тестиро
    вания на реальных пользователях с более сильными интерфейсны
    ми решениями.
  4.  Вносить вклад в работу других подразделений, связанных с продук
    том, например в планы по маркетингу и продажам. Авторы сталки
    вались с тем, что клиенты начинают применять персонажей внутри
    своей организации в иных целях, например в качестве источника
    информации для маркетинговых кампаний, развития структуры
    организации и других задач стратегического планирования. Под
    разделения, не имеющие непосредственного отношения к разработ
    ке продукта, жаждут подробной информации о пользователях про
    дукта и обычно проявляют к персонажам огромный интерес.

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

  1.  Проблема пластилинового пользователя
  2.  Проектирование под себя
  3.  Проектирование в расчете на исключительные ситуации

Мы коротко опишем каждую из них в последующих подразделах.

Проблема пластилинового пользователя

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


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

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

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

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

Проектирование под себя

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


Персонажи 115

Проектирование в расчете на исключительные ситуации

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

Персонажи основаны на исследованиях

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

  1.  данные интервью с пользователями вне контекста использования;
  2.  информацию о пользователях, предоставленную заинтересованны
    ми лицами и экспертами в предметной области (ЭПО);
  3.  данные исследований рынка, таких как фокус-группы и опросы;
  4.  модели сегментации рынка;
  5.  результаты обзора литературы и более ранних исследований.

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

Персонажи представляются как отдельные личности

Персонажи - это модели пользователей, представленные в виде отдельных, конкретных людей. Они не являются реальными людьми, но синтезируются непосредственно по результатам наблюдений за реальными людьми. Успех персонажей как моделей пользователей во многом определяется тем, что персонажи олицетворяют личности (Соп-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).

Эти подходы представляются нам не слишком удачными ввиду следующих причин:

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


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

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

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

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

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

Персонажи и профили пользователей

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


Персонажи 121

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

Персонажи и рыночные сегменты

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

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

Условный персонаж:

что делать, если нет точного персонажа

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


122

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

Рис. 5.3. Персонажи и сегменты рынка. Сегменты рынка можно использовать на стадии исследований для ограничения диапазона персонажей пределами целевых рынков. Однако соответствие один к одному между сегментами рынка и персонажами встречается редко

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

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

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


Цели

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

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

При использовании условных персонажей важно:

  1.  недвусмысленно пометить их в качестве таковых;
  2.  визуально представлять их через наброски вместо фотографий, что
    бы подчеркнуть условность;
  3.  стараться использовать как можно больше существующих данных
    (обзоры рынка, исследования предметной области, ЭПО, полевые
    исследования, персонажи для сходных продуктов);
  4.  отмечать, какие данные были использованы и какие предположе
    ния выдвинуты; держаться подальше от стереотипов (это сложнее
    делать, когда нет данных полевых исследований);
  5.  сосредотачиваться на поведении и мотивах, а не на демографиче
    ских характеристиках.

Цели

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

Цели мотивируют использовать продукт определенным образом

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


124

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

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

Источником целей должны быть качественные данные

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

Цели пользователей и когнитивные процессы обработки

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

. Вот три уровня когнитивной обработки по Норману: • Физиологический. Самый непосредственный уровень обработки, на котором человек реагирует на визуальные и другие сенсорные аспекты продукта еще до того, как случится какое-либо значимое взаимодействие. Обработка на физиологическом уровне позволяет нам быстро принимать решения о том, что хорошо или плохо, безопасно или опасно. Это одна из замечательных особенностей человеческого поведения, но ее эффективная поддержка входит в число наиболее сложных задач при создании цифровых продуктов. Мал-кольм Гладуэлл (Malcolm Gladwell) исследует этот уровень когнитивной обработки в своей книге «Blink»1. Еще более подробное изучение принятия решений на интуитивном уровне предпринято вкнигах «Sources of Power» Гэри Клейна (Gary Klein) и «Hare Brain, Tortoise Mind» Гая Клэкстона (Guy Claxton)

 M. Гладуэлл .Озарение. Сила мгновенных решений». - Пер. с англ  - М.: Вильяме, Альпина Бизнес Букс, 2008.


Цели

 

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

Проектирование для физиологических реакций

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

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


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

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

Проектирование для уровня поведения

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

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

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

Проектирование для аналитического уровня

Уровень аналитических процессов (особенно в его связи с проектированием) - самый сложный из трех уровней обработки, описываемых


Цели  127

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

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

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

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

Три типа пользовательских целей

В книге «Emotional Design» (Norman, 2005) Норман представил свою теорию трехуровневой когнитивной обработки и продемонстировал важность этой теории для проектирования. При этом автор не предложил метода для систематической интеграции своей модели познания и воздействия в практику проектирования продуктов или исследования пользователей. Наш опыт показывает, что ключ к такой связи - в соответствующем разграничении и моделировании трех конкретных типов целей пользователей в рамках описания каждого персонажа (Goodwin, 2001).


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

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

  1.  эмоциональные цели;
  2.  конечные цели;
  3.  жизненные цели.

Рассмотрим подробнее каждую из категорий.

Эмоциональные цели

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

  1.  Чувствовать уверенность в том, что ситуация под контролем.
  2.  Получать удовольствие.
  3.  Ощущать душевный подъем или расслабленность.

• Быть собранным и сосредоточенным.

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

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

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


Цели 129

торых отображаются отношения персонажей к окружению и их поведение.

Конечные цели

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

  1.  Узнавать о проблемах до того, как они послужат причиной катаст
    рофы.
  2.  Поддерживать контакт с родными и друзьями.
  3.  Заканчивать запланированные дела к пяти часам вечера ежедневно.
  4.  Найти музыку, которая мне понравится.
  5.  Получить наилучшее предложение.

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

Жизненные цели

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

  1.  Прожить хорошую жизнь
  2.  Преуспеть в реализации амбиций

5 3ак. 1494


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

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

Цели суть мотивы

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

  1.  Эмоциональные цели, связанные с физиологическим уровнем обра
    ботки: как пользователь хочет себя
    чувствовать.
  2.  Конечные цели, связанные с поведением: что пользователь хочет
    делать.
  3.  Жизненные цели, связанные с анализом и рефлексией: кем пользо
    ватель хочет
    быть.

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

Прочие типы целей

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


Цели 131

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

Цели покупателей

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

Бизнес-цели и цели организации

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

Вот некоторые из целей бизнеса:

  1.  Увеличить прибыль
  2.  Расширить свое присутствие на рынке
  3.  Удержать клиентов
  4.  Обойти конкурентов
  5.  Эффективнее использовать ресурсы
  6.  Расширить спектр предлагаемых продуктов или услуг

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


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

  1.  Повысить уровень образованности публики
  2.  Получить достаточно денег, чтобы покрыть расходы

Технические цели

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

  1.  Поддерживать различные броузеры
  2.  Сохранять целостность данных
  3.  Повысить эффективность работы программы
  4.  Использовать какой-то конкретный язык разработки или библио
    теку
  5.  Сохранить межплатформенное единообразие

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

Успешные продукты в первую очередь служат целям пользователей

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

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


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

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

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

 принцип        Не заставляйте пользователей чувствовать себя дураками.

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

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

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

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

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

Создание правдоподобных и действенных персонажей в равной степени требует детального анализа и творческого синтеза. Оба вида деятельности в значительной степени выигрывают от применения стандартизированного процесса. Описываемый в этом разделе процесс разработан Робертом Рейманом, Ким Гудвин и Лэйн Хэлли (Robert Reimann, Kim Goodwin, Lane Halley) в компании Cooper, является результатом эво-


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

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

  1.  Выявить поведенческие переменные.
  2.  Сопоставить респондентов с поведенческими переменными.
  3.  Выявить значимые шаблоны поведения.
  4.  Синтезировать характеристики и соответствующие им цели.
  5.  Проверить полноту и выявить избыточность.
  6.  Расширить описание атрибутов и поведений.
  7.  Назначить персонажам типы.
    Рассмотрим каждый из этапов более подробно.

Шаг1: выявить поведенческие переменные

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

В общем случае наиболее важные различия между шаблонами поведения определяются при рассмотрении следующих типов переменных:

  1.  Деятельность: чем занят пользователь, частота и объем.
  2.  Взгляды: каким образом пользователь думает о предметной области
    и технологии продукта.
  3.  Наклонности: каковы образование и подготовка пользователя, его
    способность обучаться.
  4.  Мотивация: каким образом пользователь вовлечен в предметную
    область продукта.
  5.  Навыки: умения пользователя, связанные с предметной областью
    продукта и используемой технологией.

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


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

 135

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

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

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

Шаг 2: сопоставить респондентов с поведенческими переменными

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

Здесь важна не столько точность значений, сколько взаимное расположение респондентов. Иначе говоря, не так важно, располагается ли респондент на шкале на уровне 45% или 50%, и часто вообще нет способа измерить это точно и приходится полагаться на интуицию исходя из наблюдений за респондентом. Результатом этого шага должна стать группировка всех респондентов по каждой из осей (рис. 5.4).

Шаг 3: выявить значимые шаблоны поведения

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


136

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

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

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

Шаг 4: синтезировать характеристики и соответствующие им цели

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

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

И все же одна вымышленная деталь на этой стадии является существенной - это имена и фамилии персонажей. Имя должно вызывать од-


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

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

Синтез целей

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

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

Взаимоотношения персонажей

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

Принимая решение о том, задавать ли социальные отношения между персонажами, обдумайте следующие моменты:


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

  1.  Наблюдали ли вы какие-либо различия в поведении респондентов
    в зависимости от размеров компании, отрасли, в которой они рабо
    тают, или социальной/семейной динамики? (Если ответ положи
    тельный, то необходимо убедиться, что набор персонажей должным
    образом представляет разнообразие ситуаций, попадая, как мини
    мум, в два различных социальных или деловых контекста.)
  2.  Важно ли проиллюстрировать особенности рабочего процесса или
    социальных взаимодействий между сотрудниками или членами се
    мьи либо социальной группы?

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

Шаг 5: проверить полноту и выявить избыточность

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

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


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

Шаг 6: расширить описание атрибутов и поведений

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

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

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

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

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

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


140

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

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

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

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

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


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

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

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

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

  1.  ключевой
  2.  второстепенный
  3.  дополнительный
  4.  покупатель
  5.  обслуживаемый
  6.  отрицательный

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

  1.  цель или желаемый результат процесса;
  2.  частота и важность процесса и каждого действия;
  3.  событие, инициирующее процесс в целом и каждое действие;
  4.  зависимости - что требуется, чтобы выполнить процесс в целом и ка
    ждое действие в отдельности, а также какие события и действия за
    висят от завершения процесса в целом и каждого из действий;
  5.  участники процессов, их роли и ответственности;
  6.  конкретные действия;
  7.  принимаемые решения;
  8.  информация, используемая при принятии решений;
  9.  что может пойти не так - ошибки и исключительные ситуации;
  10.  как исправляются ошибки и обрабатываются исключения.

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

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

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

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

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


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

 145

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

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


6

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

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

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

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

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


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

 147

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

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

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

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

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


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

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

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

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

В девяностые годы сообществом HCI (Human-Computer Interaction -взаимодействие человека и компьютера) была проделана значительная работа в области проектирования программ, ориентированных на варианты использования. Здесь находятся истоки понятия сценария, которое широко используется как указание на метод решения задач проектирования через конкретизацию - использование специально составленного рассказа, чтобы одновременно конструировать и иллюстрировать проектные решения. Джон Кэрролл пишет об этих идеях в своей книге «Making Use» (Carroll, 2000):

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

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

• Действующее лицо как абстрактная, ролеориентированная модель в представлении Кэрролла недостаточно конкретно, чтобы обеспечить понимание пользователей или вызвать эмпатию по отноше-


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

нию к ним. Невозможно адекватно спроектировать поведение системы, не имея подробного знания о пользователях системы.

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


152 Глава 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, еще раз подчеркнем важность того, чтобы модель представления интерфейса - то, как ведет себя и как выглядит продукт, - максимально точно соответствовала ментальным моделям пользователей, а не отражала модель реализации -то есть внутреннее устройство продукта.

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

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

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

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


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

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

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

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

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

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

  1.  В какой обстановке будет использоваться продукт?
  2.  Будет ли он использоваться в течение долгого времени?
  3.  Часты ли прерывания в работе персонажа?
  4.  Работает ли с компьютером/устройством более чем один пользова
    тель?
  5.  Какие еще продукты используются вместе с проектируемым?
  6.  Какие основные действия должен выполнить персонаж, чтобы дос
    тичь своих целей?
  7.  Каков ожидаемый конечный результат применения продукта?
  8.  Какова допустимая сложность продукта исходя из частоты его ис
    пользования и навыков персонажа?

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


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

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

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

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

  1.  Готовясь к выходу с утра, Вивьен при помощи смартфона проверяет
    электронную почту. Смартфон быстро подключается и обладает
    достаточно большим экраном, так что это удобнее, чем загружать
    компьютер. Ведь Вивьен еще надо быстренько сделать дочери Али
    се бутерброд в школу.
  2.  Вивьен видит письмо от последнего клиента, Фрэнка, который хотел
    бы днем посмотреть дом. Контакт Фрэнка уже есть внутри устройст
    ва, поэтому Вивьен может позвонить Фрэнку при помощи единст
    венного действия непосредственно с экрана электронного письма.
  3.  Разговаривая с Фрэнком, Вивьен включает громкую связь, чтобы
    иметь возможность в ходе разговора смотреть на экран. Она изучает
    назначенные встречи, чтобы понять, в какое время она свободна.
    Когда она создает новую запись о встрече, смартфон автоматически
    отмечает ее как встречу с Фрэнком, потому что знает, с кем она сей
    час разговаривает. Заканчивая беседу, она быстро вносит адрес до
    ма в запись о встрече.
  4.  Отправив Алису в школу, Вивьен направляется в агентство недви
    жимости, чтобы собрать документы, которые требуются для другой
    встречи. Ее смартфон уже синхронизировал новые встречи с
    Out
    look,
    так что остальные сотрудники офиса знают, где она будет днем.
  5.  День летит быстро, и Вивьен несколько опаздывает на встречу. На
    правляясь к дому, который хочет смотреть Фрэнк, она получает
    уведомление от смартфона, что встреча состоится через пятнадцать
    минут. Открыв смартфон, она видит не только запись о встрече, но
    и список всех документов, относящихся к Фрэнку, включая элект
    ронные письма, заметки, голосовые сообщения и информацию
    о звонках на номер Фрэнка. Вивьен нажимает кнопку вызова,
  6.  


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


7

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

  1.  Голосовая активация (голосовые данные, привязанные к контакту
    из телефонной книги)
  2.  Программируемые кнопки быстрого набора
  3.  Выбор человека из записной книжки
  4.  Выбор на основе заголовка сообщения электронной почты, записи
    о встрече или заметки
  5.  Аавтоматическое предоставление кнопки вызова в подходящих кон
    текстах (к примеру, при уведомлении о приближающейся встрече)

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


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

  1.  Позволит пользователям эффективно достигать целей?
  2.  Будет лучше других соответствовать нашим принципам проектиро
    вания?
  3.  Окажется в рамках бюджета и технологических возможностей?
  4.  Будет лучше других соответствовать прочим требованиям?

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

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

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

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

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


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

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

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

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

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

  1.  Какие элементы займут много экранного пространства, а какие нет?
  2.  Какие из элементов являются контейнерами для других элемен
    тов?
  3.  Как следует расположить контейнеры, чтобы оптимизировать рабо
    чий процесс?
  4.  Какие элементы используются совместно, а какие нет?
  5.  В какой последовательности используются связанные элементы?
  6.  Какие шаблоны и принципы взаимодействия здесь уместны?
  7.  Как влияют на организацию элементов ментальные модели персо
    нажей?

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

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


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

 169

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

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

Шаг 4: макетирование общей инфраструктуры взаимодействия

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

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

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


170

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

Рис. 7.1. Пример ранних макетов компоновки: работа студии Cooper для Cross Country TravCorp - интернет-портала для мобильных медсестер. Наброски экранной компоновки должны быть простыми - поначалу достаточно прямоугольников, названий и простых описаний связей между функциональными областями. Можно делать визуальные намеки на детали более низкого уровня, чтобы дать представление о содержимом областей, однако не попадайте в ловушку - не переходите на этом шаге к проектированию деталей

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

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

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


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

сования высокоуровневых эскизов интерфейса применяются такие продукты, как Adobe Fireworks, Adobe Illustrator, Microsoft Visio, Microsoft PowerPoint и OmniGraffle от Omni Group. Главное здесь - найти наиболее удобный для вас инструмент, позволяющий быстро работать на высоком уровне, не вдаваясь в детали. Мы находим полезным применять для макетов инфраструктуры такой стиль, который подчеркивает схематичность предложенных решений (вспомним, что грубые наброски лучше всего стимулируют обсуждение проектных решений). Крайне важно также иметь возможность легко получить визуализацию набора последовательно связанных экранов, отражающую поведение продукта при выполнении ключевого сценария (система «фреймов»1 в Fireworks делает этот инструмент особенно удобным для решения данной задачи).

Шаг 5: создание ключевых сценариев

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

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

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

В последней версии Adobe Fireworks CS4 фреймы были переименованы в «состояния» - удачное решение с точки зрения применения данного элемента. - Примеч. науч. ред.


172

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

Раскадровка

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

Рис. 7.2. Пример более подробного варианта компоновки веб-приложения Cross Country TravCorps, связанного с поиском работы

Цикличность и вариативность процесса

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


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

способы выполнения шагов с 3 по 5. Какой-то из способов окажется удобнее прочих.

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

  1.  Ключевые сценарии.
  2.  Словесная группировка.
  3.  Макетирование.

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

  1.  Макетирование.
  2.  Ключевые сценарии.
  3.  Проверка соответствия группировки сценариям.

Шаг 6: выполнение проверочных сценариев для верификации решений

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

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


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

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

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

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

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

Создание визуальной инфраструктуры происходит обычно следующим образом:

  1.  Провести исследование визуального языка.
  2.  Применить выбранный визуальный стиль к экранным архетипам.

Шаг 1: исследование визуального языка

Первый шаг в определении визуальной инфраструктуры- изучить разнообразные варианты оформления посредством исследования ви-


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

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

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

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

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

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

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


176

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

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


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

аятов, именно его выберут заинтересованные лица - это почти неписаное правило.

 принцип

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

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

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

Шаг 2: применение выбранного стиля

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

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

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

1. Совместно с проектировщиками взаимодействия обсудить форм-фактор и способы управления.


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

  1.  Создать грубыо прототипы.
  2.  Выполнить исследование языка формы.

Шаг 1: совместно с проектировщиками взаимодействия обсудить форм-фактор и способы управления

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

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

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

Пользавательский опыт целостен - форму и поведение продукта следует проектировать согласованно.

ПРИНЦИП проектирования

Шаг 2: создать грубые прототипы

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


Детализация формы и поведения

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

Шаг 3: выполнить исследование языка формы

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

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

Детализация формы и поведения

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

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

На этапе детализации происходит перевод раскадровок в полноценные экраны, отражающие пользовательский интерфейс с точностью до отдельных пикселов (рис. 7.4).

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


180

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

Рис. 7.4. Полноценные экраны для Cross Country TravCorps, основанные на иллюстрациях, созданных в программе Framework (рис. 7.2). Обратите внимание, что в макете интерфейса произошли небольшие естественные изменения, связанные с реалиями пиксельной графики и экранного разрешения. Дизайнеры и проектировщики взаимодействия на з-той стадии в тесном сотрудничестве добиваются того, чтобы все изменения в дизайне подчеркивали те или иные варианты поведения продукта и соответствовали целям ключевых персонажей

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

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

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


Проверка результата проектирования и юзабилити-тестирование 181

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

Проверка результата проектирования и юзабилити-тестирование

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

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

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


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

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

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

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

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

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

Когда тестировать: полное и промежуточное тестирование

В своей книге «Usability Engineering» (Nielsen, 1993) Якоб Нильсен различает полное тестирование, когда тестируются завершенные продукты, и промежуточное тестирование, проводимое в ходе проектирования как часть итерационного процесса. Это важное различие. Полное тестирование применяется для сравнения продуктов, для выявления проблем перед перепроектированием, для расследования причин возвратов продукта и определения источника запросов на обучение


Проверка результата проектирования и юзабилити-тестирование 183

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

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

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

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

Проведение промежуточного юзабилити-тестирования

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


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

Вот вкратце важные составляющие успешного промежуточного юза-билити-тестирования:

  1.  Проводите тестирование достаточно поздно, когда уже существует
    конкретное решение проектирования, но и достаточно рано, чтобы
    можно было успеть скорректировать проект и реализацию.
  2.  Тестируйте задачи и аспекты опыта пользователя, связанные с кон
    кретным продуктом.
  3.  Набирайте участников из аудитории целевых пользователей, ис
    пользуя персонажей в качестве фильтра.
  4.  Четко ставьте перед участниками задачи и просите при их решении
    размышлять вслух.
  5.  Дайте участникам возможность напрямую взаимодействовать с низ
    котехнологичным прототипом (исключением являются случаи, ко
    гда тестируется специализированное оборудование, а бумажный
    прототип не способен отразить нюансы взаимодействия).
  6.  Управляйте ходом сеансов, чтобы выявить проблемы и изучить
    причины их возникновения.
  7.  Минимизируйте предвзятость, введя в эксперимент модератора,
    который ранее не принимал участия в проекте.
  8.  Сосредоточьтесь на поведении и образе мысли участников.
  9.  По завершении тестов проведите разбор (дебрифинг) вместе с на
    блюдателями, чтобы выявить причины наблюдавшихся проблем.
  10.  Вовлекайте в процесс исследования проектировщиков.

Вовлеченность проектировщика в юзабилити-исследования

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

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


Проверка результата проектирования и юзабилити-тестирование 185

успеха исследования. Мы обнаружили, что проектировщиков важно привлекать к следующим видам деятельности:

  1.  Планирование исследований - для формулирования важных с точ
    ки зрения проектирования вопросов
  2.  Определение критериев отбора участников с помощью персонажей
    и их атрибутов
  3.  Использование сценариев для выбора тестовых задач
  4.  Наблюдение за сеансами тестирования
  5.  Совместный анализ результатов исследований
  6.  


8

Создание качественного интерфейса:

принципы и шаблоны

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

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

Принципы проектирования взаимодействия

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


1Э0 Глава 8. Создание качественного интерфейса: принципы и шаблоны

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

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

Принципы действуют на различных уровнях детализации

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

  1.  Ценности проектирования - императивы эффективной и этичной
    практики проектирования. Эти принципы, о которых мы погово
    рим далее в этой главе, служат отправной точкой для принципов
    более низкого уровня из категорий, перечисленных ниже.
  2.  Концептуальные принципы помогают определять сущность про
    дукта
    и его место в более широком контексте использования, кото
    рый требуется пользователям. Принципы концептуального уровня
    описываются в главах 3, 9 и 10.
  3.  Поведенческие принципы описывают, как продукт должен себя
    вести -
    в целом и в конкретных ситуациях. Поведенческие прин
    ципы описываются в главах с 8 по 20.
  4.  Интерфейсные принципы описывают эффективные стратегии ви
    зуальной коммуникации поведенческих и информационных аспек
    тов интерфейса. К этому уровню проектирования относятся прин
    ципы из глав 13 и 14, а также некоторая информация из глав вто
    рой и третьей частей книги.

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

Поведенческие принципы и интерфейсные принципы сокращают трудозатраты

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


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

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

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

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

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

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

Принципы - это правила, ведущие к действиям и обычно опирающие- ся на ряд ценностей и убеждений. Приведенный ниже набор ценностей  создали Роберт Рейман, Хью Дабберли (Hugh Dubberly), Ким Гудвин,  Дэвид Фор (David Fore) и Джонатан Корман (Jonathan Korman). Он  применим к любой дисциплине проектирования, которая служит потребностям человека.

Задача проектировщиков взаимодействия- создавать такие проект- ные решения, которые:

• Этичны [тактичны, заботливы]:
не причиняют вреда;
улучшают положение человека.


192 Глава 8. Создание качественного интерфейса: принципы и шаблоны

• Целенаправленны [полезны, применимы]:

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

Прагматичны [жизнеспособны, осуществимы]:

помогают организации, внедряющей ваши проектные решения,

достигать своих целей;

учитывают требования бизнеса и технические требования.

• Элегантны [эффективны, искусны, вызывают эмоции]:
представляют собой простые, но полноценные решения;
обладают внутренней (самоочевидной, понятной) целостностью;
учитывают и пробуждают эмоции и познавательные процессы.

Рассмотрим эти ценности подробнее.

Проектирование этичного взаимодействия

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

Не навреди

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

  1.  межличностный вред (потеря достоинства, оскорбления, унижение);
  2.  психологический вред (замешательство, дискомфорт,  раздраже
    ние, давление, скука);

  1.  физический вред (боль, травмы, лишения, смерть, угрозы безопас
    ности);
  2.  экологический вред (загрязнение, сокращение числа биологиче
    ских видов);
  3.  


Ценности проектирования 193

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

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

Улучшай положение человека

Чтобы результатом проектирования стало действительно этичное взаимодействие, мало просто не вредить - требуется способствовать. Вот некоторые улучшения, которым в широком смысле могут содействовать интерактивные системы:

  1.  улучшение понимания (индивидуального, социального, культур
    ного);
  2.  повышение эффективности/действенности отдельных личностей
    и групп;
  3.  совершенствование коммуникаций - как между отдельными лич
    ностями, так и между группами людей;
  4.  снижение социокультурной напряженности между личностями
    и группами;
  5.  умножение справедливости (финансовой, социальной, правовой);
  6.  сглаживание культурных противоречий путем стимулирования об
    щественного согласия.

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

Проектирование целенаправленного взаимодействия

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

7 3ак   I494


194 Глава 8. Создание качественного интерфейса: принципы и шаблоны

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

Проектирование прагматичного взаимодействия

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

Проектирование элегантного взаимодействия

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

Создавай простые, но полноценные решения

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


Ценности проектирования 195

отличий для четкой передачи нужного смысла. В хорошем проектировании «меньше» означает «больше», и проектировщики должны стремиться разрешать проблемы проектирования с минимальными добавлениями к форме и поведению в соответствии с ментальными моделями персонажей. Такой подход хорошо знаком программистам, которые соглашаются, что лучшие алгоритмы коротки и понятны. Известный турист и основатель компании Patagonia, производящей одежду для туристов, Ивон Шунар (Yvon Chounard) очень метко процитировал французского писателя и авиатора Антуана де Сент-Экзю-пери: «абсолютно во всем совершенство достигается не тогда, когда уже нечего добавить, но когда уже ничего нельзя отнять».

Добивайся внутренней целостности

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

Учитывай и пробуждай эмоции и познавательные процессы

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

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


196 Глава 8. Создание качественного интерфейса: принципы и шаблоны

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

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

Шаблоны проектирования взаимодействия

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

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

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

Архитектурные шаблоны

и проектирование взаимодействия

Идея выявления шаблонов проектирования взаимодействия уходит корнями к замыслу Кристофера Александера, который первым описал шаблоны архитектурного проектирования в своих новаторских работах «A Pattern Language» (Alexander, 1977) и «The Timeless Way of Building» (Alexander, 1979). Определив жесткий набор архитектурных особенностей, Александер стремился выразить ту суть архитектурного проектирования, которая создает ощущение благополучия у людей, находящихся в зданиях.


Шаблоны проектирования взаимодействия 197

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

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

Определение шаблонов проектирования взаимодействия и их использование

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

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

Шаблоны проектирования не являются рецептами или готовыми решениями. В своей книге «Designing Interfaces»1 - объемистом и полезном собрании шаблонов проектирования взаимодействия - Дженифер Тидвелл (Jenifer Tidwell) предостерегает нас: «[Шаблоны] - это не го-

Дж. Тидвелл «Разработка пользовательских интерфейсов». - Пер. с англ. -СПб: Питер, 2008.


198 Глава 8. Создание качественного интерфейса: принципы и шаблоны

товые к употреблению компоненты; каждая реализация шаблона немного отличается от всех других» (Tidwell, 2006).

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