Методы промышленного дизайна

Еще одна профессиональная отрасль, к которой нередко обращаются за получением экспертного мнения, – это промышленный дизайн. Эта отрасль представляет собой давнюю, устоявшуюся практику профессионального создания трехмерных объектов, которые хорошо адаптированы под ваши глаза, тело и в особенности под ваши руки. Если говорить в общем, то промышленные дизайнеры делают отличную работу, но в применении к программам их преимущества оказываются скорее недостатками. Они обучены создавать элементы управления, которых можно легко коснуться физически, рассмотреть их и производить с ними различные манипуляции, – кнопки, ручки, регуляторы. Но они не имеют специальной подготовки для того, чтобы должным образом справляться с когнитивным сопротивлением или взаимодействовать с разработчиками программ. Как в случае с системой бесключевого автомобильного доступа, описанной в главе 2 «Когнитивное сопротивление», пользователь легко сможет опознать кнопку даже на ощупь. Что с ними делать физически – нам совершенно ясно, а вот их логическое назначение (метафункция) по-прежнему вызывает массу вопросов.

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

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

Новая первоклассная технология

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

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

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

Итерации

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

В 1986 году компания Microsoft наскоро выпустила на рынок самую первую версию Windows, которая оказалась настолько жалкой, что справедливо стала посмешищем всей индустрии. Полгода спустя компания представила версию 1.03, в которой были исправлены некоторые мелкие погрешности. Еще через год Microsoft выпустила версию 1.1, а чуть позже – версию 2.0^[38]. В ходе каждой следующей итерации разработчики продукта пытались справиться с проблемами, возникшими в предыдущей версии. Наконец, спустя четыре года от начала выпуска первой версии компанией Microsoft была представлена Windows 3.0, и только тогда смех в индустрии утих. Не так много компаний в этой индустрии обладают такими финансовыми возможностями или, может быть, стойкостью, которые позволили бы им выносить публичное унижение в течение четырех лет и в итоге все же создать оптимальное решение. Побочным эффектом этой ситуации является то, что вся индустрия следит, как признанный лидер делает неуверенные шаги, словно незрячий, до тех пор, пока все наконец-то не встанет на свои места. Как следствие, индустрия принимает очевидно абсурдное решение считать такой подход единственно верным.

Тем не менее для Microsoft создание такого множества промежуточных версий стало весьма затратным предприятием. Если бы компания пошла несколько иным путем и довела продукт до качества Windows 3.0, не выводя на рынок пару промежуточных версий, ей удалось бы сэкономить порядка нескольких миллионов долларов на разработке и поддержке продукта и заработать дополнительные миллионы за счет продаж на более раннем этапе жизненного цикла продукта (к слову сказать, пользователи бы тоже сэкономили миллиарды долларов и избежали многих головных болей). Принимая как данность неизбежный выпуск множественных версий продукта, разработчики и компании просто-напросто вынуждают здравый смысл капитулировать и при этом несут огромные затраты.

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

Подобная стратегия, основанная на истощении противника, является не только затратной, но также требует огромного количества времени. Более того, она невероятно отвратительна, поскольку унижает человеческое достоинство пользователей, которые применяют компьютерные технологии. К сожалению, для Microsoft эта стратегия оказалась неплохой находкой. Раз за разом компания выводит на рынок «полуфабрикаты» – непродуманные, некачественные в отношении проектирования и конструирования продукты, вызывая насмешки обозревателей индустрии – как приверженных компании, так и беспристрастных. Но несмотря на издевки экспертов, Microsoft продолжает поддержку своих изначальных версий продуктов выпусками вторых, третьих, четвертых, пятых и одиннадцатых версий. В результате продукты этой компании, среди которых Windows, ActiveX, Word, Access, Windows NT и множество других, превратились в гигантов соответствующих рынков.

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

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

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

Управляемый процесс

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