Целеориентированное проектирование по А.Куперу

A.Kuper Psihbolnica v rukah pacientov

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

Как обстоят дела сейчас

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

Человеку свойственно ошибаться, но чтобы провалить дело капитально необходим компьютер

Успешный профессионал XXI века – это либо инженер, сведущий в бизнесе, либо бизнесмен, сведущий в технологии

Действия без планирования всегда чреваты риском потратить слишком много

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

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

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

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

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

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

О когнитивном сопротивлении

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

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

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

Танцует медведь просто ужасно, но чудо не в том, что он танцует хорошо, а в том, что вообще танцует.

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

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

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

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

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

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

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

Об инженерах и инженерном процессе

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

Семь привычек крутых инженеров». Эти определения невероятно точны, хотя и гиперболичны.

  1. Они щедры в своем эгоизме.
  2. Слепота улучшает их зрение.
  3. Они кусают не только руку кормящего, но еще и собственные руки.
  4. Они готовы приложить любые усилия, чтобы сохранить впечатление, будто их не заботит собственный имидж.
  5. Они чинят то, что не сломано, до тех пор, пока это не сломается.
  6. «Не я дал неверный ответ, а вы задали не тот вопрос».
  7. Считают отсутствие критики комплиментом.

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

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

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

Суть хорошего программирования в отсроченном вознаграждении. Выкладываясь в начале, вы пожинаете плоды позже.

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

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

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

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

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

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

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

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

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

Целеориентированное проектирование

Он перечисляет: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми покрышками; 3) трансмиссия, связывающая двигатель с ведущими колесами; 4) трансмиссия и двигатель смонтированы на ходовой части; 5) рулевое колесо. На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя: 6) быстро и легко срезает траву; 7) на этом удобно сидеть. На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.

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

Вы добьетесь гораздо большего успеха, проектируя для единственного человека.

Наша же цель состоит в проектировании программ, которые будут изгибаться, растягиваться и адаптироваться к потребностям пользователя.

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

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

Более того, наиболее важными целями считаются личные цели, интересующие одного конкретного человека.

Тед не хочет, чтобы новая вещь его унижала, он не хочет, чтобы из него делали идиота. Тед не хочет совершать ошибки. Ему нужно чувство достигнутого результата, и чем скорее, тем лучше. Он хочет развлечься.

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

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

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

Кейт интерпретировал «человечность» как внесение неточностей во взаимодействие.

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

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

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

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

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

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

Компания перестает быть производителем продуктов, изобретающим вещи, которые можно продавать клиентам, и становится обслуживающей компанией, выполняющей работу по запросам

У клиента могут быть деньги, однако клиент не обладает двумя важнейшими качествами: 1) он не заботится о ваших интересах и 2) не знает, как проектировать ваш продукт.

Неважно, насколько у клиента благие намерения, он не обладает способностью воспринимать ваш продукт, как единую концептуально целостную сущность.

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

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

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

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

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

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

Главная рекомендация этой книги: за качество продукта в конечном итоге должен отвечать проектировщик взаимодействия.

Заключение

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