Файл: Алан Купер Психбольница в руках пациентов.pdf

259 случае, обладающие абсолютной властью над программными артефактами, неизбежна берут на себя управление командой, обычна с заднего сиденья.
Круглый стал не дает желаемых перемен.
Подход демократичный, полидисциплинарный, многокультурный, никого не оставляющий за бортом, на не способный исправить ущербную последовательность, продолжающую отравлять взаимодействие.
Проектирующие программисты
Первыми «добровольцами» в борьбе с проблемами несведущих в технологиях пользователей стали сами программисты. Полная неприспособленность их культуры и инструментов для решения данной задачи не имела никакого значения ввиду отсутствия других кандидатов. Славно случайные свидетели, которым не повезло оказаться поблизости от места катастрофы, программисты получили задание организовать скорую помощь для интерфейсов лишь потому, что занимались родственными вещами.
Программисты - ничто без своего энтузиазма, и они гордятся сваей компетенцией, поэтому сложность проектирования взаимодействия привлекла их, и они приложили к решению задачи значительные усилия. Так появилась язвительная шутка:
«Проектирование - то, чем программисты занимаются двадцать минут перед тем, как начать писать код».
В этой книге я неоднократно показывал, что усилия программистов были обречены с самого начала. Как говорит По Бронсон, они считают отсутствие критики комплиментам, поэтому их оценка собственной производительности невероятно высока, и многие из них продолжают держаться за роль проектировщика взаимодействия. Славно безумные карали, программисты не желают сдавать захваченную территорию, даже если оккупация неприятна, невыгодна, нежеланна и непригодна для защиты.
Если вы программируете профессионально, та вы - программист независима от того, чему мажете научить, что протестировать или спроектировать. Как нельзя быть немножко беременной, так нельзя немножко заниматься программированием.
Многие разработчики все еще не признают существования серьезной проблемы
(«просто пользователи должны больше учиться»), но есть и такие, кто отчетливо видит всеобщее разочарование и финансовые убытки от широко продаваемых танцующих медведей. Хорошо, что группа последних растет, как растет и желание большинства

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

261 профессионалы, возможно, делают ошибки время от времени, однако их работа основывается не на догадках.
Мне приходилось видеть, как уважаемые специалисты по юзабилити попадают «в молоко». Они разрабатывали изощренные тесты для выделения отдельных реакций пользователей на существующие программы, а затем изучали таблицы с результатами, чтобы обнаружить дефекты интерфейса. Когда их точный научный метод вскрывал проблемную область, они скатывались до дилетантских рассуждений: «Что ж, полагаю, мы можем перенести эту кнопку вот в этот диалог» или «Думаю, если мы добавим здесь кнопку, пользователю будет удобнее».
Вполне можно сказать: «Я не знаю», однако попытка угадать ответ обречена на провал. Что еще хуже - вид человека, гадающего с отсутствующим взглядом, вызывает у программистов, людей, кровно заинтересованных в результате, однозначную реакцию.
Вас списывают со счетов как шарлатана.
Руководства по стилю
Сотрудничество дизайнера Шелли Ивенсон (Shelley Evenson) и ученого Джона
Райнфранка (John Rheinfrank) в исследовательском центре компании Xerox в Пало-Альто в восьмидесятые годы дало жизнь ряду важных идей в области визуальных коммуникаций. Они создали своеобразный словарь, «язык визуального проектирования» для всех фотокопировальных аппаратов Xerox: зеленый цвет обозначал оригиналы, синий принадлежности, а красный - зоны обслуживания. Схожие нетекстовые подсказки весьма полезны в интерфейсах, обладающих высоким когнитивным сопротивлением.
Такие подсказки содержатся в «руководствах по стилю», содержащих примеры и предложения по использованию.
Многие разработчики программного обеспечения и их руководители, раздраженные многочисленными проблемами взаимодействия, не отказались бы иметь подобное руководство, описывающее, какой интерфейс должен быть у продукта. Многие корпорации разработали руководства по стилю интерфейсов для всех внутрикорпоративных приложений, а многие поставщики программного обеспечения предлагают подобные руководства сторонним разработчикам, занятым производством совместимых программ.
Руководства по стилю могут помочь, но они не решают проблем взаимодействия, с

