АкушерствоАнатомияАнестезиологияВакцинопрофилактикаВалеологияВетеринарияГигиенаЗаболеванияИммунологияКардиологияНеврологияНефрологияОнкологияОториноларингологияОфтальмологияПаразитологияПедиатрияПервая помощьПсихиатрияПульмонологияРеанимацияРевматологияСтоматологияТерапияТоксикологияТравматологияУрологияФармакологияФармацевтикаФизиотерапияФтизиатрияХирургияЭндокринологияЭпидемиология

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

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

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

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

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

* * *

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

Дата добавления: 2015-02-05 | Просмотры: 604 | Нарушение авторских прав