Проектирующие программисты

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

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

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

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

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

Откуда вы знаете?

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

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

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

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

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

Руководства по стилю

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

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

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

Конфликт интересов

Потребуй Билл Гейтс публично от всех прочих компаний прекратить разработки в области проектирования взаимодействия, эти компании просто прогнали бы его со сцены. Однако документ Microsoft, озаглавленный «Interface Style Guide» (руководство по стилям интерфейсов), требует именно этого и является одним из самых сильных конкурентных преимуществ Мiсrоsоft.

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

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