262 которыми связано целеориентированное проектирование. Эти проблемы решаются в каждом конкретном случае по-своему. Разные приложения нужны пользователям для разных целей, и каждый элемент взаимодействия в продукте должен относиться к чему- то определенному. Общий визуальный язык и последовательные органы управления способны помочь, но только их для решения проблемы будет мало.
Конфликт интересов
Потребуй Билл Гейтс публично от всех прочих компаний прекратить разработки в области проектирования взаимодействия, эти компании просто прогнали бы его со сцены. Однако документ Microsoft, озаглавленный «Interface Style Guide» (руководство по стилям интерфейсов), требует именно этого и является одним из самых сильных конкурентных преимуществ Мiсrоsоft.
Microsoft и Apple продвигают руководства по стилям интерфейсов, превознося их мощь и пользу, и на первый взгляд может показаться, что эти компании являются самым компетентным источником подобной информации. Однако интересы владельцев платформы конфликтуют с интересами разработчиков программного обеспечения.
Оба создателя платформ применяют скрытую форму принуждения, пытаясь заставить производителей придерживаться стандарта. Независимый разработчик программного обеспечения, не следующий рекомендациям руководства по стилю, не сможет заявить о «совместимости с платформой», лишая свой продукт важного плюса с точки зрения маркетинга. Таким образом, большинство компаний, создающих пользовательские приложения, готовы следовать рекомендациям разработчика платформы.
Требуя, чтобы независимые разработчики следовали описанным принципам, разработчики платформ исподтишка подавляют инновации.
Тем временем сами разработчики платформ вольны экспериментировать и давать ход новшествам, сколько пожелают. Они могут без угрызений совести пренебрегать собственными руководствами по стилям. Разумеется, никакие другие компании не нарушают эти руководства столь же часто и откровенно, как сами Microsoft и Apple.
Я не выступаю за сожжение руководств по стилю и за хаос в интерфейсах. Просто говорю, что к руководствам следует относиться так, как сенатор относится к лоббисту, а не так, как автомобилист к полиции.

263
Законодатель знает, что лоббист действует из корыстных соображений, он вовсе не третья сторона, не заинтересованная в вопросе.
Фокус-группы
Многие отрасли обнаружили ценность фокус-групп, позволяющих узнать, что нравится и что не нравится потребителям в различных продуктах. Но какими бы полезными ни были фокус-группы для проникновения в мысли потребителей о самых разнообразных продуктах, для бизнеса программного обеспечения они могут быть источником проблемы. Самая большая сложность состоит в том, что большинство людей, включая и профессиональных пользователей программ, не представляют, что может и чего не может программное обеспечение. Поэтому если участник фокус-группы просит включить какую-то возможность, этот запрос часто носит оттенок недальновидности. Пользователь просит того, что считает вероятным, возможным, разумным. Сознательно потребовать чего-то маловероятного, невозможного, неразумного - значит просто выставить себя дураком, а люди не делают этого добровольно.
Насс и Ривз из Стэнфордского университета изучали реакцию людей на компьютеры и получили убедительные свидетельства того, что собственная оценка людей таких реакций ненадежна. Они пишут: «Многие распространенные методы, особенно фокус-группы, основываются на предположении, что люди способны к интроспекции в отношении [интерактивного] опыта. Мы считаем, что такое предположение часто неверно».
Ларри Кили говорит, что «пользователи отвергнут новые идеи, если вы их предложите». Поэтому фокус-группы - сомнительный инструмент для создания сколько- нибудь новаторских продуктов. В большинстве продуктов, основанных на программном обеспечении, достаточно передовых решений, чтобы фокус-группы потеряли всякий смысл.
Фокус-группы могут быть эффективными для определенных категорий продуктов, однако ошибочно будет доверять им в надежной оценке продуктов с высоким уровнем когнитивного сопротивления.
Визуальное проектирование
В книге «AboutFace» я показал, почему вовсе не графическая основа графического

