Персонажи нужны проектировщикам и программистам

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

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

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

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

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

Персонаж пользователя, а не покупателя

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

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

Подбор персонажей

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

Наш клиент, компания Remedy Inc., как раз занимался пересмотром флагманского продукта, Action Request System (ARS), и желал сделать его «более простым в применении». Разработав эти три персонажа (и еще ряд других), мы смогли четко выразить действительные цели проекта.

Тед на тот момент был основным потребителем ARS, но не он стал нашим главным персонажем. Мы могли бы сделать программу более простой для Теда, но это означало бы полный провал. Вместо этого мы решили дать Лео прямой доступ к системе поддержки. До этого, нуждаясь в помощи, Лео был вынужден звонить Теду, который уведомлял Элисон. Полный набор персонажей дал нам четкое представление об участниках этой игры. Мы получили возможность сообщить разработчикам системы, что цель будет достигнута лишь в том случае, если Лео, далекий от техники маркетолог, сможет задействовать систему обработки запросов (Action Request System, ARS) со своего компьютера для вызова техпомощи, не прибегая к вмешательству Теда.

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

* * *

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

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

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

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

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

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

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

Пример: Sony Trans Соm и P@ssport

В 1997 году компания Sony Trans Соm предложила нам замечательную проблему из области проектирования. Sony Trans Соm – это отделение корпорации Sony, расположенное в Калифорнии и отвечающее за проектирование и производство развлекательных систем для гражданской авиации. Развлекательные системы подобного рода, позволяющие в полете смотреть фильмы, телепередачи, слушать музыку и играть в игры – большой и прибыльный бизнес. Компания Sony Trans Соm разработала новое поколение технологии, предоставляющее пассажирам новые возможности. Самой впечатляющей возможностью новой системы, получившей название P@ssport, стало работоспособное видео по запросу (video-on-demand). Видео по запросу означает, что Патриция на месте 23А может начать смотреть фильм «Когда Гарри встретил Салли» через десять минут после взлета, тогда как Анна, на месте 16С, может начать смотреть тот же фильм на 45 минут позже, причем каждая из них будет иметь возможность приостановить воспроизведение или перемотать фильм, никак не мешая другой.

Система P@ssport подняла планку развлекательных систем в гражданской авиации на высоту, невообразимую для существующих технических решений. В спинку каждого кресла встраивался экран и компьютер с процессором Pentium под управлением Windows 95. В носу самолета располагался мощный кластер компьютеров, хранящий огромные объемы оцифрованной информации. Компьютеры на местах соединялись с кластером оптическим кабелем, причем каждые несколько рядов кресел подключались через выделенные концентраторы, что делало систему исключительно быстрой и поразительно мощной.

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

Традиционное решение

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

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

Классический пример «необоснованного решения». На каждом шаге пользователь делает выбор, последствия которого неизвестны. На первом надо выбрать вид развлечения: музыка (Audio), фильмы (Video), игры (Games), покупки (Shop) и т. д. Если выбрать «Video», то все остальные варианты исчезают, а следующий экран требует выбрать категорию фильма. И так экран за экраном, пока на шестом уровне пользователю не удается, наконец, посмотреть ролик и согласиться или отказаться смотреть весь фильм. Отказавшись, он и должен вернуться на шесть экранов назад, к самому началу, и снова пройти шесть экранов, чтобы добраться до следующего фильма. Уф!

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

Описанный шестиэкранный интерфейс – классический пример проектирования по модели реализации, точно отражающего внутреннее строение программного обеспечения. Каждый экран с выбором содержал очень мало контекстной или вспомогательной информации, поэтому пользователь не мог почувствовать себя уверенно, что и сделало навигацию неприемлемо сложной. Каждый раз, погружаясь уровнем ниже, пользователь терял из виду контекст. Выбор пункта «Video» лишал возможности выбрать (или даже видеть) другие пункты, такие как «Games». На каждом шаге программа совершенно никак не отражала общую картину, поэтому пользователю оставалось только теряться в догадках. И он выбирал «Video», не зная, какие фильмы можно посмотреть и сколько их. Он выбирал единственную категорию фильма, не понимая, что все эти категории означают. Что за фильм «Правдивая ложь» – приключенческий, романтический или это комедия? Добравшись, наконец, до названий фильмов, пользователь утрачивает и эту информацию. Хм, «Стирательная резинка» – это же, вроде, какой-то художественный фильм про кроткого школьного учителя?

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

Персонажи

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

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

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

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

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

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

Пассажиры

Экипаж Odissey AIRLINES

Клевис Мак-Клауд

Возраст: 65,

World Odyssey Class

Брент Ковингтон

Возраст: 37,

старший стюард

Мари Дюбуа

Возраст: 31,

Odyssey Club Class

Аманда Кент

Возраст: 28,

стюардесса

Чак Бургермайстер

Возраст: 54,

Odyssey Gold Class

Жан-Поль Дюро

Возраст: 33,

переводчик-синхронист

Этан Скотт

Возраст: 9,

World Odyssey Class

Молли Спрингер

Возраст: 41,

специалист по обновлению цифровой библиотеки

Мел «Хоппи» Хоппер

Возраст: 51,

механик

Джеймс Таттерсолл

Возраст: 47,

пилот

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

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

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

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

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

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

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

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

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

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

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

Программисты Sony попали в ловушку трех чисел – нуля, единицы и бесконечности. На практике система P@ssport способна справиться примерно с тремя дюжинами фильмов. С точки зрения программиста число 36, будучи больше нуля и единицы, эквивалентно бесконечности, а представление бесконечного числа фильмов вызвало осложнения, что и стало причиной возникновения иерархии категорий. Но Клевису по душе прокрутка трех десятков вариантов. Даже если бы фильмов было несколько сотен, ему все равно была бы приятна эта прогулка – он вспоминал бы фильмы, которые уже видел, и предвкушал бы просмотр новых.

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

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

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

* * *

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

Позаботившись о безопасности пассажиров, Аманда должна сосредоточиться на обслуживании, чтобы каждый пассажир остался максимально доволен полетом. Интерфейс для нее должен содержать органы управления всеми операциями в полете. К примеру, если Чак (место 24С) захочет пересесть, потому что Клевис (место 24В) уснул и громко храпит, Аманда должна иметь возможность перенести счет Чака и до половины просмотренный фильм на пустое место 19D, куда он пересаживается.

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

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

* * *

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

Глава 10
Проектирование ради результата

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