• Главная
• В избранное
• Наш E-MAIL
• Добавить материал
• Нашёл ошибку
• Вниз

Альберт Эйнштейн сказал, что нельзя решить проблему, находясь внутри системы, которая ее породила. Я уделил уже достаточно времени тому, чтобы идентифицировать старый образ мышления и показать, почему он неработоспособен. Теперь настало время поговорить о новом методе, который работает. Начиная с 1992 года я занимался разработкой такого метода, получившего название целеориентированного проектирования (Goal-Directed Design), и проектировщики в моей консультационной компании применяют его во всех проектах. В основе метода лежат нетрадиционные подходы к проблемам, ряд мощных руководящих аксиом, а также некоторые поразительно эффективные мыслительные инструменты. В следующих трех главах я представлю обзор трех наиболее мощных инструментов, а также примеры их применения и результаты, которых можно ожидать.

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

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

Работоспособный подход кажется примитивным, но обладает невероятной мощью и эффективен во всех случаях. Мы выдумываем несуществующих пользователей и проектируем для них. Мы называем таких несуществующих пользователей персонажами (personas), и они представляют собой необходимую базу качественного проектирования взаимодействия.

Персонажи25 – не реальные люди, но они представляют реальных людей в процессе проектирования. Это гипотетические архетипы реальных пользователей. Будучи воображаемыми, они, тем не менее, определяются достаточно жестко и точно. На практике мы не столько «выдумываем» персонажи, сколько обнаруживаем их в качестве побочного продукта процесса расследования. Но мы действительно выдумываем их имена и личные сведения.

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

Как правило, мы начинаем с разумного приближения и быстро сосредотачиваемся на правдоподобном наборе персонажей. Данный итеративный процесс похож на итеративный процесс, применяемый разработчиками программного обеспечения при создании продуктов, но имеет одно фундаментальное отличие. Циклическое совершенствование дизайна проекта и его предпосылок происходит быстро и легко, так как мы работаем на бумаге, работаем с текстом. Но циклическое совершенствование реализованного продукта медленнее и сложнее, поскольку здесь необходимо кодирование.

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

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

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

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

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

Роберт Лутц (Robert Lutz), руководитель компании Chrysler, говорит, что 80% участников фокус-группы возненавидели новый пикап Dodge Ram. Но после выхода на рынок машина стала бестселлером, потому что остальные 20% в нее влюбились. Любовь людей к продукту, пусть даже этих людей не очень много, – вот ключ к успеху.

Чем больше размер мишени, тем меньше вероятность попадания «в яблочко». Если вы желаете достичь уровня удовлетворенности продуктом в 50%, это невозможно сделать, осчастливив 50% широкой аудитории, Единственный способ достичь цели состоит в том, чтобы выявить эти 50% и стремиться осчастливить их на 100%. И это еще не все. Еще большего успеха можно добиться, если выделить 10% рыночной аудитории и направить свои усилия на то, чтобы вызвать у них стопроцентный восторг. На первый взгляд – противоречие, однако проектирование для единственного пользователя – самый эффективный способ удовлетворить широкую аудиторию.

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

После успеха чемоданов на колесиках в целевом сегменте продукт выпустили и на другие рынки. Сегодня в продаже есть большие чемоданы на колесах, чемоданы на колесиках «haute couture», бронированные чемоданы на колесиках, детские чемоданы на колесиках. Сегодня уже непросто купить багажный чемодан без встроенных колес и убирающейся ручки.

Вот другой пример. Арт Фрай (Art Fry), инженер отдела клейких материалов компании 3М, решая свои личные, сугубо специфические задачи, создал, можно сказать, самый распространенный и полезный из офисных аксессуаров. Арт Фрай пел в церковном хоре и постоянно сбивался, потому что бумажные закладки выпадали из псалтыря. Не желая портить церковную собственность скотчем, он принялся за поиски лучшего решения. Он вспомнил о клейком материале, над которым работал за несколько лет до описываемых событий. Материал не пошел в производство, поскольку имел низкий коэффициент сцепления. Арт нанес этот неудавшийся материал на небольшие квадратики желтой бумаги и получил удобные закладки. Вот так родились клейкие бумажки Post-It Note компании 3М.

Счастливые пользователи – невероятно эффективное и ценное приобретение. Сужая фокус, можно получить фанатично преданных клиентов целевого рынка. Как видно из главы 5 «Нелояльность клиентов», преданность покупателей становится хорошей поддержкой в трудные времена. Преданные пользователи не просто готовы покорять горы и вброд преодолевать реки, они также представляют собой самый мощный из известных инструментов маркетинга: преданные пользователи лично рекомендуют вас друзьям. Добившись шумихи вокруг своего продукта, вы сможете завоевать и соседние сегменты рынка.

Наша цель состоит в том, чтобы удовлетворить пользователя, но термин «пользователь» является источником трудностей. Из-за своей нечеткости этот термин бесполезен, как циркулярная пила бесполезна для удаления аппендикса. Нам нужен более точный инструмент проектирования.

Те, кто говорит «пользователь», обычно подразумевают эдакое «гуттаперчевое» создание, которому приходится изгибаться, растягиваться и адаптироваться к потребностям момента. Наша же цель состоит в проектировании программ, которые будут изгибаться, растягиваться и адаптироваться к потребностям пользователя. Программисты писали и пишут бессчетные множества программ для этого мифологического гуттаперчевого потребителя. Когда программист находит удобным познакомить пользователя с файловой системой Windows для поиска нужной информации, то определяет гуттаперчевого пользователя как пользователя, способного адаптироваться, продвинутого, образованного в области компьютеров; в других случаях, когда программист находит удобным провести пользователя через сложный процесс посредством бестолкового мастера, то определяет гуттаперчевого пользователя, как покладистого наивного новичка. Проектирование для гуттаперчевых пользователей дает разработчику разрешение писать код как угодно, лицемерно презирая «юзера». Реальные пользователи не эластичны.

Программисты создали выразительную систему, описывающую конструирование программного обеспечения. Хорошие программисты не бросаются глупыми обобщениями на тему различных компьютеров и систем. Программист никогда не скажет: «Это будет хорошо работать на компьютере». На каком компьютере? На какой модели? Под управлением какой операционной системы? С какими периферийными устройствами? Точно так же проектировщику никогда не следует расплывчато говорить о программах, будто они «спроектированы для пользователя» или «дружелюбны к пользователю». Такие слова обычно призваны оправдать навязывание собственных интересов.

В нашем процессе проектирования нет места «пользователю продукта» мы говорим о совершенно конкретном человеке – о персонаже.

Чем более конкретными мы делаем персонажи, тем более эффективными инструментами проектирования они становятся. Происходит это потому, что по мере конкретизации персонажи теряют эластичность. К примеру, мы не можем просто сказать, что Эмили пользуется офисными приложениями. Мы говорим, что Эмили пишет письма бабушке при помощи WordPerfect версии 5.1. Мы не позволяем Эмили просто поехать на работу. Мы снабжаем ее темно-синей Toyota Camry выпуска 1991 г., с серым пластиковым детским сиденьем и отвратной царапиной на заднем бампере. Мы не позволяем Эмили просто пойти на работу. Мы назначаем ее клерком по заведению счетов в бежевом отсеке компании Global Airways в Мемфисе, штат Теннесси. Такая характерная детализация – очень мощный инструмент проектирования и коммуникации. Как следствие, все наши персонажи описываются с тщательным вниманием к деталям.

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

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

В стремлении к равенству я не избегаю людей различных рас, полов, национальностей, но стараюсь не выбирать типичных представителей аудитории, поскольку это всех запутает. Шаблонный персонаж более эффективен, если шаблонность придает ему достоверность. Моя цель не в том, чтобы соблюсти политкорректность, но в том, чтобы всех убедить в реальности моих персонажей. Если персонаж – медсестра, то я скорее сделаю ее женщиной, а не мужчиной, и не потому, что медбратьев не бывает, а потому, что подавляющее большинство составляют все-таки медсестры. Если пользователь – компьютерный техник, то персонажем станет «Ник», прыщавый двадцатитрехлетний молодой человек, бывший член школьного клуба Аудио и Видео, а не «Хелен», отлично сложенная красавица ростом 175 сантиметров, посещавшая школу в Беверли Хиллз. Я стремлюсь к правдоподобию, а не к разнообразию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Программист: «Кому-то может понадобиться печать».