264 пользовательского интерфейса (ГПИ)
1
сделала его доминирующей формой взаимодействия с компьютером. Скорее, дело было в жестко ограниченном словаре новых интерфейсов. Эта ограниченность и дала ГПИ (в английском варианте GUI
(Graphical User Interface)) такое преимущество перед прежними зелеными экранами.
Качественный дизайн может стать хорошим вкладом в качество интерфейса, однако многие игроки отрасли все еще приписывают дизайну ценность, которой он попросту не обладает.
Я только что вернулся с конференции COMDEX в Чикаго, где судил конкурс по проектированию и созданию прикладных программ для внутрикорпоративного использования
2
. Одно из первых мест заняла программа управления продажей билетов для ежегодного съезда любителей авиации в Висконсине. Кассовый терминал - сердце системы – преднамеренно был сделан неграфическим. Небольшой текстовый экран был необыкновенно строгий, прямоугольный, эстетически примитивный. Однако программа уверенно вышла в лидеры, поскольку при проектировании пристальное внимание уделялось особым потребностям команды добровольцев, занятых продажей билетов у этих добровольцев была ответственная, но простая работа, причем работу эту надо было выполнять быстро и с минимальной подготовкой. Графические интерфейсы замечательно подходят для информирования руководителей о положении дел в целом, но у пользователей описываемого терминала таких потребностей не было, поскольку каждый следующий клиент из очереди не имел ничего общего со всеми остальными клиентами в очереди. Видеть картину в целом в требования к программе не входило.
Простого текстового экрана вполне хватило, чтобы продукт завоевал награду. Об этом уроке забывают многие профессионалы.
Одна из характерных особенностей ГПИ заключается в их способности отображать растровую графику. Можно запросто делать программные интерфейсы, насыщенные сочной графикой, как в игре Myst. Поэтому многие дизайнеры и художники с радостью наложат грим из привлекательной растровой графики на лицо вашей программы. Однако графические дизайнеры редко задумываются о сопутствующем взаимодействии.
Этот интерфейс - одна из тех бесполезных «красивостей», которые вы получаете вместе с новыми компьютерами, и он - до самой последней копейки - стоит тех денег,
1
В английском варианте GUI (Graphical User Interface). – Примеч. науч. ред.
2
Конкурс проводится уже семь лет и называется Windows World Open. Спонсируется компаниями Microsoft, ComputerWorld и Ziff-Davis Events.

265 которые вы заплатили. Его назначение как-то связано с телефоном или приводом CD-
ROM, точно не могу сказать. Интерфейс, несомненно, прекрасен, особенно если вы технофил, влюбленный во всякие примочки, однако способ работы с программой непостижим. Это пример того, что мы называем «росписью по трупам». Программисты взяли интерфейс, не подлежащий использованию из-за фундаментальных дефектов в поведенческом проектировании, и завернули его в привлекательную обложку.
Поставщики устройств, похоже, особенно увлечены таким подходом, ведь программа шла в комплекте с моим новым компьютером. Подозреваю, дело в том, что интерфейс метафорически следует представлениям о классном аппаратном обеспечении.
Мы часто видим красивые продукты, эстетика которых великолепна, а функциональность или способы взаимодействия неадекватны назначению. Причина не в том, что продукт не проектировался, а в том, что он проектировался дизайнером, а не проектировщиком взаимодействия, имеющим инструменты для борьбы с когнитивным сопротивлением.
Промышленный дизайн
Другая область, к представителям которой обращаются за экспертизой, это промышленный дизайн. Эта хорошо развитое и сформировавшееся ремесло создания трехмерных объектов, приспособленных для вашего взгляда, вашего тела и особенно для ваших рук. В целом промышленные дизайнеры достигают отличных результатов, и упрекать их можно разве что в недостатках, но не в проступках. Они обучаются созданию кнопок, регуляторов и органов управления, которые легко увидеть, нащупать, применить. Однако они не подготовлены специально ни к разрешению проблем

