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

Три главные мысли книги:

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

Цитаты

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

«Многие распространенные методы, особенно фокус-группы, основываются на предположении, что люди способны к интроспекции в отношении [интерактивного] опыта. Мы считаем, что такое предположение часто неверно».

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

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

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

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

Просто пишем код и выбрасываем на рынок, а там уж видно будет.

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

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

Когда я говорю «меньше интерфейса», то не имею в виду меньше функциональности.

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

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

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

Если вы закричите о своем решении во весь голос, другие ответят: «Ну разумеется, колесо круглое! Какое еще оно может быть?» Так что похвастать хорошей работой по проектированию очень и очень сложно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструкции по применению должны быть написаны у программы «на лбу».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Самая важная личная цель — сохранить достоинство, не почувствовать себя глупо.

Программист: «Что если пользователь захочет вывести это на печать?» Проектировщик взаимодействия: «Розмари печать не нужна». Программист: «Кому-то может понадобиться печать». Проектировщик взаимодействия: «Но мы проектируем для Розмари, а не для кого-то».

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

Преданные пользователи лично рекомендуют вас друзьям.

Поймет ли пользователь? Можем ли мы представить информацию в осмысленном виде? Подходит ли этот набор инструкций для целей пользователя? Какая информация является для пользователя первоочередной?

Необходимо сначала проектировать интерактивные продукты и только тогда начинать программирование.

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

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

Хотелось бы, чтобы продукт скрывал сложную функциональность или не содержал таковой вовсе.

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

Знаменитый идеолог UNIX Эрик Реймонд (Eric Raymond) говорит: «Хорошие программисты знают, что писать, великие — что надо использовать повторно».

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

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

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

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

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

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

Они чинят то, что не сломано, до тех пор, пока это не сломается.

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

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

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

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

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

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

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

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

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

Точно так же оператор бетономешалки может сказать плотникам, что они смогут начать создавать каркас, как только он закончит заливать бетон.

Она владела мощной технологией и адекватной деловой хваткой, но пострадала из-за полного отсутствия проектирования взаимодействия.

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

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

Выпуск первой версии QuickBooks должен был занять девять месяцев. Мы правильно оценили, что начальное развитие будет длиться столько же, сколько длится беременность, но все-таки ошиблись: у нас ушло почти два с половиной года — срок беременности слона.

Старая шутка Кремниевой Долины: «Как сделать небольшое состояние на программном обеспечении?» И ответ, конечно: «Начать с большого состояния!».

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

Билл Гейтс однажды заметил, с нетипичным для него цинизмом, как сделать программу дружелюбной к пользователю: изготовить печать и поставить на каждой коробке штамп «USER FRIENDLY»

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

Один руководитель сказал мне: «Наши люди уже пишут код, и я не собираюсь их останавливать». Эти ковбои думают: «Пока мы будем лететь к земле, я успею сшить парашют».

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

Первые 90% кода отнимают первые 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки

Успеем в Чикаго вовремя, но багаж придется выбросить!

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

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

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

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

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

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

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

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

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

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

Инженеры не занимаются строительством мостов, этим занимаются другие специалисты. Только в области программного обеспечения перед инженером ставится задача создать собственно продукт. Только в области программного обеспечения перед «строителем мостов» ставится задача определить, как следует создавать продукт.

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

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

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

чаще всего решения эрзац-проектировщиков склоняются в сторону пути наименьшего сопротивления

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

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

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

Инженерное дело и конструкторское дело так плотно пересекаются, что специалисты и руководители их не разделяют и, вероятно, не различают.

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

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

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

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

Самая нужная вам информация — информация об окружающем мире, и этой информации у вас нет.

Руководящий работник уже не может делегировать обработку информации специалистам, ведь бизнес и есть обработка информации.

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

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