Руководитель: «Вероятно, да, но не могли бы мы отложить пока эту функцию?»

Руководитель не может победить в этом споре, поскольку в его аргументах нет логики. Аргумент, независимо от его правдивости, выглядит лишь аморфным желанием руководителя сделать что-то иначе, тогда как логике программиста о «возможных событиях» сопротивляться нельзя!

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

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

Проектировщик взаимодействия: «Розмари печать не нужна».

Программист: «Кому-то может понадобиться печать».

Проектировщик взаимодействия: «Но мы проектируем для Розмари, а не для кого-то».

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

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

Перелом наступает во всех наших успешных начинаниях, связанных с проектированием. И тогда происходит переключение на высокую передачу. Беседа звучит теперь иначе:

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

Довольный проектировщик взаимодействия: «Нет. А вот Джейкобу нужна печать квартальных отчетов».

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

Довольный руководитель: «Эдак мы сэкономим на разработке две недели!»

Я видел, как после такого перелома наши клиентские компании меняются коренным образом. Раньше они плутали в дебрях бесконечных споров о возможностях и каждые две недели снова решали уже, казалось бы, решенные вопросы. После описанных перемен вопросы проектирования обсуждаются, разрешаются и остаются разрешенными навсегда.

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

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

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

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

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

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

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

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

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

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

Тед на тот момент был основным потребителем ARS, но не он стал нашим главным персонажем. Мы могли бы сделать программу более простой для Теда, но это означало бы полный провал. Вместо этого мы решили дать Лео прямой доступ к системе поддержки. До этого, нуждаясь в помощи, Лео был вынужден звонить Теду, который уведомлял Элисон. Полный набор персонажей дал нам четкое представление об участниках этой игры. Мы получили возможность сообщить разработчикам системы, что цель будет достигнута лишь в том случае, если Лео, далекий от техники маркетолог, сможет задействовать систему обработки запросов (Action Request System, ARS) со своего компьютера для вызова техпомощи, не прибегая к вмешательству Теда.

Как только мы объяснили положение дел в терминах персонажей, участники команды сразу поняли, что необходимо снять акцент с Теда и сосредоточить внимание на Лео. Тед занимает место так называемого «отрицательного персонажа». Его существование помогает нам понять, для кого мы не проектируем.

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

В каждом наборе персонажей есть хотя бы один ключевой персонаж. Эта личность находится в фокусе процесса проектирования. Ключевой персонаж отличает потребность в удовлетворении, недостижимом при помощи интерфейсов, спроектированных для любого другого персонажа. Для ключевого персонажа всегда существует отдельный интерфейс. В примере с Remedy ARS ключевым персонажем был Лео Пирс.

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

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

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

Выполнить качественное проектирование и не выразить его в терминах персонажей – не очень мудрое решение. Слишком уж легко скатиться обратно к разговорам о «пользователе» и утратить с таким трудом приобретенный фокус на конкретных архетипах пользователей.

В 1997 году компания Sony Trans Соm предложила нам замечательную проблему из области проектирования. Sony Trans Соm – это отделение корпорации Sony, расположенное в Калифорнии и отвечающее за проектирование и производство развлекательных систем для гражданской авиации. Развлекательные системы подобного рода, позволяющие в полете смотреть фильмы, телепередачи, слушать музыку и играть в игры – большой и прибыльный бизнес. Компания Sony Trans Соm разработала новое поколение технологии, предоставляющее пассажирам новые возможности. Самой впечатляющей возможностью новой системы, получившей название P@ssport, стало работоспособное видео по запросу (video-on-demand). Видео по запросу означает, что Патриция на месте 23А может начать смотреть фильм «Когда Гарри встретил Салли» через десять минут после взлета, тогда как Анна, на месте 16С, может начать смотреть тот же фильм на 45 минут позже, причем каждая из них будет иметь возможность приостановить воспроизведение или перемотать фильм, никак не мешая другой.

Система P@ssport подняла планку развлекательных систем в гражданской авиации на высоту, невообразимую для существующих технических решений. В спинку каждого кресла встраивался экран и компьютер с процессором Pentium под управлением Windows 95. В носу самолета располагался мощный кластер компьютеров, хранящий огромные объемы оцифрованной информации. Компьютеры на местах соединялись с кластером оптическим кабелем, причем каждые несколько рядов кресел подключались через выделенные концентраторы, что делало систему исключительно быстрой и поразительно мощной.

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

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

Каждый экран представлял дополнительный уровень иерархии, и требовалось пройти шесть экранов, чтобы выбрать фильм.

Классический пример «необоснованного решения». На каждом шаге пользователь делает выбор, последствия которого неизвестны. На первом надо выбрать вид развлечения: музыка (Audio), фильмы (Video), игры (Games), покупки (Shop) и т. д. Если выбрать «Video», то все остальные варианты исчезают, а следующий экран требует выбрать категорию фильма. И так экран за экраном, пока на шестом уровне пользователю не удается, наконец, посмотреть ролик и согласиться или отказаться смотреть весь фильм. Отказавшись, он и должен вернуться на шесть экранов назад, к самому началу, и снова пройти шесть экранов, чтобы добраться до следующего фильма. Уф!

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

Описанный шестиэкранный интерфейс – классический пример проектирования по модели реализации, точно отражающего внутреннее строение программного обеспечения. Каждый экран с выбором содержал очень мало контекстной или вспомогательной информации, поэтому пользователь не мог почувствовать себя уверенно, что и сделало навигацию неприемлемо сложной. Каждый раз, погружаясь уровнем ниже, пользователь терял из виду контекст. Выбор пункта «Video» лишал возможности выбрать (или даже видеть) другие пункты, такие как «Games». На каждом шаге программа совершенно никак не отражала общую картину, поэтому пользователю оставалось только теряться в догадках. И он выбирал «Video», не зная, какие фильмы можно посмотреть и сколько их. Он выбирал единственную категорию фильма, не понимая, что все эти категории означают. Что за фильм «Правдивая ложь» – приключенческий, романтический или это комедия? Добравшись, наконец, до названий фильмов, пользователь утрачивает и эту информацию. Хм, «Стирательная резинка» – это же, вроде, какой-то художественный фильм про кроткого школьного учителя?

Даже на стадии прототипа в интерфейсе уже была красивая трехмерная графика, высокохудожественные пиктограммы, а также метафорическая тема карты-глобуса – все атрибуты хорошего, но пустого интерфейса. Мы называем это «раскраской трупа».

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

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

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

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

Мари Дюбуа, говорит на двух языках, деловые поездки. Английский для нее второй язык. Ей понравились разделы покупок, а также развлекательных программ.

Клевиc Мак-Клауд, старичок, под семьдесят, с причудами. Стареющий, но еще бойкий техасец, немного стесненный начинающимся артритом рук. Этот персонаж – единственный из четырех, который не имеет компьютера и не умеет компьютером пользоваться.

Пассажиры

Экипаж Odissey AIRLINES

Клевис Мак-Клауд

Возраст: 65,

World Odyssey Class

Брент Ковингтон

Возраст: 37,

старший стюард

Мари Дюбуа

Возраст: 31,

Odyssey Club Class

Аманда Кент

Возраст: 28,

стюардесса

Чак Бургермайстер

Возраст: 54,

Odyssey Gold Class

Жан-Поль Дюро

Возраст: 33,

переводчик-синхронист

Этан Скотт

Возраст: 9,

World Odyssey Class

Молли Спрингер

Возраст: 41,

специалист по обновлению цифровой библиотеки

Мел «Хоппи» Хоппер

Возраст: 51,

механик

Джеймс Таттерсолл

Возраст: 47,

пилот