266 когнитивного сопротивления, ни к сотрудничеству с разработчиками программного обеспечения. Кнопки мгновенно опознаются как таковые (для примера возьмите систему дистанционного замка из главы 2 «Когнитивное сопротивление»), даже на ощупь. Их физическое назначение интуитивно понятно, однако логическое назначение
(метаназначение) остается неясным, как прежде.
Каждый из пяти пультов на моем кофейном столике в отдельности сделан хорошо, но все вместе они делают мой домашний развлекательный комплекс практически бесполезным. Обладая привлекательным внешним видом, эти пульты бесполезны, если требуется переключить канал или заглушить звук в темноте. Дизайнеры, создавшие эти пульты, удовлетворили требования разработчиков развлекательных систем, но не удовлетворили потребности пользователя в качественном взаимодействии.
Легко понять, почему менеджеры продуктов путают промышленный дизайн с проектированием взаимодействия. Промышленные дизайнеры тоже имеют дело с интерфейсом между людьми и продуктами высоких технологий. Они тоже облегчают людям применение высокотехнологичных штуковин. Кнопки можно легко найти и нажать, но это не означает, что пользователь поймет, какую именно кнопку следует нажимать. Это проблема когнитивного сопротивления, а не промышленного дизайна.
Классная новая технология
И последний претендент на трон проектирования взаимодействия - сама технология.
Microsoft, в частности, усиленно навязывает эту ложную панацею. Например, Мiсrоsоft утверждает, что интерфейсы упростятся, как только разовьются технологии распознавания голоса и рукописного ввода. 'Уверен, что это глупость. Каждая новая технология всего лишь добавляет возможностей для приведения пользователей в отчаяние – при помощи систем более быстрых и более мощных.
Ключ к более качественному взаимодействию кроется в уменьшении неопределенности между компьютерами и пользователями. Обработка естественных языков никогда не даст такого эффекта, поскольку значения слов в человеческой речи весьма расплывчаты. Наше общение столь часто основано на нюансах, жестах и интонациях, что появившиеся системы распознавания слов еще очень долго не смогут
(если вообще смогут) научить компьютеры интерпретировать значения наших фраз.
Технология распознавания голоса определенно принесет пользу многим продуктам.

267
Но, полагаю, было бы излишне оптимистично надеяться; что какая-то новая технология сможет просто спасти нас, сделать то, что до сих пор не было сделано. Технология требует проектирования взаимодействия для создания законченных решений для пользователей, независимо от того, какое сочетание технологий используется.
Итерации
Расхожая истина о разработке программного обеспечения гласит, что добиться качественного взаимодействия можно только поэтапным улучшением. Приверженность юзабилити-тестированию во многих крупных компаниях, в частности в Microsoft, привела к распространению этой идеи. Конечно, итерации - важный элемент качественного проектирования: продолжаем работать, пока не получим правильное решение. Однако многие разработчики поняли идею иначе: плюем на проектирование и просто пересчитываем в темноте все кочки, какие есть на дороге.
В 1986 году компания Мiсrоsоft поторопилась на рынок с первой версией Windows, которая была столь смехотворна, что заслуженно стала предметом шуток. Шесть месяцев спустя Мiсrоsоft выпустила версию 1.03 и исправила некоторые дефекты. Годом позже
Microsoft выпустила версию 1.1, а затем версию 2.0 1
. На каждом этапе развития продукта разработчики пытались разрешить проблемы, созданные в предыдущей версии. Наконец, четыре года спустя после выпуска первой версии, Мiсrоsоft представила Windows 3.0, и все перестали смеяться. Мало какие компании в этой индустрии имеют такое упорство и финансовые возможности, позволяющие выдержать четыре года публичного унижения и добиться, наконец, приемлемого результата. При этом все наблюдают, как лидер де- факто слепо спотыкается практически до победного конца, после чего делают очевидный вывод о том, что именно так и нужно действовать.
Однако создание всех этих промежуточных версий дорого обошлось компании.
Если бы Microsoft достигла уровня качества Windows 3.0, пропустив пару промежуточных версий, она сэкономила бы миллионы на разработке и поддержке, при этом заработав дополнительные миллионы на продажах - на более раннем этапе жизни продукта. Позиция, защищающая неизбежность создания многочисленных версий продукта, - весьма дорогостоящее убийство здравого смысла.
1
В нумерации версий продуктов Microsoft совершенно нет логики. Windows 3.0 предшествовали по меньшей мере четыре значительных издания системы. Очевидно, что Windows 3.1 – радикально иной и улучшенной версии, содержащей массу серьезных изменений, следовало дать название Windows 4.0. Уверен, что маркетологи Microsoft дали этой версии номер 3.1 потому, что не хотели терять рыночную нишу, уже завоеванную «третьей версией».