Что послужило причиной написания этой книги

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

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

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

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

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

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

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

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

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

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

Когнитивное сопротивление

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