Наш интерфейс должен удовлетворить Чака, Этана, Мари и Клевиса, не причиняя никому из них неудобств. Однако не было речи о том, чтобы сделать всех четверых безумно счастливыми. Этан знает, что игры, игры и снова игры – вещь особая, ради нее можно и несколько лишних кнопочек нажать; лишь бы был результат. Чак знает, что обширный опыт полетов позволяет ему экономить усилия на уже привычных вещах, однако, он готов немного напрячься и запомнить специальные команды.

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

Любое решение, ориентированное на Чака, Мари или Этана, было бы неприемлемым для Клевиса, которого напугали бы и запутали сокращенные команды (Чaк) и выбор языка (Мари). Мельтешащие игрушки Этана будут Клевису только мешать; при этом решение, способное осчастливить Клевиса, странноватого старого луддита, будет абсолютно приемлемо для всех остальных, если их особые потребности будут учтены в интерфейсе.

Чак и Марш летают уже давно и смогут сориентироваться в любой системе, если она не потребует длительного обучения. Мы понимали, что простая и наглядная система не подразумевает длительного привыкания, так что Чака и Мaри не обидим. С Этаном еще проще, о нем известно заранее, что он быстро и активно освоит систему и разберется со всем, что она предлагает. Он будет доволен, если сможет найти свои игрушки.

На протяжении всего проекта главным ориентиром был Клевис. Его изображение стало нашим боевым штандартом. Идеальная для Клевиса система сделала бы счастливыми и всех остальных пассажиров, всех до единого. Он стал нашим ключевым персонажем, мы проектировали систему для него и только для него.

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

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

Клевис просматривает постеры точно так же, как витрины магазинов, идя по улице. Ему не нужно выбирать категорию фильма и даже задумываться о ней. Мы отказались от древовидной иерархии – никто не будет долбить по экрану, как дятел, поэтому мы вернули к жизни сенсорный экран. Заинтересовавшись фильмом, Клевис касается постера и мгновенно получает рекламный ролик, вместе с текстом, информацией об актерах и стоимости просмотра. Еще одно касание, и он сможет начать просмотр фильма или продолжить прогулку по «Фильм-стрит».

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

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

Программисты Sony попали в ловушку трех чисел – нуля, единицы и бесконечности. На практике система P@ssport способна справиться примерно с тремя дюжинами фильмов. С точки зрения программиста число 36, будучи больше нуля и единицы, эквивалентно бесконечности, а представление бесконечного числа фильмов вызвало осложнения, что и стало причиной возникновения иерархии категорий. Но Клевису по душе прокрутка трех десятков вариантов. Даже если бы фильмов было несколько сотен, ему все равно была бы приятна эта прогулка – он вспоминал бы фильмы, которые уже видел, и предвкушал бы просмотр новых.

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

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

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

Я описал лишь интерфейс, спроектированный нами для Клевиса Мак-Клауда, пассажира. Мы спроектировали еще два более емких интерфейса для двух оставшихся ключевых персонажей, Аманды Кент, стюардессы, и Мела Хоппера, механика. Цели этих людей отличаются от целей Клевиса.

Позаботившись о безопасности пассажиров, Аманда должна сосредоточиться на обслуживании, чтобы каждый пассажир остался максимально доволен полетом. Интерфейс для нее должен содержать органы управления всеми операциями в полете. К примеру, если Чак (место 24С) захочет пересесть, потому что Клевис (место 24В) уснул и громко храпит, Аманда должна иметь возможность перенести счет Чака и до половины просмотренный фильм на пустое место 19D, куда он пересаживается.

Основное требование для Хоппи – быстрая оценка состояния системы. Он определяет, какие есть неполадки, насколько они серьезны и что он может сделать, чтобы исправить ситуацию.

Аманда и Хоппи пользуются одним экраном, расположенным на посту стюардов, однако их интерфейсы очень сильно различаются, поскольку различаются их цели.

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

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

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

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

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

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

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

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

Различать задачи и цели просто. Задачи меняются вместе с технологией, тогда как цели обладают приятной особенностью – они очень стабильны. Например, в путешествии из Сент-Луиса в Сан-Франциско мои цели – скорость, удобство, безопасность. Направляясь в Калифорнию на золотые прииски где-нибудь в 1850 году, я путешествовал бы в своем новом, высокотехнологичном фургоне Конестога26. В интересах безопасности я взял бы с собой ружье «винчестер». Направляясь из Сент-Луиса в Caн-Франциско в 1999 году, я путешествую в новом, высокотехнологичном Боинге-777. В интересах безопасности «винчестер» имеет смысл оставить дома. Мои цели остались неизменными, однако задачи изменились вместе с технологиями настолько, что стали прямо противоположными.

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

Цель – стабильная сущность. Задачи преходящи. Вот одна из причин, по которой проектирование под задачи не всегда уместно, а проектирование под цели уместно всегда.

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

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

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

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

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

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

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

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

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

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

В новостном бизнесе случается всякое, поэтому ведущий всегда желает иметь место для отступления. Его цель – всегда иметь разумную передачу, которую не стыдно выпустить в эфир. Вечерние новости появляются утром в виде полноценной, готовой к передаче в эфир записи. Эта запись длительностью 22 минуты (не считая рекламных вставок) всегда находится в состоянии полной готовности. Под каждое направление новостей отведено определенное время, и в сумме все сюжеты всегда имеют продолжительность 22 минуты. Здесь можно провести аналогию с подстройкой фокуса размытого изображения: границы новостной передачи никогда не меняются, а вот содержимое становится более точным и выдержанным по мере настройки. Начиная с 10 утра передача готова к выходу в эфир в любой момент, однако лучше всего выйти в эфир приблизительно в 5 часов вечера.

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

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

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

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

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

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

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

Начнем с оценки целей Теда. Здесь всегда предпочтительно начинать с главного. Очевидно, нам известно, что Тед желает смотреть телевизор. Он только что заплатил уйму денег за новый ящик, поэтому так же очевидно, что он желает воспользоваться преимуществами новых супервозможностей этого телевизора. Эти практические цели непосредственно связаны с задачей настройки нового телевизора.

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

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

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

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

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

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

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

Известная человеческая черта, и Тед здесь не исключение, – реагировать на компьютеры эмоционально (более подробно чуть позже в этой главе). Взаимодействуя с продуктом, человек естественным образом наделяет этот продукт человеческими качествами. Тед готов вложить дополнительные усилия в настройку своего телевизора, поскольку чувствует, что телевизор приложил усилия, чтобы доставить ему, Теду, удовольствие.

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

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

Не чувствовать себя глупо

Не совершать ошибок

Выполнить адекватный объем работы

Развлечься (или хотя бы не страдать от скуки)

Апологетов, как правило, очень беспокоит пункт «не чувствовать себя глупо». Это гордые, умные люди, они преуспевают в разрешении сложных ситуаций. Я бы сказал, что это очень похоже на предпринимателей Кремниевой Долины. К примеру, описав историю с телевизором Теда, я в качестве любезности отправил эту историю ему, человеку состоявшемуся, независимому, предпринимателю в области высоких технологий. Вот что ответил Тед:

Нельзя сказать, что возня с руководством в 40 страниц заставляет меня чувствовать себя глупо. Скорее, хочется сэкономить время, которое я в раздражении потратил бы на решение ненужных задач, а точнее – изучил бы то, что, возможно, впоследствии придется изучать повторно. (Скажем, если отключат электричество, потребуется ли программировать телевизор еще раз, снова обращаясь к руководству?)

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

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

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

Увеличить прибыль

Увеличить рыночную долю

Победить конкурентов

Нанять больше сотрудников

Предложить новые продукты и услуги

Выпустить акции компании в свободное обращение

Психологи, изучающие рабочую обстановку, применяют термин «гигиенические факторы», которые Сол Геллерман (Saul W. Gellerman)27 определяет как «элементы, обязательные для эффективной мотивации, но не способные мотивировать самостоятельно». Освещение в вашем офисе – гигиенический фактор. Вы ведь не ходите на работу только потому, что там хорошее освещение, но если бы освещения не было, вы не ходили бы туда вовсе.

