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

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

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

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

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

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

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

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

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

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

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

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

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