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

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

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

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

Различать задачи и цели просто. Задачи меняются вместе с технологией, тогда как цели обладают приятной особенностью – они очень стабильны. Например, в путешествии из Сент-Луиса в Сан-Франциско мои цели – скорость, удобство, безопасность. Направляясь в Калифорнию на золотые прииски где-нибудь в 1850 году, я путешествовал бы в своем новом, высокотехнологичном фургоне Конестога 26 26 Конестога (Conestoga) – местность в Пенсильвании, где были созданы фургоны такого типа. – Прим. перев. . В интересах безопасности я взял бы с собой ружье «винчестер». Направляясь из Сент-Луиса в Caн-Франциско в 1999 году, я путешествую в новом, высокотехнологичном Боинге-777. В интересах безопасности «винчестер» имеет смысл оставить дома. Мои цели остались неизменными, однако задачи изменились вместе с технологиями настолько, что стали прямо противоположными.

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

Цель – стабильная сущность. Задачи преходящи. Вот одна из причин, по которой проектирование под задачи не всегда уместно, а проектирование под цели уместно всегда.

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

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

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

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

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