Я адаптировал этот термин, заменив факторы целями: «гигиенические цели». Я их определяю как цели, необходимые для эффективной работы, но сами по себе не мотивирующие. Все корпоративные и практически цели, приведенные в списке, являются гигиеническими. С точки зрения корпорации, это все важные цели, однако работу выполняет не корпорация, а люди, а для людей важнее цели личные.

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

Практические цели восполняют пробел между стремлениями компании и стремлениями отдельного пользователя. Корпорация желает, чтобы все работали на пределе с целью максимального увеличения итоговой прибыли. Практическая цель удовлетворения требований клиента соединяет корпоративную цель (более высокие прибыли) с личной целью пользователя (работать продуктивно).

Избегать собраний

Удовлетворять требованиям клиента

Сохранять информацию о заказах клиента

Создавать математические модели бизнеса

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

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

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

Экономия памяти

Уменьшение потребности в клавиатурном вводе

Поддержка работы в броузере

Простота в освоении

Обеспечение целостности данных

Ускорение ввода данных

Увеличение скорости исполнения программы

Применение супертехнологии или супервозможностей

Улучшение внешнего вида

Сохранение единообразия интерфейса на различных платформах

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

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

Например, в 1996 году фирма Visioneer Соmpanу оттяпала изрядную долю рынка настольных сканеров у крепких конкурентов. Visioneer свершила свой замечательный подвиг с помощью старомодных черно-белых сканеров, которые на рынке состязались со сканерами конкурентов, способными сканировать в полутонах и даже в цвете. Однако продукт Visioneer включал программное обеспечение, ориентированное на цели и позволявшее пользователям с легкостью сортировать сканированные изображения и просматривать их, тогда как программы других производителей просто перекидывали изображения в сложную файловую систему.

Клиффорд Насс (Clifford Nass) и Байрон Ривз (Byron Reeves), два профессора Стэнфордского университета, изучают реакцию людей на компьютеры. Путем умелой переориентации классических экспериментов в социальной психологии они смогли пронаблюдать замечательное поведение. Свои открытия Насс и Ривз опубликовали в книге «The Media Equation»28 (Уравнение media). Авторы убедительно показали, что люди реагируют на компьютеры так же, как на других людей.

Насс и Ривз пишут, что

«…люди не доросли до уровня технологий двадцатого века»

и что

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

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

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

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

Когнитивист, исследователь мозга Стивен Пинкер из МТИ, подкрепляет этот тезис в своей замечательной книге29. Он пишет:

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

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

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

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

С другой стороны, если взаимодействие проникнуто уважением, благородством, содержит полезную информацию, то пользователю программа понравится и работать с ней ему будет приятно. Опять же, этот результат не зависит от типа интерфейса: интерфейс командной строки на зеленом фоне будет принят пользователями, если сможет реализовать перечисленные свойства.

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

Большинство хороших разработчиков программного обеспечения испытывают затруднения, когда им приходится проектировать вежливость. Роберт Кринджели (Robert Х. Cringely) говорит о программистах:

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

Можно видеть, как понятие «вежливость» или даже «человечность» может стать камнем преткновения, попроси мы программистов интерпретировать столь нечеткие концепции. Они сражаются против идеи превращения компьютеров в объекты с более человеческим поведением, потому что считают людей слабыми и несовершенными вычислительными устройствами.

Как-то я спросил своего друга Кейта Плиса (Keith Pleas), а он широко известен в сообществе разработчиков как сложившийся профессиональный программист, чувствительный к вопросам, связанным с пользовательским интерфейсом, о том, как сделать программы более человечными. Кейт интерпретировал «человечность» как внесение неточностей во взаимодействие. Он ответил:

Что, компьютер будет говорить неправду? Будет сообщать, что на банковском счету осталось «примерно $500»? Будет давать не тот ответ, который минуту назад дал кому-то еще? Если мы добавим человечности, это сделает наши системы менее компьютерными, по крайней мере, относительно текущей ситуации.

Реакция Кейта, как программиста, вполне естественна. Верно, компьютер не сообщает примерные суммы на балансах счетов, а еще компьютер не видит разницы между ответом «примерно $500», полученным за десятую долю секунды, и ответом «ровно $503,47», полученным за семнадцать минут. Действительно вежливая, более человечная программа сразу ответит, что на счету «примерно $500», а затем уведомит пользователя, что через несколько минут сможет сообщить более точную цифру. Теперь пользователь решает, тратить ли ему дополнительное время на более точный результат. Это принцип соразмерности усилий: если вы нуждаетесь в большем количестве информации, то подождете, пока она будет получена.

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

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

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

Вежливая программа интересуется мной

Вежливая программа относится ко мне уважительно

Вежливая программа обходительна

Вежливая программа ведет себя разумно

Вежливая программа предвидит мои потребности

Вежливая программа отзывчива

Вежливая программа не склонна делиться своими личными проблемами

Вежливая программа в курсе происходящего

Вежливая программа проницательна

Вежливая программа уверена в себе

Вежливая программа всегда сосредоточенна

Вежливая программа покладиста

Вежливая программа дает мгновенное удовлетворение

Вежливой программе можно доверять

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

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

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

К примеру, в записной книжке моей почтовой программы одиннадцать человек с именем Дэйв. С большинством из них я общаюсь редко, но среди этих людей мой лучший друг Дэйв Карлик (Dave Carlick), которому я постоянно отправляю сообщения по электронной почте. Когда я создаю новое сообщение и набираю в поле адресата неоднозначное имя «Dave», то ожидаю, что программа на основе моего поведения в прошлом сделает вывод, что я имею в виду Дэйва Карлика. Если я захочу отправить сообщение другому Дэйву, Дэвиду Фору, например, то наберу «Dave F», «D4», «David Fore» или что-то подобное, чтобы указать на необычность своего выбора. Но нет, программа каждый раз открывает диалог, заставляя меня выбирать, какого из одиннадцати Дэйвов я имею в виду. Программе на меня наплевать, она считает меня незнакомцем, хотя я – единственный известный ей человек.

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

Невежливая программа контролирует действия человека, которого всегда считает недостаточно компетентным. Приемлемо, если программа высказывает мнение, что я допускаю ошибку, однако не приемлемо, если она судит мои действия. Точно так же допустимо, если программа предполагает, что я не могу отправить заявку («Submit»), пока не укажу номер социального страхования, но если я все-таки отправлю заявку, не указывая свой номер социального страхования, то ожидаю от программы повиновения. (Само слово «Submit»32 и обозначаемое этим словом понятие антиподы уважительного отношения. Программа должна подчиняться пользователю, поэтому любая программа, предлагающая кнопку Submit, де-факто невежлива. Обратите на это внимание, держатели активных веб-сайтов.)

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

Если делаю заказ в ресторане, должно быть очевидно, что мне понадобится также нож, вилка, ложка, стакан воды, соль, горчица и салфетка.

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

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

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

Ходит много страшилок о том, как клиенты подвергаются оскорблениям со стороны иррационально рациональных компьютерных систем, постоянно присылающих чеки на сумму $0,00 или на $8943702624,23. Кошмары служб поддержки преимущественно отошли в небытие благодаря продуманной изоляции клиентов от компьютерных систем, однако сотрудникам компаний по-прежнему приходится взаимодействовать с такими системами. Сотрудники получают за это деньги, поэтому не склонны громко жаловаться, да и жаловаться обычно некому – служба поддержки клиентов обычно сотрудникам недоступна.

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

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

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

Мой компьютер обычно функционирует в видеорежиме, дающем разрешение 1024х768. На презентациях мне приходится временно уменьшать разрешение до значения 800х600, соответствующего более низкой разрешающей способности видеопроектора. Многие из моих программ, включая Windows 2000, реагируют на уменьшение разрешения изменением размеров и вида окон, а также их положения на экране. Однако я всегда и довольно быстро меняю разрешение компьютера обратно на 1024х768 точек. При этом окна, автоматически изменившиеся при переходе на более низкое разрешение, не восстанавливают свои настройки, подходящие для более высокого разрешения. Необходимая для этого информация существует в компьютере, но программа просто не восприимчива к моим очевидным потребностям.

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

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

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

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

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

