Войти в систему
Войти с помощью соц. сетей:
Одним из действительно ценных моментов использования персон является то, что они задают более реалистичный тон всем дискуссиям об уровне компьютерной грамотности. Степень подготовленности пользователей может варьироваться в очень широких пределах, и персоны позволяют отчетливо это увидеть. Наиболее распространенная модель уровней компьютерной грамотности в форме пирамиды приводилась в главе 2 «Когнитивное сопротивление». На вершине этой пирамиды находятся «продвинутые пользователи», обладающие абсолютными знаниями о компьютерах, за исключением разве что умения программировать. В середине – «компьютерно грамотные пользователи», понимающие принципы работы компьютеров, но не разбирающиеся во всем многообразии его впечатляющих возможностей. Основание пирамиды – это «неопытные пользователи», которые считаются совершенно недалекими невеждами.
Вот несколько примеров персон, разрушающих ложные представления, взятые за основу при построении пирамиды:
Рупак занимает должность инженера по компьютерным сетям в Лос-Анджелесе. Днями напролет он работает с компьютерами, он эксперт в том, как заставить их функционировать должным образом, тем не менее он не обладает глубинными познаниями, как они устроены. Ему удается держаться на своем месте лишь благодаря практическому опыту, набору суеверий, способности бездумно заучивать новое и безграничному терпению.
Шэннон занимает должность бухгалтера оздоровительного спа-центра в Темпе, штат Аризона. Ей совершенно неизвестно, как работает Всемирная паутина, электронная почта, локальная сеть, файловая система и практически все остальное, что касается компьютера, но при этом она абсолютный гений в использовании электронного табличного процессора Microsoft Excel. В мгновение ока она может сотворить новую таблицу с графиками и диаграммами, отображающую уровень продаж компании.
Декстер занимает должность вице-президента по развитию бизнеса в компании Steinhammer Video Productions, расположенной в Голливуде. Он беспрерывно перемещается между павильонами звукозаписи, потому в карманах его двубортного пиджака умещается множество предметов: пейджер, два мобильных телефона, карманный компьютер и беспроводной модем. Он великий эксперт в технологиях и может решить любую проблему. Его телефон постоянно разрывается от звонков коллег с просьбами помочь им найти пропавшие файлы, однако он действительно слишком занят, чтобы попусту растрачивать время на такие мелочи. Клинт ожидает на третьей линии!
Роберто – телемаркетинговый представитель J. Р. Stone, компании-производителя надежной одежды для активного отдыха с доставкой по почте. Его рабочее место находится в офисном отсеке в пригороде Мэдисона, штат Висконсин. Там он надевает свою гарнитуру и принимает телефонные заказы, которые обрабатывает посредством компьютера. Роберто ничего не понимает в компьютерах и высоких технологиях, однако он стрессоустойчивый, трудолюбивый сотрудник, обладающий удивительной способностью с легкостью разбираться в сложных операциях. Всего через несколько дней обучения он стал одним из самых продуктивных и эффективных представителей J. Р. Stone. Он говорит, что ему «нравится работать за компьютером».
Самым интересным является то, что ни Рупака, ни Шэннон, ни Декстера, ни Роберто даже близко нельзя отнести к какому-либо из уровней вышеописанной пирамиды. Даже если абстрагироваться от подавляющей власти стереотипов, эта пирамида совершенно не отражает пользовательскую аудиторию. Слишком упрощенные модели рынков никоим образом не помогают решить проблемы проектирования.
Удивительно, но второй чрезвычайно важной и ценной особенностью персон является их способность выступать в качестве великолепного инструмента коммуникации. Набор образов превращается в систему проектирования, обладающую невероятной выразительной силой, позволяющей донести наши представления относительно проектирования. Куда больше они, подобно прожектору, показывают программистам, маркетологам и руководителям, что мы принимаем совершенно верные решения по проектированию.
Жизненно необходимо, чтобы не только каждый участник проектировочной команды ознакомился с набором персон, но и чтобы каждая персона стала почти реальным человеком, словно принимающим участие в процессе разработки. Программисты – с их математическим складом ума – от природы не склонны выделять отдельные случаи, а стараются смотреть на ситуацию в целом, обобщая. Такое восприятие переносится и на их видение в отношении пользователей – в представлении программистов это некие обобщенные, усредненные, универсальные категории. Они видят лишь абстрактного «пользователя», а не «Джуди», «Крэндалла», «Луиса», «Эстеллу», «Раджива» или «Фрэна».
До того момента, как будет разработан набор персон, стандартный диалог между программистом и руководителем, ответственными за проектирование взаимодействия, будет выглядеть приблизительно таким образом:
Программист: «А что если пользователю понадобится распечатать это?»
Руководитель: «Думаю, что в опции печати для первой версии программы большой необходимости нет».
Программист: «Но кому-то может потребоваться возможность распечатки».
Руководитель: «Может, и так. Но мы ведь можем пока отложить добавление этой функции?»
У руководителя практически нет шансов победить в этом споре, поскольку его доводы не выдерживают натиска логики со стороны программиста. Аргументы руководителя, даже будучи истинными, выглядят лишь как невнятное желание сделать все по-своему, в то время как справедливые доводы программиста о том, что «может случиться», непоколебимы.
Разработав набор персон, мы получаем систему, с помощью которой мы совершенно точно можем выразить, кому и какая опция программы нужна. Однако переубедить программистов не так-то легко, поэтому стандартный диалог между программистом, представляющим нашего клиента, и нашим проектировщиком взаимодействия на ранних стадиях рабочих отношений будет выглядеть приблизительно так:
Программист: «А что если пользователю понадобится распечатать это?»
Проектировщик взаимодействия: «Розмари не нужно ничего печатать».
Программист: «Но кому-то может потребоваться возможность распечатки».
Проектировщик взаимодействия: «Мы ведь проектируем для Розмари, а не для этого „кого-то“».
На данном этапе взаимодействия возникает некий конфликт. Программист все еще воспринимает «пользователя» как абстракцию и все еще существует в мире вероятных событий. Тем не менее включение в диалог персоны Розмари позволяет сделать наше намерение менее размытым и неясным. Здесь речь уже идет о конкретном человеке, с определенным набором навыков и целей. Мы наконец-то располагаем убедительным доводом.
Однако из-за того, что доступ к коду имеют программисты, они по-прежнему могут – и будут – делать что им заблагорассудится, вне зависимости от убедительности наших аргументов. И только способность заставить программистов поверить в реальное существование созданных нами персон может стать ключом к успеху. С этого момента каждый из наших проектировщиков начинает решительно настаивать на выражении всех аспектов проектирования в категориях персон с конкретными именами. Мы больше никогда не возвращаемся к абстрактному понятию «пользователь». Спустя некоторое время этот трюк срабатывает – программисты начинают принимать персон как должное и называть их по именам. Казалось бы, перемена незначительна, однако когда программисты делают так по собственной воле, она превращается в поистине сокрушительное событие, кардинальным образом изменяющее всю природу взаимодействия между разработчиками и проектировщиками.
Такой перелом происходит внутри каждого участника наших успешных проектов. Как только это случается, мы резко переключаемся на высокую передачу. Теперь диалог звучит иначе:
Просветленный программист: «Розмари понадобится что-то печатать?»
Счастливый проектировщик взаимодействия: «Нет. Но вот Джейкобу может потребоваться печать отчетов приблизительно раз в квартал».
Просветленный программист: «Ну, если отчеты нужны не так часто, тогда не стоит тратить время и силы на разработку собственного генератора отчетов, а лучше лицензировать стороннее коммерческое решение».
Счастливый руководитель: «Получается, что за счет этого мы сэкономим на разработке целых две недели!»
Я лично наблюдал, какие коренные изменения происходят в компаниях наших клиентов после такого перелома. Ранее они уходили в бесконечные дискуссии о том, какие опции добавить, а уже решенные вопросы снова и снова всплывали на собраниях спустя две недели с момента обсуждения. После же наступления перелома вопросы касательно проектирования возникают и решаются один раз и навсегда, более к ним не возвращаются.
Некоторые из наших клиентов придумали печатать изображения важных персон на футболках для разработчиков. Другие помещали плакаты с персонами над рабочими столами программистов. Подобные меры помогают сплотить программистов в достижении глубокого понимания пользователя их продукта.
Войти с помощью соц. сетей: