Персоны требуются как проектировщикам, так и программистам

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

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

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

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

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

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

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

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

Как создавать образы персон

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

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

 

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

 

 

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

 

* * *

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

Ключевая персона

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

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

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

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

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

Кейс: система P@ssport от компании Sony Trans Сот

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

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

 

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