При поиске в Интернете с помощью типичной поисковой машины я никогда не уверен в степени актуальности возвращаемых ссылок, что делает поиск бесполезным. Я щелкаю по интересующей меня ссылке и получаю только мерзкое сообщение «404 Link Not Found» (документ по ссылке не найден). Почему бы поисковой машине не проверять периодически каждую ссылку? Если ссылка умерла, то бесполезную запись можно выбросить из индекса базы данных, чтобы я не тратил свое время впустую.

Программы постоянно предлагают мне функции, которые по каким-то причинам в настоящий момент недоступны. Программе следует это понять самостоятельно и не предлагать мне такие функции.

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

Работая с приложением, я всегда разворачиваю окно во весь экран. Затем, при помощи панели задач я переключаюсь между окнами приложений.

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

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

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

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

Мне часто случалось подолгу работать с документом, затем нажимать кнопку Print и уходить за чашкой кофе, предоставив принтер самому себе. Затем я возвращался и обнаруживал бессмысленный ужасный диалог в центре экрана с вопросом: «Вы уверены, что хотите печатать?» Подобные сомнения приводят в ярость и являются антитезой, полной противоположностью вежливого человеческого поведения.

Если я заказываю салат в хорошем ресторане, мне приносят хороший салат. В плохом ресторане учиняется допрос: «Со шпинатом, Цезарь-салат или овощной? С луком? С гренками? С тертым сыром? Пармезан или романо? Полная порция или к обеду? Соус французский, итальянский, масло с уксусом, Тысяча Островов? Соус на тарелке? Подавать до или после главного блюда?» Даже самый требовательный гурман не настолько озабочен салатом, чтобы подвергаться такой мариновке, однако интерактивные системы ведут себя подобным образом постоянно. Приложение Adobe Photoshop печально известно своей способностью забрасывать пользователя многочисленными отвратительными и ненужными вопросиками, причем каждый появляется в отдельном диалоговом окне.

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

Выбор ведь тоже можно предлагать различными способами. Можно расставлять варианты, словно на витрине. Мы разглядываем витрину в свое удовольствие, изучая, выбирая или не обращая внимания на выставленные товары. Другой способ: варианты вываливаются на нас, словно недружелюбный допрос таможенником при пересечении границы: «У вас есть, что декларировать?». Таможеннику известно, что можно закрыть глаза на что угодно, однако раскрытие контрабанды может иметь более чем просто неприятные последствия. Мы не знаем о последствиях вопроса. Будут ли нас обыскивать? Если мы знаем, что обыска не избежать, то не станем лгать. Если знаем, что обыска не будет, то испытаем соблазн протащить через таможню лишний блок Marlboro.

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

После автоматизации его способность управлять системой исчезает. Практически не бывает автоматизированных систем, позволяющих внести элемент хаоса в процесс или воспользоваться каким-то преимуществом.

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

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

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

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

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

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

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

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

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

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

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

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

Между друзьями устанавливается доверие благодаря взаимозависимости и готовности жертвовать собой. О каком доверии может идти речь, когда компьютеры ведут себя странно и с неохотой работают на пользователей? Я доверяю кассирше в банке – ведь она улыбается и знает мое имя. Но при этом всегда пересчитываю деньги, полученные от банкомата, просто потому, что не доверяю этой тупой машине.

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

В числе интересных для нас проектов можно упомянуть небольшую начинающую компанию из Сан-Диего, компанию Elemental Software. Продукт компании, названный Drumbeat, представляет собой инструмент для создания динамических веб-сайтов, основанных на базе данных.

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

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

Уже созданный продукт обладал мощными возможностями, но создавался на основе размытых воззрений на конечных пользователей. Имеющимися функциями было трудно воспользоваться, и поэтому продукт получился не слишком мощным. Эд Форман (Ed Forman), новый вице-президент по разработке, сделал ставку на Cooper Interaction Design. Он сам был человеком достаточно новым и еще не до конца завоевал доверие программистов, поэтому наше присутствие могло стать источником переворота. Однако Эд отлично выступил в роли защитника и дал нам достаточно времени, чтобы пообщаться с его командой, узнать их, познакомить их с нашими методами.

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

Через несколько дней после начала проекта мы смогли дать имена и приближенные описания двум веб-разработчикам – Бетси и Эрни.

Бетси – дизайнер. Она носит черное и пьет эспрессо. Раньше была художницей, но потом ее укусил паук Web, и теперь она создает макеты экранов вместо макетов страниц. Она прочла достаточно книг, чтобы понять, как создавать симпатичные, хотя простые и статические, страницы для Всемирной паутины. Она овладела основами HTML, но не понимает и не хочет понимать в программировании ровным счетом ничего. Собственный сайт Бетси – мешанина модного дизайна, с размытыми шрифтами, лоскутами пастельных мазков, а также цитатами из Патти Смит и Эстер Дайсон.

Если Бетси требуется сложная обработка данных, ей приходится просить помощи у Эрни. Эрни – программист-спец нового поколения. Обожает компьютеры, компьютерные игры, компьютерные языки и компьютерное оборудование. В сравнении с программистами предыдущего поколения он пока немного легковесен: не знает языков С, C++, ассемблера, но невероятно умело обращается с инструментами вроде CGI, Perl, JavaScript и Visual Basic. Он знает сотни компонентов ActiveX и JavaBeans. Он способен создать достаточно функциональный модуль из сложных компонентов всего за несколько дней – та же работа в восьмидесятые годы заняла бы у программиста на C года четыре. Собственный сайт Эрни – случайная подборка цитат из «Звездного пути» и «Симпсонов». Здесь кричащий красный текст на черном фоне, восемь различных шрифтов, мигающий текст, потоковый звук, дергающиеся пиктограммы, кнопки Submit и ссылки на самые классные Quаkе-сайты.

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

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

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

Конкурирующие продукты также встали по разные стороны линии Бетси – Эрни. С одной стороны, несколько компаний создавали классные, новые инструменты для Эрни. Сложные и непростые в применении, эти инструменты позволяли Эрни создавать мощные, динамические, изощренные сайты для корпоративных клиентов.

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

Взглянув на поле битвы глазами Бетси – Эрни, мы все осознали, что здесь можно сделать сильный ход – дать Бетси инструмент, наделяющий ее более широкими возможностями. В результате Elemental создаст желанный продукт для еще не заполненного сегмента рынка. Программисты вскоре приняли имя «Бетси» в качестве боевого клича и сосредоточили усилия на том, чтобы ей помочь.

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

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

Возможности, предоставляемые Интернетом по мере его развития, росли очень быстро, и с такой же скоростью увеличивалась сложность создания сайтов. Сайты становились все мощнее, обретали дополнительную функциональность; появился прямой доступ к базам данных. Бетси уже не могла работать на столь низком уровне программирования. Кроме того, для нее программирование было совсем не столь привлекательным, и учиться она не хотела. Тогда она и встретила Эрни, способного решать за нее все технические проблемы. Он просто обожал все эти специальные штуки.

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

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

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

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

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

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

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

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

Случай интересен тем, что проектирование взаимодействия оказало значительное влияние как на внутреннюю структуру продукта, так и на позиционирование продукта на рынке. Это хороший пример, показывающий, как проектирование влияет на начинку, описывая всего лишь внешние проявления.

Разработчики Elemental поначалу решили, что наше решение не сработает, поскольку сразу представили себе ряд вырожденных случаев, когда Бетси все равно понадобятся особые таланты Эрни. «Нельзя совсем исключать Эрни из цикла, – заявили они, – поскольку Бетси может понадобиться решить какую-то особую или сложную задачу».

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

Независимость важна для Бетси, и ради ее достижения она готова на соразмерные жертвы. Drumbeat позволяет ей создавать полноценные сайты без помощи Эрни, и это примиряет ее с небольшими компромиссами в дизайне, открывающими доступ к готовым программам Эрни34. Жертва невелика, поскольку запросы большинства клиентов укладываются в стандартные схемы. Если она получит контракт на создание корпоративной сети для универмагов Wal-Mart или системы оперативного резервирования для отелей Hilton, то определенно задействует человека, обладающего талантами разработчика, чтобы он помог справиться с этими монументальными задачами, но в большинстве случаев это не требуется.

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

