Чтение онлайн

ЖАНРЫ

Психбольница в руках пациентов
Шрифт:

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

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

по телефону с людьми, подобными Лео, и сообщал Элисон, какой кабинет следует посетить и что починить.

Наш клиент, компания 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», то все остальные варианты исчезают, а следующий экран требует выбрать категорию фильма. И так экран за экраном, пока на шестом уровне пользователю не удается, наконец, посмотреть ролик и согласиться или отказаться смотреть весь фильм. Отказавшись, он и должен вернуться на шесть экранов назад, к самому началу, и снова пройти шесть экранов, чтобы добраться до следующего фильма. Уф!

Поделиться с друзьями: