Алан Купер - Психбольница в руках пациентов

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

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

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

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

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

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

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

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