Участники нашей команды проектировщиков в один голос заявили, что панели назойливы, сложны и совершенно излишни. Разумеется, необходимо обеспечивать доступ к инструментам, но мы знали и более привлекательные способы. Однако каждый раз, когда мы отрицательно отзывались о панелях, программисты (и руководители разработки) тут же заявляли, что панели всем очень нужны.

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

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

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

Как проектирование, так и продукт стали успешными. Ближе к завершению работ над версией, основанной на наших исследованиях, Elemental удалось получить значительное венчурное финансирование, не в последнюю очередь благодаря инновациям во взаимодействии. После выхода в свет Drumbeat получил многочисленные положительные отзывы в отраслевой прессе. Эта цитата из журнала «РС» вполне отражает ситуацию.

«Drumbeat – продукт уникальный и впечатляющий, его возможности автоматизации сложных веб-задач превосходят все другие присутствующие на рынке решения. Продукт позволяет непрограммистам решать задачи очень просто. Вы сможете создавать огромные профессиональные сайты и даже применять технологию Active Server Pages, не написав и строчки кода.»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Мiсrоsоft Word, к примеру, стандартная панель инструментов содержит пиктограммы для загрузки документа, закрытия и печати текущего документа. Перечисленные задачи выполняются с разумной частотой, и присутствие пиктограмм оправданно. Однако здесь же, рядом, располагаются пиктограммы, генерирующие схему документа и внедряющие в документ электронные таблицы. Мiсrоsоft поместила эти пиктограммы в Основном рабочем пространстве, чтобы мы смогли оценить мощь Word. К несчастью, большинство пользователей к этим функциям так никогда и не обращаются, а если и обращаются, то вряд ли часто. Этим функциям просто не место на панели инструментов, потому что панель инструментов – это идиома интерфейса, обеспечивающая доступ к самым востребованным функциям.

Обычно самые мощные инструменты позволяют нам понять, представить личности наших пользователей, вжиться в них. Одну умозрительную модель мы применяем постоянно – она называется «вечные середняки». Большинство пользователей – не новички и не эксперты, они просто вечные середняки. Помните Рупака, Шэннон, Декстера и Роберто из главы 9, где речь шла об уровне подготовленности? Квалификации этих людей совершенно различны, но все четверо являются вечными середняками.

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

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

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

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

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

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

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

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

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

Каждый инженер представляет свой продукт в собственных терминах, но из-за необходимости программировать редко видит продукт в контексте конкретного пользователя (по крайней мере, конкретизация не достигает уровня, который я нахожу полезным). Мозговые штурмы позволяют нам избавиться от всех ограничений и ожиданий и начать проектирование с чистого листа, уделяя большое внимание персонажам и их целям. Мы часто проделываем упражнение на творческое мышление. Это упражнение называется «представь себе!» и заключается в прохождении сценария с «волшебным компьютером», не имеющим никаких ограничений.

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

В процессе проектирования и особенно в ходе мозговых штурмов я отдельно подчеркиваю необходимость создания и применения подробного и точного словаря. Я считаю, что технический нюанс проектирования интерактивных продуктов настолько важен, что единственное неправильно истолкованное слово может стать причиной краха целого проекта. Мне приходилось наблюдать, как разные участники команды клиента применяют распространенные слова вроде «кнопка» или «диалог» для обозначения качественно различных вещей. Мне вспоминается встреча с заказчиком, на которой десять высокооплачиваемых специалистов в течение двух часов ожесточенно спорили из-за разногласия, возникшего лишь потому, что различные участники пользовались различными определениями одних и тех же понятий.

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

Если слова не точны, программисты рефлективно ищут спасения в самом точном из доступных методов выражения: исходном коде. И хотя не существует ничего более точного, чем код, также не существует и ничего более крепкого и неподвластного изменениям. Поэтому часто путаница в терминологии заставляет программистов преждевременно начинать создание кода, и этот код становится проектированием де-факто, независимо от того, насколько такое проектирование уместно или корректно.

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

Наши термины не имеют ничего общего с теми, которые будут напечатаны на упаковке продукта. Наш словарь предназначен для внутреннего употребления, поэтому нас не заботит красота слов с точки зрения маркетолога. Слова должны быть всего лишь точны. Позже отдел маркетинга придумает слова, подходящие для завлечения покупателей. Продукт ScanBank компании Logitech изначально назывался «верстаком», это слово идеально подходило для нашего процесса проектирования и никогда не предназначалось для широкой публики.

В одном проекте наши проектировщики зашли в тупик. После долгих споров стало очевидно, что существуют расхождения в трактовке терминов. Наша дискуссия была неэффективна, потому что не было общего словаря. Я настоял на том, чтобы разбить проект на отдельные фрагменты, с которыми мы все согласимся, и дать фрагментам совершенно новые названия, не относящиеся к делу. Без особой причины я выбрал названия горных массивов Аляски. Четыре основных фрагмента продукта мы назвали «гора Святого Ильи», «Брукс», «Аляска» и «Рангелл». Мы хорошо посмеялись над неуместностью новых терминов, но после этого практически сразу достигли согласия и быстро стали продвигаться вперед.

Прежде всего, хороший словарь делает общение более эффективным. Однако создание терминологии иногда имеет и другой очень важный эффект. Время от времени нам приходится работать с командами, в которых определенные термины уже стали частью культуры. Хороший пример – фраза Мiсrоsоft «Embrace the Internet». Подобные фразы и слова могут иметь почти религиозное значение и произноситься с оттенками благоговейного трепета. Такое благоговение приводит к неспособности разобрать значение слова и повторно изучить его в свете новых императивов проектирования. Означает ли фраза, что следует идти навстречу браузерам, или же HTML, или же только протоколам ТСР/IР? Эти священные слова – забор вокруг храма. Растоптав священные верования клиента, мы не продвинемся в процессе проектирования. Поэтому мы разбиваем процессы, задачи, программы на четко определенные обособленные фрагменты и назначаем им новые имена, не имеющие унаследованного смысла. Эти новые имена, обычно еще и шутливые, и такое легкомыслие позволят «пробить» серьезные мины участников.

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

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

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

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

Инженеры испытывают тревогу, отступая от твердых рациональных основ, а потому предпочитают мириться с предполагаемыми ограничениями. Они знают, что мы в конечном итоге встретимся с этими ограничениями, а потому считают себя обязанными защищать их. Они называют это «ролью адвоката дьявола». Все это очень хорошо, но в чем окружающая действительность не нуждается, так это в том, чтобы ей помогали создавать трудности. Реальности не нужны адвокаты, поскольку от нее возможно отречься. Реальный мир всегда смеется последним. Зная, что реальность всегда найдет подходящий ответ, мы понимаем, что невозможное никогда не станет реальным, и здесь не спасают ни воображение, ни проектирование. Лишь человек, не заинтересованный кровно в успехе предприятия, может спроектировать что-то, что «невозможно» создать. Более того, мы часто обнаруживаем, что ограничения иллюзорны и надуманы. И это нельзя понять, не обойдя их.

Наш инструмент «представь себе!» оказался особенно полезным в одном крупном проекте. Подразделение корпорации Logitech, занятое производством сканеров, пригласило нас для участия в проектировании программного обеспечения для совершенно нового поколения настольных сканеров, ориентированных на рынки домашнего и малого офисов.

В новом сканере Logitech под кодовым названием «Peacock» были применены технологии сканирования нового поколения, а само устройство подключалось к компьютеру через новый порт USB. Этот недорогой продукт, по форме и размерам напоминающий свернутую газету, удобен и не занимает много места на столе. В прорезь сканера можно вставить любую страницу, после чего небольшой двигатель протягивает страницу через сканер, при этом происходит считывание изображения.

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

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

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

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

Как обычно, мы начали процесс с создания набора персонажей. Расскажу о том, как мы сконструировали этот набор.

