Алан Купер - Психбольница в руках пациентов

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

В интересах точного определения персонажей необходимо определить средние показатели. Средний пользователь никогда не бывает математически средним. У среднего человека в моем населенном пункте 2,3 ребенка, но ни у одного жителя города не может быть такого количества детей. Более полезным представителем мог быть стать Сэмюэл, отец двоих детей, или Уэллс, у которого трое детей. Сэмюэл полезен, потому что он личность. Да, гипотетическая, но обладающая точными характеристиками. Родитель, имеющий 2,3 ребенка, не может существовать, как раз из-за этого невозможного среднего показателя.

Усредненные персонажи уничтожают преимущества конкретности точных. Великая сила персонажей именно в их точности и конкретике. Обобщенные данные сводят эту силу на нет.

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

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

Один из действительно положительных моментов, связанных с персонажами, заключается в том, что они придают дискуссиям об уровне подготовленности пользователей свежесть реализма. Вариации на тему подготовленности пользователей крайне широки, и персонажи позволяют отчетливо это осознать. Широко распространенная модель подготовленности пользователей приведена в главе 2 «Когнитивное сопротивление». Вершину пирамиды составляют «продвинутые пользователи», которые предположительно знают о компьютерах все, если речь не идет о программировании. Центральный фрагмент составляют «компьютерно образованные пользователи», имеющие базовое понимание принципов работы компьютера, но не представляющие себе всех замечательных возможностей. «Неподготовленные пользователи» – это основание пирамиды; считается, что они до безобразия невежественны и неумны.

Вот некоторые примеры персонажей, разрушающие ложные посылки, на которых строится пирамида.

Рупак работает инженером по установке компьютерных сетей в Лос-Анджелесе. Он ежедневно целыми днями возится с компьютерами, он дока в том, как заставить их работать, однако он не понимает, как они работают. Его выживание на данном месте основано на запасе суеверий и практических знаний, способности к механическому заучиванию и бесконечному терпению.

Шэннон работает бухгалтером в оздоровительном центре в Темпе, штат Аризона. Она совершенно не имеет представления о Всемирной паутине, электронной почте, сетях, файловой системе и практически всех остальных аспектах современных компьютеров, но потрясающе обращается с электронными таблицами Мiсrоsоft Excel. Она умеет моментально создавать новые финансовые таблицы с графиками и диаграммами.

Декстер – вице-президент отдела развития голливудской компании Steinhammer Video Productions. У Декстера, перемещающегося между павильонами звукозаписи, карманы двубортного пиджака заполнены: там пейджер, два мобильных телефона, наладонный компьютер и беспроводной модем. В области техники он гигант, способный решить любую проблему. Коллеги постоянно звонят ему, просят найти потерянные файлы, но он действительно очень занят, чтобы терять время на подобное обучение. Майкл ждет ответа на третьей линии!

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

Что интересно, ни Рупак, ни Шэннон, ни Декстер, ни Роберто не вписываются в упомянутую пирамиду. Если оставить в стороне угнетающий характер стереотипов, предложенных пирамидой, она совершенно не отражает характер аудитории пользователей. Чрезмерно упрощенные рыночные модели никак не способствуют решению проблем проектирования.

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

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

До введения в обращение персонажей типичный диалог программиста и руководителя, занятых проектированием взаимодействий, выглядит примерно так:

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

Руководитель: «Не думаю, что печать в первой версии так уж необходима».