Алан Купер. Психбольница в руках пациентов. Очень “долгая” книга, многословная, в первой половине очень уныло обрисовывается state of art в проектировании взаимодействия на момент написания книги, во второй половине рассказывается как должно быть. На шестиста страницах автор пытается донести нехитрую мысль, что программирование взаимодействия нужно забрать у программистов. Они всё равно делать этого не хотят и не умеют (в силу профессиональной деформации), отчего получается только хуже. Тем не менее несколько интересных вещей я вынес (чуть было не дропнул на трети пути), отдельного внимания заслуживают примеры, идущие после каждого раздела. Итог 3 из 5, тем не менее, стоит прочитать всем, кто связан с проектированием интерфейсов.
Автор начинает с примеров неправильного взаимодействия, порой приводящих к печальным последствиям (авиакатастрофа над Кали). Иногда пользователи из-за когнитивного сопротивления устраивают бойкот и саботаж новых информационных систем. И если пользователи пользуются сложной программой - это, скорее всего, означает, что на рынке просто отсутствует аналог с меньшим сопротивлением. Таки программы называются “Танцующий медведь” - Танцует медведь просто ужасно, но чудо не в том, что он танцует хорошо, а в том, что вообще танцует.
Высокое сопротивленеи раскалывает людей на два лагеря: уцелевших и апологетов. Первые страдают и впадают в отчаяние, вторые - чувствуют эйфорию от предоления серьезных препятствий.
Весь второй раздел посвящен борьбе программистов со всей остальной компанией: менеджерами, тестировщиками, проектировщиками взаимодействия. Всё написанное там ничуть не изменилось за десять лет, прошедших с написания этой книги. Даже “давайте вы начнете программировать, а мы пока будем проектировать”.
Автор выделил ключевые особенности психологии программистов, которые приводят к проблемам со взаимодействием:
1. Жертва простотой ради контроля
2. Успех менее важен понимания
3. Программисты сосредотачиваются на исключительных (их ряд чисел состоит из 0, 1, бесконечность)
4. Программисты ведут себя грубо и прямолинейно
При проектировании взаимодействия, важнейший этап - выделить персонажей. Причем не абстрактных, а обладающих фотографией, именем, предысторией, мотивацией и определенными целями. Чем более точным будет архетип, тем более качественным получится взаимодействие. На каждую программу может приходиться 3-5 ключевых персонажей. В идеале, у каждого должен быть свой интерфейс. Такие персонажи закроют споры по функционалу, поскольку сразу будет видно, кто и в какой ситуации будет этим пользоваться. Персонаж должен описывать пользователя а не покупателя, хотя маркетинг может сопротивляться.
Проектирование должно быть ориентировано на цели, а не задачи. Задачи меняются вместе с технологией, тогда как цели обладают приятной особенностью – они очень стабильны. Например, в путешествии из Сент-Луиса в Сан-Франциско мои цели – скорость, удобство, безопасность. Направляясь в Калифорнию на золотые прииски где-нибудь в 1850 году, я путешествовал бы в своем новом, высокотехнологичном фургоне Конестога. В интересах безопасности я взял бы с собой ружье «винчестер». Направляясь из Сент-Луиса в Caн-Франциско в 1999 году, я путешествую в новом, высокотехнологичном Боинге-777. В интересах безопасности «винчестер» имеет смысл оставить дома. Мои цели остались неизменными, однако задачи изменились вместе с технологиями настолько, что стали прямо противоположными.
Цели могут быть личными и практическими. Сущность качественного проектирования взаимодействия состоит в том, чтобы позволить пользователям достигать практических целей, не отказываясь от целей личных. При этом отсутствие препятствий в достижении личных целей важнее мгновенного достижения всех практических целей. Это достигается через соразмерность усилий: пользователь готов приложить дополнительные усилия, потому что ожидает получить за эти усилия дополнительное вознаграждение.
Примеры личных целей:
1. Не чувствовать себя глупо
2. Не совершать ошибок
3. Выполнить адекватный объем работы
4. Развлечься (или хотя бы не страдать от скуки)
Примеры корпоративных целей
1. Увеличить прибыль
2. Увеличить рыночную долю
3. Победить конкурентов
4. Нанять больше сотрудников
5. Предложить новые продукты и услуги
6. Выпустить акции компании в свободное обращение
Примеры практических целей:
1. Избегать собраний
2. Удовлетворять требованиям клиента
3. Сохранять информацию о заказах клиента
4. Создавать математические модели бизнеса
Ложные цели:
1. Экономия памяти
2. Уменьшение потребности в клавиатурном вводе
3. Поддержка работы в броузере
4. Простота в освоении
5. Обеспечение целостности данных
6. Ускорение ввода данных
7. Увеличение скорости исполнения программы
8. Применение супертехнологии или супервозможностей
9. Улучшение внешнего вида
10. Сохранение единообразия интерфейса на различных платформах
Компьютер на подсознательном уровне воспринимается как разумное существо, хотя и осознанно человек может это отрицать. Иначе говоря, у людей есть особые инстинкты, подсказывающие, как надо вести себя рядом с другими разумными существами, и как только произвольный объект демонстрирует достаточно серьезное когнитивное сопротивление, эти инстинкты включаются, и мы реагируем так, будто имеем дело с другим разумным человеческим существом. Эта реакция бессознательна и неизбежна, она присуща каждому человеку.
Именно поэтому интерфейс должен быть вежливым:
Вежливая программа интересуется мной
Вежливая программа относится ко мне уважительно
Вежливая программа обходительна
Вежливая программа ведет себя разумно
Вежливая программа предвидит мои потребности
Вежливая программа отзывчива
Вежливая программа не склонна делиться своими личными проблемами
Вежливая программа в курсе происходящего
Вежливая программа проницательна
Вежливая программа уверена в себе
Вежливая программа всегда сосредоточенна
Вежливая программа покладиста
Вежливая программа дает мгновенное удовлетворение
Вежливой программе можно доверять
Помимо персонажей, проектирование взаимодействия включает в себя сценарии. Сценарий – это сжатое описание способов применения программного продукта персонажем для достижения цели. Сценарии делятся на повседневные (самые полезные и важные), обязательные (выполняемые нечасто, но неукоснительно), исключительные ситуации. Программисы обращают свое внимание именно на них, хотя их можно упрятать в глубины интерфейса. Работоспособность кода может зависеть от того, обрабатываются ли исключительные ситуации, а успех продукта зависит от способности справляться со случаями, описанными в сценариях повседневных и обязательных.
Парадокс середняков: маркетологи проектируют для новичков, программисты для экспертов. Хотя эти группы находятся по разные стороны Колокола Гаусса. Новички быстро осваивают функционал и становятся середняками, либо отказываются от программы. Экспертами становятся единицы. Большинство так и сотается середняками, при этом для них никто не проектирует.
В заключании автор говорит о ловушке клиента, который начинает диктовать, какие функции должны быть в программе. Продукты, создающиеся под дудку клиентов, не обладают ясным замыслом. Такие продукты не имеют качества, которое идеолог программного обеспечения Фредерик Брукс называет «концептуальной целостностью, всепроникающим видением программы», которое, по его мнению, и есть главный ингредиент успеха. В отсутствие концептуальной целостности могут случиться две вещи: клиенты начинают контролировать проектирование вашего продукта, а вы перестаете это делать. Неважно, насколько у клиента благие намерения, он не обладает способностью воспринимать ваш продукт, как единую концептуально целостную сущность. Четкое видение ситуации – это одно из главных достоинств, и большинство компаний с трудом могут сфокусироваться на собственном бизнесе, что уж говорить о вашем. Даже выкрикивая противоречивые приказы, клиенты ожидают, что вы самостоятельно выберете правильные.