Магазинная цена сканера была около $150. Для массового продукта это был достаточно мощный сканер с высоким разрешением и цветопередачей, однако до уровня профессиональных планшетных сканеров, стоивших обычно от $800 до $1000, он не дотягивал36. Всем было ясно, что основной рынок сбыта продукта формируют пользователи в домашних и малых офисах, известных под собирательным называнием SOHO (small office, home office).

Для представления сегмента пользователей SОНО мы создали персонаж Малкольма, бойца фронта Всемирной паутины. Этот молодой человек открыл на дому небольшую фирму по созданию сайтов. Он не разбирается глубоко в технических вопросах и не является дизайнером, однако знаком с компьютерами и знает, что оптимизированные изображения гораздо быстрее скачиваются из Интернета, чем здоровые, полноцветные. Сканер Peacock позволяет ему легко получить изображения среднего разрешения для сайтов, не неся излишних расходов и не вдаваясь в детали процесса.

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

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

Искрой стал персонаж по имени DPI Магнум. (Вариация на тему старого телешоу Тома Селлека «Magnum, Р.I.37» и аббревиатуры слов dots-per-inch, распространенной меры разрешения оцифрованного изображения.) Магнум представляет, возможно, не самый крупный сегмент пользователей, но человек он, несомненно, влиятельный. Все его друзья, владельцы домашних компьютеров, просят его совета, когда речь заходит о программном и аппаратном обеспечении для работы с графикой. Через год он сможет позволить себе планшетный сканер, но до тех пор обойдется аппаратом Peacock.

Малкольм и Чед не особенно разбираются в обработке изображений. Малкольм слишком сосредоточен на другом – ему нужно создавать сайты и зарабатывать деньги. У Чеда тоже иные интересы – не потерять изображения в глубинах файловой системы. Ни тот, ни другой не видят серьезных причин ковыряться в пикселах. Обоим требуется сканировать изображения, обрезать их, а затем внедрять в документы. Конечным результатом являются именно эти документы, а никак не изображения. Мы обнаружили, что три важных цели Малкольма и Чеда совпадают:

Они не желают разбираться в сканерах, разрешениях, настройках.

Они желают быстро и легко находить на своем компьютере уже отсканированные изображения.

Они желают легко и быстро внедрять отсканированные изображения в другие документы при помощи других программ.

DPI Магнум гуляет сам по себе: он хорошо знает, что такое разрешение и чувствует себя, как рыба в воде, манипулируя различными настройками. Таким образом, можно предположить, что включение подобной функциональности в продукт пойдет Магнуму на пользу. Однако Магнум уже приобрел Adobe Photoshop. Эта мощная, сложная, дорогая программа обработки изображении – его основной инструмент, и он отлично им владеет38. Для решения всех своих задач (не имеет значения, насколько мелких) он применяет Photoshop. Любая попытка продублировать функциональность и мощь Photoshop в рамках Peacock обречена. Как и Пи Герман39, вышедший на ринг против Джорджа Формана, Peacock не продержался бы и раунда против чемпиона. Нет смысла вкладывать усилия в то, что не найдет применения и станет позорным клеймом.

Однако же в двух случаях из трех цели Магнума идентичны целям Чеда и Малкольма: он желает легко находить свои изображения и легко переносить эти изображения в другую программу (Photoshop).

Лишь во время сканирования Магнуму может понадобиться указать физическое разрешение в точках на дюйм. В старых, более медленных сканерах понижение разрешения позволяло экономить время при сканировании, что Магнум и делал. Новый Peacock гораздо быстрее и дает максимальное разрешение, равное вполне приличным 200 dpi. При полноцветном сканировании процесс занимает около 20 секунд для формата А4. Потратив десять секунд на изменение режима, Магнум сэкономит лишь пять секунд при сканировании, но получит при этом более низкое качество, так что овчинка выделки не стоит. При достаточно высокой скорости сканирования придет ли в голову кому-нибудь – даже Магнуму – уменьшать разрешение? Такое проникновение в суть вещей позволило нам понять, что цели всех троих не противоречат друг другу, так что мы можем осчастливить пользователей и при этом избавиться от большинства ненужных возможностей продукта.

В ходе мозговых штурмов мы сыграли в игру «Представь себе!». Мы обнаружили, что Чед вполне доволен возможностью помещать изображения в компьютер, вообще не пользуясь сканером. Это упражнение показало, что ни Чеду, ни Малкольму, ни Магнуму не хочется разбираться с аппаратной частью процесса. С этого ракурса было легко увидеть, что Чеда интересовало только отсканированное изображение, причем после того, как оно уже попало в компьютер. Его не волнует, если изображение сканируется при помощи черной магии, однако интересует возможность потом найти это изображение, обрезать его и открыть в других программах.

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

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

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

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

• Исключили из интерфейса все идиомы управления сканером.

• Сделали невозможной потерю отсканированных изображений в дебрях файловой системы.

• Предельно облегчили перенос отсканированных изображений в документы других программ.

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

• Обрезка, отсечение изображения по краям.

• Изменение размера изображения.

• Изменение ориентации, поворот изображения.

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

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

Наш вариант инструмента решил обе проблемы простыми для освоения и понимания способами. На каждой из четырех сторон отсканированного изображения присутствует постоянно видимый якорь линии обрезки. Якорь является наглядным инструментом непосредственного манипулирования. Теперь Чеду достаточно щелкнуть по якорю и потащить за него, чтобы получить мгновенный и соответствующий действию наглядный отклик, оценить последствия своих действий. По мере перемещения якоря часть изображения, оставленная «за бортом», меняет свой цвет на призрачно-серый. Становится очевидно, что происходит обрезка изображения, но также ясно, что обрезка еще не произошла необратимо. Чед может так же легко перетащить якорь на прежнее место и таким образом восстановить фрагмент изображения.

Перемещая один якорь, Чед сразу понимает, что четыре стороны области обрезки независимы, что перемещение одной стороны не затрагивает три другие. Он может корректировать и изменять область обрезки, пока не получит нужный результат. Совсем другое ощущение оставляют традиционные инструменты обрезки, где процесс модален, необратим, должен выполняться одним идеальным движением. Очень немногие пользователи компьютеров обладают нужной ловкостью рук, позволяющей выполнить хорошо такое движение. И Чед определенно не входит в их число. Более того, обрезка должна быть наглядной и, как правило, итеративной. Даже художникам требуется несколько попыток, чтобы добиться нужного результата. Старые инструменты просто не поддерживали такой подход. А тот, что мы создали для Logitech, делал это замечательно.

Даже окончательный выбор Чеда не делал обрезку необратимой. Текущие настройки области обрезки считались просто свойством изображения, а изображение всегда хранилось в полном объеме (отдельный пункт меню позволял сделать обрезку необратимой, если требовалась экономия дискового пространства). Так что Чед мог отсканировать фотографию своей семьи, усечь изображение, исключив всех, кроме кого-то одного, например матери, а результат использовать в домашней работе и потом, месяца через три, вернуться к той же фотографии и изменить область обрезки, включив в результат только отца, и его фотографию поместить затем в письмо. Любая другая программа сканирования заставила бы Чеда повторно сканировать изображение.

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

Наше решение: небольшой красный уголок, располагающийся в правом нижнем углу отсканированного изображения. При наведении курсора уголок едва заметно меняется в размерах, увеличивается на пару пикселов. Это я и называю «активным откликом», он показывает Малкольму, что объект поддается прямому манипулированию. Если Малкольм щелкнет мышью и потащит за красный уголок, изображение (в реальном времени) станет больше или меньше, в зависимости от направления движения уголка. Изображение всегда сохраняет правильную пропорцию. Непропорциональное масштабирование – это уже работа Магнума, который для таких целей применяет Photoshop.

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

Графические программы обычно позволяют вращать отсканированное изображение. Вот три базовых применения этой функции:

• Вращение фрагментов изображений с целью изменения композиции.

• Придание нужной ориентации изображению, которое сканировалось с небольшим отклонением от вертикальной ориентации.

