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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PS. В завершении я переключаюсь из режима пользователя (или сочувствующего им) в режим программиста. Как же меня раздражают программы, которые намеренно ограничивают пользователя, считая его недостойным для выполнения некоторых действий, например для записи на флеш-карту. Да, это кивок в сторону Android 6. А еще меня раздражают программы, которые пытаются скрыть от пользователя файловую систему, не давая выбирать, куда сохранить создаваемый файл, хотя Купер как раз считает это нормальным, что пользователь не обязан разбираться в файловой системе. И да, я тоже ворчу на пользователей, которые не знают, что такое корень диска D: под Виндой, и что Интернет и Firefox — это не одно и то же, а почтовый ящик — это не программа Outlook. И поэтому мне ужасно не нравятся мобильные платформы — я не могу проконтролировать, что там происходит в данный момент.

Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.

Пожалуйста, оцените запись

УжасноПлохоТак себеХорошоОтлично (Количество голосов: 3, средняя оценка: 5,00)
Загрузка...

комментария 2

  1. Денис Сепетов:

    А ведь и правда… Я как-то уже поймал себя на мысли, что сразу начинаю писать код, а проектировать уже в процессе. Пожалуй, только один раз долго посидел ПЕРЕД началом разработки, подумал, порассуждал, обмозговал, а потом нанчал кодить. Результат и правда лучше. Вот бы так всегда.

  2. Алексей:

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

    IMHO, это та самая проблема 100% пользователей, которые используют лишь 20% функционала. Но, ЧСХ, каждый из них использует РАЗНЫЙ функционал и общей кучей они покрывают все 100%. Именно поэтому LibreOffice всё ещё остаётся лишь бледным подобием MSO, а GIMP — бледным подобием Adobe Photoshop: там тупо недостаёт функционала.

    Вот вы, например, пробовали найти аналог фотошоповского Slice в бесплатных графических редакторах? А я пару лет назад пробовал и, в итоге, написал собственный плагин для paint.net. Такие дела…

Leave a comment

Subscribe without commenting