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

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

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

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

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

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

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

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

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

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

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

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

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

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

* * *

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