• Придание нужной ориентации перевернутому или перекошенному изображению.

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

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

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

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

Третий вариант – изменение ориентации. Можно случайно отсканировать изображение вверх ногами или «уронив» его набок. Программным способом можно легко и быстро повернуть изображение на 90, 180 или 270 градусов, сориентировав его правильно.

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

Если Малкольм щелкнет мышью и потащит за кружок, изображение опоясывает ярко-зеленый контур. Этот контур называется «прицелом» и подсказывает, как повернется изображение, когда Малкольм отпустит кнопку мыши. Как только кружок заходит за очередной угол изображения, зеленый прицел поворачивается в следующее из возможных положений: на угол 90, 180, 270 градусов. Малкольм заранее знает, какое влияние на изображение окажет его действие. Он отчетливо понимает, что поворот возможен лишь на фиксированные углы, а свободное вращение или коррекция результата невозможны. Все наши персонажи мгновенно понимают, как работать с инструментом.

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

Когда продукт Peacock вышел наконец на рынок, персонал отдела техподдержки Logitech забеспокоился, потому что звонков с вопросами о том, как пользоваться продуктом, поступило намного меньше, чем обычно для новых продуктов.

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

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

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

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

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

Гибридных продуктов становится все больше, и потребность в целеориентированном проектировании растет, потому что в смысле способов реализации оно агностично.

Продукт PalmPilot компании 3Соm – хороший пример гибридного продукта, в котором проектирование позволило гладко сшить программную и аппаратную части. Достаточно коснуться экрана, чтобы машина проснулась точно в том состоянии, в каком была выключена. Мгновенная реакция устройства на действия пользователя четко показывает, что при проектировании аппаратной части были учтены потребности программной части. А вот контрпример: моя фотокамера Nikon CoolPix 900, при каждом включении которой на загрузку, при отсутствии жесткого диска, уходит семь длинных секунд. Когда устройство настолько медлительно, становится ясно, что шоу режиссировали разработчики аппаратной части.

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

Однако если бюджет проекта позволяет, проектировщики могут без колебаний давать рекомендации относительно аппаратной части. Система P@ssport IFE, описанная в главе 9 «Проектирование для удовольствия», работала на выделенных компьютерах, и поставщик решения имел абсолютную власть над всеми устройствами и программами. Мои проектировщики дали некоторые рекомендации.

Продукт Elemental Drumbeat, описанный в главе 10 «Проектирование ради результата» должен был работать на любом нормальном настольном компьютере Wintel. В данном случае мои проектировщики о рекомендациях даже и не думали.

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

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

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

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

Гениальный программист и дизайнер Кай Краузе (Kai Krause) прославился своими уникальными интерфейсами. Кай создал некоторые из самых мощных и интересных программ для работы с графикой. Его продукты всегда имели захватывающе красивые интерфейсы, в то же время весьма загадочные, похожие на игры. Кай не только программист, но и дизайнер, и его продукты отражают стремление дизайнера делать вещи малопонятными, как в современном искусстве – чтобы произвести впечатление. Такой подход эффективен потому, что пользователи его продуктов – такие же дизайнеры и увлеченные люди. За рамки этого мира продукты Кая пробиваются с трудом.

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

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

Если проектировщик на верном пути, он урезает интерфейс продукта. Он вовсе не проектирует экран за экраном, наполняя их кнопками и штучками. Однажды нас посетил менеджер продукта из одной крупной компании, чтобы проконсультироваться по поводу перепроектирования продукта. В интерфейсе будет примерно десяток диалоговых окон, сказал он. Мы описали ему наш процесс, а затем дали оценку работы. Если мне не изменяет память, цифра составила $60000. «Возмутительно! – воскликнул тогда менеджер. – Это же $5000 за экран!» У меня не хватило духу сказать ему, что мы, вероятно, сократим количество диалогов до одного или двух, и тогда цена, если ее исчислять таким методом, станет гораздо выше. Он просто не понял, о чем речь. Платить за проектирование, исчисляя стоимость в экранах, все равно, что платить официанту за количество подходов к столику. Лучший официант меньше бегает, а лучший проектировщик всегда создает менее развесистые интерфейсы.

Иногда стезя проектировщика взаимодействия становится просто невыносимой! Если, выполняя свою работу, вы делаете что-то фундаментально, абсолютно, неоспоримо верное, все тут же восклицают: «Ну разумеется! Здесь же просто нет других вариантов!» Такова реальность, даже если клиент много месяцев и даже лет совершенно не имел понятия, как решить свою проблему. Такова реальность, даже если наше решение приносит компании миллионы долларов. Большинство действительно новаторских прорывов сложны в разработке и вполне очевидны задним числом. Невероятно сложно увидеть прорыв в проектировании. Можно получить подготовку, пройти обучение, потратить многие часы на изучение задачи, но не найти ответа. Затем приходит человек со стороны, указывает на ключевую концепцию, и тут же вся головоломка складывается в полноценное изображение с естественной очевидностью, присущей колесу. Если вы закричите о своем решении во весь голос, другие ответят: «Ну разумеется, колесо круглое! Какое еще оно может быть?» Так что похвастать хорошей работой по проектированию очень и очень сложно.

Ученый-компьютерщик Алан Карп говорит: «Практически все мои патентные заявки были отвергнуты как "очевидные"».

Когда я говорю «меньше интерфейса», то не имею в виду меньше функциональности, хотя и такое случается. Я имею в виду, что пользователя не следует заставлять взаимодействовать с программой дольше, чем абсолютно необходимо для решения тои или иной задачи.

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

Примечания:

2

Aegis (англ. эгида) интегрирует системы обнаружения и боевые системы корабля с целью противостояния ракетным атакам. – Прим. перев.

3

Честер Нимиц, командующий Тихоокеанским флотом США во время Второй мировой войны. – Прим. перев.

25

Из двух вариантов перевода «персона» и «персонаж» был выбран второй. Краткая справка: «персонаж» (франц. personnage, от лат. persona – личность, лицо) – действующее лицо пьесы (спектакля), сценария (кинофильма), романа и других художественных произведений. Второй термин ближе к функциональной смысловой нагрузке понятия и легче понимается неподготовленными лицами (программистами и руководителями). – Примеч. науч. ред.

26

Конестога (Conestoga) – местность в Пенсильвании, где были созданы фургоны такого типа. – Прим. перев.

27

Saul W. Gellerman «Motivation and Productivity», Amacom, New York, 1963.

28

Byron Reevs, Clifford Nass «The Media Equation; How People Treat Computers, Television, and New Media Like Real and Places», Cambrige University Press, 1996.

29

Steven Pinker «How the Mind Works», W.W. Norton & Company, 1997. Мне очень нравится эта великолепная, грамотная, увлекательная книга. Интересное чтение, открывающее глаза.

30

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

31

Robert X. Cringely «Accidental Empires, How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can’t Get a Date», Addison-Wesley, 1991.

32

В переводе с английского слово «submit» имеет значения «подчиняться», «покоряться», а также «представлять на рассмотрение». В программах и на веб-сайтах речь идет о последнем, однако это значение не является для слова «submit» основным. – Прим. перев.

33

Вообще-то, в полном наборе персонажей было больше, но Бетси и Эрни затмили всех.

34

Создание сайтов – это программирование, и Бетси точно так же не способна сопротивляться очарованию повторного использования кода.

35

Edward de Bono «Lateral Thinking, Creativity Step by Step» (Нестандартное мышление: Творчество шаг за шагом), 1970, Harper & Row, Publishers, New York.

36

Как обычно, время и пикирующие цены на продукты из кремния значительно изменили поле битвы сканеров, но в 1997 году ситуация была именно такая.

37

Частный детектив Магнум. – Примеч. перев.

38

Как бы мне хотелось перепроектировать взаимодействие в этой мощной сложной программе! Примечание: по меньшей мере шесть человек, читавших рукопись, подчеркнули эту сноску и добавили комментарии вроде: «И мне тоже!» и «Пожалуйста, сделай это!»

39

Pee Wee Herman – псевдоним американского комика Пола Ройбенса. – Примеч. ред.