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

Просветленный программист: «Розмари захочет это напечатать?»

Довольный проектировщик взаимодействия: «Нет. А вот Джейкобу нужна печать квартальных отчетов».

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

Довольный руководитель: «Эдак мы сэкономим на разработке две недели!»

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

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

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

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

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

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

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

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

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

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

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

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