ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.01.2024
Просмотров: 786
Скачиваний: 35
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
171
С другой стороны, проектируя чемодан на колесиках, мы можем в качестве прототипа рассматривать Франсин, стюардессу компании на Reno Air. Она трижды в день преодолевает немалые расстояния, раздавая напитки и пакетики с арахисом. Герд и
Франсин совершенно разные личности, но их цели и потребности в области багажа эквивалентны.
Программисты живут исключительными ситуациями, и под этим влиянием выбирают персонажи. Они будут спорить, что Соня законно претендует на роль персонажа, поскольку занимает место пилота. В этом разница - программирование определяется краевыми случаями предметной области, а проектирование - центральными. Если есть хоть какое-то сочинение в центральном расположении персонажа, этот персонаж следует исключить из рассмотрения.
В интересах точного определения персонажей необходимо определить средние показатели. Средний пользователь никогда не бывает математически средним. У среднего человека в моем населенном пункте 2,3 ребенка, но ни у одного жителя города не может быть такого количества Детей. Более полезным представителем мог быть стать
Сэмюэл, отец двоих детей, или Уэллс, у которого трое детей. Сэмюэл полезен, потому что он личность. Да, гипотетическая, но обладающая точными характеристиками.
Родитель, имеющий 2,3 ребенка, не может существовать, как раз из-за этого невозможного среднего показателя.
Усредненные персонажи уничтожают преимущества конкретности точных. Великая сила персонажей именно в их точности и конкретике. Обобщенные данные сводят эту силу на нет.
Персонажи - самый мощный из имеющихся в нашем распоряжении инструментов проектирования. Они являются основой целеориентированного проектирования.
Персонажи позволяют нам видеть масштаб и природу проблемы проектирования.
Позволяют точно понять и определить цели пользователя и таким образом определить, что должен делать продукт и чего он может совершенно спокойно не делать. Точно определенный персонаж дает нам определенность относительно уровня владения пользователя компьютером, поэтому мы перестаем терзаться загадкой, для кого проектировать: для дилетанта или специалиста.
Изобретенные персонажи уникальны для каждого проекта. Время от времени мы обращаемся к персонажам из прошлых проектов, но требование точности делает
172 практически невозможным существование двух идентичных персонажей.
1 ... 8 9 10 11 12 13 14 15 ... 21
Реалистичный взгляд на уровень подготовленности
Один из действительно положительных моментов, связанных с персонажами, заключается в том, что они придают дискуссиям об уровне подготовленности пользователей свежесть реализма. Вариации на тему подготовленности пользователей крайне широки, и персонажи позволяют отчетливо это осознать. Широко распространенная модель подготовленности пользователей приведена в главе 2
«Когнитивное сопротивление. Вершину пирам иды составляют «продвинутые пользователи, которые предположительно знают о компьютерах все, если речь не идет о программировании. Центральный фрагмент составляют «компьютерно образованные пользователи», имеющие базовое понимание принципов работы компьютера, но не представляющие себе всех замечательных возможностей. «Неподготовленные пользователи - это основание пирамиды; считается, что они до безобразия невежественны и неумны.
Вот некоторые примеры персонажей, разрушающие ложные посылки, на которых строится пирамида.
Рупак работает инженером по установке компьютерных сетей в Лос-Анджелесе. Он ежедневно целыми днями возится с компьютерами, он дока в том, как заставить их работать, однако он не понимает, как они работают. Его выживание на данном месте основано на запасе суеверий и практических знаний, способности к механическому заучиванию и бесконечному терпению.
Шэннон работает бухгалтером в оздоровительном центре в Темпе, штат Аризона.
Она совершенно не имеет представления о Всемирной паутине, электронной почте, сетях, файловой системе и практически всех остальных аспектах современных компьютеров, но потрясающе обращается с электронными таблицами Мiсrоsоft Excel.
Она умеет моментально создавать новые финансовые таблицы с графиками и диаграммами.
Декстер - вице-президент отдела развития голливудской компании Steinhammer
Video Productions. У Декстера, перемещающегося между павильонами звукозаписи, карманы двубортного пиджака заполнены: там пейджер, два мобильных телефона, на ладонный компьютер и беспроводной модем. В области техники он гигант, способный
173 решить любую проблему. Коллеги постоянно звонят ему, просят найти потерянные файлы, но он действительно очень занят, чтобы терять время на подобное обучение.
Майкл ждет ответа на третьей линии!
Роберто - представитель по телемаркетингу J. Р. Stone, компании, продающей одежду по почтовым заказам. Он сидит в своем рабочем отсеке, где-то в пригороде
Мэдисона, штат Висконсин, на нем гарнитура, а компьютер он использует для обработки поступающих по телефону заказов. Роберто совершенно не разбирается в компьютерах и высоких технологиях, но он уравновешенный добросовестный работник, обладающий замечательной способностью выполнять сложные процедуры. После нескольких дней тренировки он стал одним из самых производительных и эффективных представителей J.
Р. Stone. Он говорит: «Мне нравится мой компьютер!»
Что интересно, ни Рупак, ни Шэннон, ни Декстер, ни Роберто не вписываются в упомянутую пирамиду. Если оставить в стороне угнетающий характер стереотипов, предложенных пирамидой, она совершенно не отражает характер аудитории пользователей. Чрезмерно упрощенные рыночные модели никак не способствуют решению проблем проектирования.
Персонажи закрывают споры о функциях
Как ни удивительно, вторым крайне важным вкладом персонажей является их большая ценность в качестве инструмента общения. Набор персонажей становится системой, обладающей мощным свойством объяснять наши решения в области проектирования. Более того, это как прожектор высвечивающий для разработчиков, маркетологов, руководителей очевидную правильность наших решений по проектированию.
Жизненно важно, чтобы каждый в команде проектировщиков не только познакомился с набором персонажей, но чтобы все персонажи стали подобны реальным людям, подобны самим участникам команды разработчики. Программистам свойствен математический подход и они естественным образом не склонны рассматривать отдельных пользователей, предпочитая обобщение. Это переходит и на их отношение к пользователям, которых они всегда представляют в общих, агрегатных или же усредненных категориях. Они предпочитают говорить «пользователь», а не «Джуди»,
«Крэндал», «Луис», «Эстелла», «Раджив» или «Фрэн».
174
До введения в обращение персонажей типичный диалог программиста и руководителя, занятых проектированием взаимодействий, выглядит примерно так:
Программист: «Что если пользователь захочет вывести это на печать?
Руководитель: «Не думаю, что печать в первой версии так уж необходима».
Программист: «Кому-то может понадобиться печать».
Руководитель: «Вероятно, да, но не могли бы мы отложить пока эту функцию? »
Руководитель не может победить в этом споре, поскольку в его аргументах нет логики. Аргумент, независимо от его правдивости, выглядит лишь аморфным желанием руководителя сделать что-то иначе, тогда как логике программиста о «возможных событиях» сопротивляться нельзя!
После разработки набора персонажей мы получаем систему, позволяющую точно выразить, кому и что нужно от программы. Однако программистов тяжело убедить, поэтому типичная беседа нашего клиента с программистом на ранних стадиях выглядит так:
Программист: «Что если пользователь захочет вывести это на печать?»
Проектировщик взаимодействия: «Розмари печать не нужна».
Программист: «Кому-то может понадобиться печать».
Проектировщик взаимодействия: «Но мы проектируем для Розмари, а не для кого-
то».
На данном этапе особых перемен нет. Программист по-прежнему применяет слово
«пользователь» И по-прежнему живет в мире возможных событий. Однако ввод в действие персонажа Розмари - это уже не аморфное, несформированное желание.
Напротив, речь идет о конкретном человеке, обладающем известным набором умений и целей. У нас, наконец, имеется убедительный аргумент.
Но поскольку кодом владеют программисты, они могут делать и делают, что захотят, независимо от силы наших аргументов. Ключ к успеху в том, чтобы заставить программистов поверить в существование и реальность созданных персонажей. Каждый из наших проектировщиков решительно настаивает на выражении всех вопросов, связанных с проектированием, с помощью именованных персонажей. Мы никогда не возвращаемся к понятию
«пользователь».
Через какое-то время такая последовательность приносит плоды, программисты начинают привыкать к персонажам и называть их по именам. Когда программисты начинают называть их по именам по
175 собственной воле, это малозаметное, но переломное событие меняет природу сотрудничества между проектировщиками и разработчиками.
Перелом наступает во всех наших успешных начинаниях, связанных с проектированием. И тогда происходит переключение на высокую передачу. Беседа звучит теперь иначе:
Просветленный программист: «Розмари захочет это напечатать?»
Довольный проектировщик взаимодействия: «Нет. А вот Джейкобу нужна печать квартальных отчетов».
Просветленный программист: «Ну, если печать нужна так редко, сэкономим время и силы, не будем создавать собственный встроенный генератор отчетов, а лицензируем уже существующий».
Довольный руководитель: «Эдак мы сэкономим на разработке две недели!»
Я видел, как после такого перелома наши клиентские компании меняются коренным образом. Раньше они плутали в дебрях бесконечных споров о Возможностях и каждые две недели снова решали уже, казалось бы, решенные вопросы. После описанных перемен вопросы проектирования обсуждаются, разрешаются и остаются разрешенными навсегда.
Некоторые наши клиенты заказали футболки с изображениями важных персонажей для каждого из разработчиков. Другие напечатали постеры с персонажами для помещений, где работают программисты. Эти усилия помогают сплотить программистов ради понимания потребителей продукта.
Персонажи нужны проектировщикам и программистам
Нам приходилось работать в компаниях, где программисты не могли себя заставить называть пользователей по именам и не верили в точных персонажей. Они постоянно скатывались обратно к «пользователям», отчего кошмарно страдали продукты.
Я знаю программиста, который просто не понимает механизм действия персонажей.
Под давлением аргументов с моей стороны и со стороны Моих коллег он признал, что персонажи важны. При этом он упускает из виду главную идею конкретизации, поэтому склонен слово «персонаж»употреблять в качестве синонима слова «пользователь». Он говорит: «Мы должны обеспечить потребности персонажей». Применяя термин, он тем не менее отвергает конкретику, главный действующий ингредиент, из-за чего подход
176 теряет всякую силу.
Один клиент дал нам лишь несколько дней на составление рекомендаций. Мы создали персонаж по имени Эдгар, и большим количеством деталей этот персонаж обрасти не успел. Затем мы вступили в продолжительные дискуссии с клиентом по вопросам, выходящим за исходные рамки проекта. Мы быстро обнаружили, что Эдгар начал размножаться. Различные команды внутри этой компании воспринимали различных Эдгаров, то есть каждая самостоятельно наделяла его теми или иными качествами.
Профессиональные маркетологи мгновенно принимают процесс разработки персонажей, поскольку он очень похож на то, что они делают на этапе определения рынка. Главное различие между персонажами маркетинга и персонажами проектирования в том, что первые создаются исходя из демографии и каналов сбыта, а последние - исключительно на основе пользователей. Это не одни и те же персонажи, хотя служат одной цели. Персонажи маркетинга проливают свет на процесс продажи, тогда как персонажи проектирования проливают свет на процесс разработки.
Продумывая этапы проектирования, мы можем примерять их результаты к персонажам и видеть, насколько хорошо справляемся. Мы начинаем играть роли, действуем от имени и по поручению персонажей. И благодаря конкретным определениям это нетрудно. Примерив на персонаже продукт или задачу, вы сразу можете понять, удастся ли вам его удовлетворить.
Персонаж пользователя, а не покупателя
Одна из распространенных ошибок заключается в проектировании для человека, близкого к продукту, но непосредственным пользователем не являющегося. Многие продукты проектируются для журналиста, пишущего обзор продукта для потребительской прессы. В сфере информационных технологий руководитель, покупающий продукт, часто оказывается не тем, кому придется продукт применять.
Проектирование для покупателя - распространенная ошибка в компьютерном бизнесе.
Разумеется, потребности руководителя в ИТ тоже нельзя игнорировать, но в конечном итоге руководителю больше понравится, если продукт сделает довольным
конечного пользователя. В конце концов, если конечный пользователь доволен и имеет возможность работать Продуктивно, это успех для руководителя в ИТ. Нередко наши
177 клиенты игнорируют данный совет и потворствуют этим клевретам технологии. Одарив реальных конечных пользователей продуктом, руководители тонут в потоке жалоб и обнаруживают, что пользователи не желают иметь дело с продуктом, очаровавшим руководителя. Руководитель обращается к создателю приложения и требует, чтобы взаимодействия стали более удобными для конечных пользователей.
Подбор персонажей
Каждый проект получает собственный набор персонажей в количестве от трех до двенадцати. Мы проектируем не для каждого из них, но все персонажи полезны для выражения пользовательской аудитории. Некоторые создаются лишь для того, чтобы было ясно, для кого мы не проектируем. Так, в одном из проектов речь шла о системе управления поддержкой клиентов. Мы дали определения трем персонажам, из которых двое были техническими специалистами, работающими в отделе поддержки. Лео Пирс, младший маркетолог продукта, работал на компьютере ежедневно и время от времени сам обращался в службу поддержки. Элисон Хардинг, специалист компании, перемещалась из кабинета в кабинет со своими инструментами в алюминиевом кейсе, разрешая проблемы сотрудников, подобных Лео. Тедван Верен, представитель службы поддержки, целыми днями разговаривал по телефону с людьми, подобными Лео, и сообщал Элисон, какой кабинет следует посетить и что починить.
Наш клиент, компания Remedy Inc., как раз занимался пересмотром Флагманского продукта, Action RequestSystem (ARS), и желал сделать его «более простым в применении». Разработав эти три персонажа (и еще ряд других), мы смогли четко выразить действительные цели проекта.
Тед на тот момент был основным потребителем ARS, но не он стал нашим главным персонажем. Мы могли бы сделать программу более простой для Теда, но это означало бы полный провал. Вместо этого мы решили дать Лео прямо и доступ к системе поддержки. До этого, нуждаясь в помощи Лео был вынужден звонить Теду, который уведомлял Элисон. Полный набор персонажей дал нам четкое представление об участниках этой игры. Мы получили возможность сообщить разработчикам - системы, что цель будет достигнута лишь в том случае, если Лео, далекий от техники маркетолог, сможет задействовать систему обработки запросов (Action Request System, ARS) со своего компьютера для вызова техпомощи, Не прибегая к вмешательству Теда.
178
Как только мы объяснили положение дел в терминах персонажей, участники команды сразу поняли, что необходимо снять акцент с Теда и сосредоточить внимание на Лео. Тед занимает место так называемого «отрицательного персонажа». Его существование помогает нам понять, для кого мы не проектируем.
179
* * *
Обнаружив такой персонаж, цели которого уникальны, мы идентифицируем его.
Совершенно не обязательно, чтобы персонажи имели непересекающиеся наборы целей, достаточно, чтобы стремления каждого персонажа четко отличались от набора остальных. Цели Рауля, собирающего она конвейере газонокосилки, отличаются от целей
Сесили, контролирующей сборку. Сесили стремится улучшить производительность в целом, избежав при этом происшествий. Рауль желает выполнить разумный объем работы, не совершая ошибок. Практически е цели этих людей одинаковы, однако мотивы очевидно различаются. Рауль желает стабильности, Сесили желает получить повышение.
Их цели достаточно сильно различаются, чтобы появилась необходимость создать два различных персонажа.
Ключевые персонажи
В каждом наборе персонажей сеть хотя бы один ключевой персонаж. Эта личность находится в фокусе процесса проектирования. Ключевой персонаж отличает потребность в удовлетворении, недостижимом при помощи интерфейсов, спроектированных для любого другого персонажа. Для ключевого персонажа всегда существует отдельный интерфейс. В примере с Remedy ARS ключевым персонажем был Лео Пирс.
Нахождение одного ключевого персонажа или сразу нескольких - жизненно важный шаг в разработке набора персонажей. По моему опыту, каждый ключевой персонаж требует отдельного уникального интерфейса. Если у нас два ключевых персонажа, то придется в конечном итоге проектировать два интерфейса. Если у нас три ключевых персонажа, придется в конечном итоге проектировать три интерфейса. Если у нас четыре ключевых персонажа, это означает, это у нас возникли трудности.
180
Если мы обнаружили более трех ключевых персонажей, это означает, что набор проблем предметной области слишком велик, что мы пытаемся слишком много сделать в один прием. Мы создаем персонажи для сужения диапазона конечных пользователей.
Отсюда следует, что если число персонажей слишком велико, значит, мы начинаем действовать против исходной цели создания персонажей.
Подбор персонажей - не просто удобное словосочетание, а средство проектирования, как в физическом, так и логическом плане. После просеивания аудитории полезных персонажей оказывается обычно от трех до семи. Мы собираем на одном листе бумаги информацию о них - имена, изображения, описания должностей, цели и, нередко, обрывки сплетен. Этот документ в одну страницу становится неизменной составляющей нашего процесса. Мы распечатываем копии набора персонажей и раздаем их на каждом собрании, независимо от того, присутствует ли клиент. Каждый проектировщик на всех наших мозговых штурмах и собраниях, посвященных детальному проектированию, постоянно держит перед собой эту страницу.
Если на собрании присутствуют представители клиента, мы печатаем дополнительные копии и для них. Каждый созданный для клиента документ содержит эту страницу. Наша цель состоит в том, чтобы сделать персонажи неизбежным ингредиентом. Они настолько важны, что мы навязываем их всем и каждому.
Выполнить качественное проектирование и не выразить его в терминах персонажей
- не очень мудрое решение. Слишком уж легко скатиться обратно к разговорам о
«пользователе» и утратить с таким трудом приобретенный фокус на конкретных архетипах пользователей.
Пример: Sony Trans Соm и P@ssport
В 1997 году компания Sony Trans Соm предложила нам замечательную проблему из области проектирования. Sony Trans Соm - это отделение корпорации Sony, расположенное в Калифорнии и отвечающее за проектирование и производство развлекательных систем для гражданской авиации. Развлекательные системы подобного рода, позволяющие в полете смотреть фильмы, телепередачи, слушать музыку и играть в игры - большой и прибыльный бизнес. Компания Sony Trans Соm разработала новое поколение технологии, предоставляющее пассажирам новые возможности. Самой впечатляющей возможностью новой системы, получившей название P@ssport, стало