Рецензии на книгу «Психбольница в руках пациентов» Алан Купер
Самая правильная книга, объясняющая, почему мы живем в таком неудобном мире. Это книга о проектировании взаимодействии, именно взаимодействии - тонкой прослойке между программами, машинами и человеком.
Лично мне, книга открыла глаза, почему старшему поколению так тяжело дается компьютер, банкомат, сотовый телефон, стиральная машина, все то, где есть электроника и программирование. Раньше, как системный администратор, думал - "Люди ленивы - они не хотят читать инструкции". Сейчас же - "Почему они сделали такое сложное взаимодействие?".
Эту книгу необходимо прочесть всем, кто создает что-либо для людей. Неважно, программу, пульт управления, мп3-плеер, сотовый телефон или же печатает отчет для руководства.
Классический пример банкомат:
Вставляем карту, вводим ПИН-код, набираем сумму для снятия (1750 рур) и вываливается ошибка: "В банкомате отсутствует запрашиваемая сумма". Сообщение понятно, но информативности в нем 0.00. Почему бы уважаемым инженерам сразу не написать какая сумма присутствует? Например "В банкомате отсутствует запрашиваемая сумма. Закончились 50 рублевые купюры." или "... но вы можете снять 1500 рур."
Итак, эта книга должна быть прочтена в обязательном порядке: дизайнерами, проектировщиками, инженерами, программистами, проект-менеджерами, разработчиками человеко-машинных интерфейсов, разработчиками графических интерфейсов, людьми которые хотят "опускать" программистов.
Эту книгу бессмысленно читать: разработчикам, которым плевать на пользователей, людям, чей труд не связан с созидательностью.
Как выразился мой коллега, "беллетристика". Я с ним согласен. 320 страниц материала, а реально полезное можно было в 20 уложить. Видимо Купер все повторяет по 50 раз, чтобы мы это получше запомнили. Интересно было читать серединку, где описывались реальные конкретные примеры успешного проектирования. Книга смахивает на рекламу его компании, какие они крутые и успешные. Все остальное - это лишь многочисленные изливания о том, как все щас плохо и как надо чтобы было хорошо. Кроме того, материал уже морально устарел с 1998 года, интерфейсы сильно поменялись. Тот же Майкрософт, который Купер всячески поддевает, стал производить существенно лучшие продукты в плане удобства, чувствуется, что отношение поменялось к процессу. Короче, надо что-то конкретное и современное. Тратить время остальным людям на эту книгу не советую.
В целом книга содержит важные и уместные замечания на тему важности вдумчивого взаимодействия людей и машин. Но по-американски затянуто с многократным разжевыванием каждой мысли. Почитать можно, если хватит терпения продраться сквозь предисловие переводчика, многочисленные благодарности автора всем на свете, воспоминания автора о том как писалась эта книга и прочий мусор.
Внедрение компьютеров в нашу жизнь мчится вперед семимильными шагами. Книга, написанная почти 20 лет назад, уже прилично устарела по ряду технических данных, но, увы, многое в ней осталось актуальным до сих пор. И сейчас, когда уже практически каждый школьник умеет программировать, впечатление, что руководство не научилось внимательнее относится к программным продуктам. Я не буду уж описывать серьезные специализированные программы, с которыми сталкиваюсь по работе, хотя и там время от времени у меня возникает подозрение, что программист пишет функционал просто потому, что он так умеет и так может, а вовсе не потому, что такой функционал нужен конечному пользователю. Но возьмем элементарные сайты. Для многих фирм: интернет-магазинов, турбюро, сайтов авиакомпаний, удобный сайт - это их хлеб. Но как часто приходится сталкиваться с простейшими неудобствами. Наиболее классические ошибки - сброс введенной информации о пользователе из-за неправильной графы. Скажем, пароль вы ввели недостаточно защищенный. И есть масса вариантов это предотвратить, тут и запоминание информации, со стиранием только графы пароля, и, в конце концов, предварительное информирование, пароль какой сложности минимально доступен для вашего сайта. Но программист не догадался, ставящий ему задание не подумал,а в результате пользователи чертыхаются, по четвертому разу вводя данные. Тут и время ввода информации, о котором пользователя не предупреждают, но после которого вся введенная информация, включая номера паспортов и свидетельств о рождении сбрасываются и вас вежливо уведомляют, что надо бы еще раз выбрать нужный Вам рейс, вдруг уже изменилось число мест. Приводить примеры еще можно долго. Это не только будило во мне раздраженного пользователя, но и вызывало чисто профессиональный гнев к неряшливой работе. И я была рада, что когда-то, еще на заре развития всеобщей компьютеризации, нашелся человек, который все это свел воедино, описал эти проблемы, заставил посмотреть на них иным взглядом, а не привычным нам: ну, что ж вы хотите, надо учиться пользоваться компьютером, и предложил свои методы решения. Конечно, учиться все равно придется. Если пользователь компьютера не запоминает папку, в которой хранится ее файл, это все же говорит о ее низкой квалификации, а не о недостатках компьютера. (Тут мы с автором расходимся во мнениях.) Ведь помним же мы на какую полку положили документы и в каком шкафу их искать. Но, быть может, в будущем Сири или Алиса смогут помогать и в этом: дорогуша, найди-ка мне файл, над которым я работала вчера после обеда, и, вуаля, он перед нами. Но пока что компьютером все же надо уметь управлять более механизированными способами. А программисты (вернее, их руководители) должны ставить себя на место пользователей и делать программы эргономичнее, упрощая их эксплуатацию. Пусть эти маленькие и большие черные и белые коробочки приносят нам больше радости, а не раздражения. Автор постарался описать нам и действия, с помощью которых можно прийти к качественному результату. В некоторых случаях это выглядит замечательно, в некоторых, как мне кажется, может и не сработать, но, в любом случае, в книге изложено много интересных мыслей, и она заставляет взглянуть на проблему под другим углом.
Теперь, после прочтения столь нашумевшего бестселлера, я понимаю почему эта книга меняет мировозрения разработчика. Теперь я отчётливо понимаю, почему меня бесят Internet Explorer, который не сохраняет вкладки при закрытии, банкомат, который выкидывает мне карточку и чек с надписью "Неправильно введён пин-код"... причина в том, что о проектировании взаимодействия этих интерфейсов (как программных, так и аппаратных) никто даже и не задумывался. Разработчиков ограничивают либо технологии, либо лень, либо собственное самолюбие: накрутить по-больше красивостей и кнопочек, которыми никто не пользуется. А пользователя лучше заставить считать себя идиотом, чем дать ему возможность откатить изменения неправильного шага.
Так что же могут сказать проектировщики на все те нелепые и выбешивающие недостатки интерфейсов, которые они создают?
Источник
Вы не найдёте в этой книге ничего о том, как правильно надо проектировать интерфейсы, но вы узнаете, как правильно строить в первую очередь успешный для бизнеса продукт и как правильно распределять роли внутри команды. Всем, кто имел хотя бы косвенное дело с разработкой продукта будут знакомы все боли, которые описывает Алан Купер, и мне понравились некоторые решения, которые он предлагает.
Во-первых, нужно сместить акценты с тестирования на проектирование. И проектирование продукта не должно идти параллельно с написанием кода, на проектирование должно быть выделено в 2 раза больше времени, чем на написание кода, и это сэкономило бы кучу денег многим компаниям, примени они это правило на практике.
Во-вторых, использовать метод персон. Убирать никому ненужный и сложный функционал из продукта, думать о том, чтобы продукт вызывал наименьшее когнитивное сопротивление у среднего пользователя.
В-третьих, проектировщик взаимодействия - это отдельная должность, программистов нельзя подпускать к проектированию. Проектирования для программистов - это те 20 минут перед тем, как они начинают писать
код. У них совершенно другой склад мышления и свои выгоды при разработке.
Проектировщик должен думать, как привлечь людей и чего они желают, его задача - понять, как должен вести себя продукт, чтобы люди получали удовольствие от взаимодействия с ним и чувствовали себя счастливыми. Программы должны вести себя так, как симпатичный нам человек, обладать обходительностью и вежливостью.
Но продукты "пляшущие медведи" вызывают неприязнь и раздражение у пользователей, только потому что технические специалисты захватили всю власть в компаниях, они решают, что будет реализовано, а что нет, воспринимая инструкции, как рекомендации. Они готовы с радостью поступиться простотой приложения ради возможности всё контролировать. Ещё забавное замечание Купера - "подкуп в случае с программистами работает гораздо эффективнее, нежели просьбы".
Ещё понравилась мысль Купера о том, что прислушиваться к мнению клиентов хорошо, но выполнять все их пожелания - это плохое решение. Компании, ведомые клиентами получают легкие деньги в краткосрочной перспективе, но лишают себя возможностей для роста и перспективного будущего.
Он советует отказываться от легких денег за проекты, где нужен только опыт, и отдавать приоритет более сложным и менее доходным проектам, где понадобится применить ум. Запросы потребителей - это проекты, требующие только опыта, в то время как задачи для ума - это собственные инициативы компании. Нужно искать все ответы внутри себя.
Первая треть книги далась мне тяжелей всего. Почти на каждой странице и не по одному разу упоминается одна и та же мысль, про танцующих медведей, про то, что существующими программами невозможно пользоваться, и про то, что взаимодействие нельзя доверять программистам. А главное, что проектированием надо заниматься до начала программирования, а не после пытаться причесать интерфейс. Мысли верные и хорошие, но когда их долбят тебе с завидным упрямством, уже на десятой странице от такого начинает подташнивать.
Потом пошло веселей: примеры проектирования взаимодействий, примеры реальных продуктов и компаний, а основные мысли вспоминали чуть реже. В итоге ещё полкниги я прочитала быстро. Правда, по книге чувствуется, что она была написана в конце 1990-х и многие из существовавших тогда проблем на сегодняшний момент решены. Но это дополнительно указывает, что даже очевидное и принятое сейчас (но неудобное) может быть изменено.
Далее следовали указания по управлению и снова стало скучновато. В итоге книгу я уже помучивала и в общей сложности потратила на неё много времени, хотя она оказалась во многом полезна.
Найдя решение главной проблемы, вы делаете главной проблемой следующую по списку
Джерри Вайнберг
Среда web по организации схожа с Советским Союзом, здесь центральные компьютеры указывают беспомощным настольным машинам, что делать.
"Психбольница" — книга-гештальт. Купил ее еще семь лет назад в университете, когда нам преподавали Купера на курсе по человеко-машинному взаимодействию. С тех пор я несколько раз начинал ее и бросал на середине. Для меня Купер — редкостный зануда. Пишет ужасно, постоянно вставляет скучные и не интересные истории. Но на этот раз я собрался с силами, дочитал и не пожалел.
Вкратце, Купер описывает почему продуктами, в создании которых главенствующую роль занимают программисты могут пользоваться только программисты, но не простые смертные. Ну и дает рецепты, как создавать продукты, в которые влюбятся пользователи.
Книгу в первую очередь рекомендую менеджерам, вышедшим из программистов. За чтением будет немного больно, но зато чакры прочистятся на ура.
Мир стремительно меняется, тем более мир IT-технологий, и точно также меняются ожидания пользователей от этих технологий. И сегодня пользователи ждут от программных продуктов не только ожидаемых действий, того самого функционала, но и комфорта в использовании этих продуктов. Более того, оценка пользователем любого ПО прежде всего начинается с именно этого комфорта. Но далеко не любой программный продукт может похвастаться продуманным и действительно удобным уровнем взаимодействия с пользователем. Скорее даже наоборот, действительно удобных продуктов мало, к сожалению, у большинства же приложений, как правило, находятся проблемы.
Проблемы взаимодействия ПО и пользователя встречаются повсеместно, от очень сложных и «навороченных» серверов до маленьких и простых утилит, которыми приходится пользоваться каждый день. Но если раньше все эти неудобства пользователями воспринимались как должное, как неотъемлемый атрибут применения программы/системы/Веб-сайта, то сегодня, когда этих программ/систем/Веб-сайтов стало ощутимо больше, пользователи автоматически сделались более взыскательными. Это — пользователи, но не разработчики! Разработчики по-прежнему мыслят своими категориями, и в погоне за скоростью реализации забывают вовсе о тех, ради кого все это и создается. И примеров тому масса. Буквально вчера мне довелось заполнять регистрационную форму на некотором Веб-узле для получения кода активации купленного ранее программного продукта. В этой форме было всего 5 полей, и я, довольно искушенный пользователь, умудрился сделать в них 4 ошибки, в результате чего мне удалось получить требуемую регистрацию только с какой-то по счету попытки (я даже сбился со счета). Что это? Я не умею читать? Я не в своем уме, чтобы сразу не разобраться в 5 строчках текста? Или же это вопиющие проблемы юзабилити Веб-узла известной компании? Ведь согласитесь, на какой-то очередной ошибке, получив вот такое сообщение от системы «--handle---Resource id #9--- No getting, Продукт не выбран!» хочется всe бросить и просто закрыть браузер, так как совершенно не ясно, что же случилось и что же делать дальше...
После «Психбольницы» особо остро начинаешь видеть подобные недочеты в приложениях, написанным другими, и самое главное, в своих собственных! И, по крайней мере, только одно это уже является замечательным результатом. Поэтому я однозначно рекомендую эту книгу всем разработчикам программных продуктов и Веб-сайтов.
Источник
Алан Купер поднимает вопрос о том, насколько трудно бывает пользоваться программами из-за их недружелюбности и как этого избежать. Он предлагает пересмотреть процесс разработки ПО, которым, в конечном счете, заправляют инженеры — те, кто непосредственно пишет код, и добавить проектирование интерфейса и взаимодествия перед непосредственным созданием архитектуры программы и кодирования. А. Купер вводит понятие «целеориентированное проектирование» — подход к проектированию пользовательского интерфейса, основанный на персонажах и их целях. Это понятие легло в основу всей его работы и конкретной книги «Психбольница в руках пациентов». О ней сегодня и пойдет речь.
Цитат получилось много, может даже слишком перегружено. Но это только подчеркивает насколько емкая и полезная книга. По мере прочтения, я добавлял в цитаты только те высказывания, которые находили отклик во мне и, как вы видите, их получилось более чем достаточно. Книга более чем понравилась, она заставила по иному взглянуть на процесс разработки ПО и собственных продуктов в частности. Хотя мы и проходили в университете этот подход к проектированию интерфейсов, я узнал много нового для себя и все встало в единую картину. Советую к прочтению всем, кто так или иначе связан с разработкой программных систем, ведь именно от вас зависит будет ли пользователь получать удовольствие от пользования вашими программами или почувствует себя глупо, столкнувшись с каким-то очередным «гениальным» решением программиста, и или забросит вашу программу, или будет пользоваться и плеваться от «танцующего медведя».
Подробнее в отзыве на сайте
Целеориентированное проектирование по А.Куперу - Grow & Manage