Описание должно быть подробным, а не идеальным

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

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

К примеру, проектируя чемодан на колесиках, в качестве персонажа мы могли бы взять Герда, командира рейса Боинга-747 из Ванкувера во Франкфурт.

С одной стороны, мы не можем расширением персонажа охватить всех пилотов коммерческих рейсов. Скажем, Соня посещает занятия в Университете аэронавтики Эмбри-Риддл и собирается стать профессиональным пилотом после выпуска. Она летает ежедневно, но только на маленьких одномоторных самолетах, и никогда не ночует вне дома. Если говорить о багаже, то Соня – крайний случай. Если определение Герда распространить на Соню, то персонаж из точного превращается в размытый. Начинаются бесконечные и бесцельные дискуссии о том, является ли Соня пилотом авиалиний, и о том, какие требования предъявляет она к своему багажу.

С другой стороны, проектируя чемодан на колесиках, мы можем в качестве прототипа рассматривать Франсин, стюардессу компании на Reno Air. Она трижды в день преодолевает немалые расстояния, раздавая напитки и пакетики с арахисом. Герд и Франсин совершенно разные личности, но их цели и потребности в области багажа эквивалентны.

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

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

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

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

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