Психбольница в руках пациентов
Добавить в закладки К обложке
- Отзывы на книгу Алана Купера - Страница 1
- Об авторе - Страница 3
- Благодарности - Страница 4
- Предисловие научного редактора - Страница 6
- Предисловие - Страница 8
- Введение - Страница 9
- Инженер, сведущий в бизнесе, либо бизнесмен, сведущий в технологии - Страница 10
- Часть IКомпьютерная безграмотность - Страница 18
- Что получится, если скрестить компьютер с фотокамерой? - Страница 19
- Что получится, если скрестить компьютер с будильником? - Страница 20
- Что получится, если скрестить компьютер с автомобилем? - Страница 21
- Что получится, если скрестить компьютер с банком? - Страница 22
- Компьютер позволяет легко попасть в беду - Страница 23
- Коммерческое программное обеспечение тоже страдает - Страница 25
- Что получится, если скрестить компьютер с военным кораблем? - Страница 26
- Техноярость - Страница 27
- Индустрия в «несознанке» - Страница 28
- Мотивы создания этой книги - Страница 29
- Глава 2Когнитивное сопротивление - Страница 31
- Поведение, не связанное с физическими силами - Страница 32
- Проектирование6 – слово емкое - Страница 33
- Отношения между программистами и проектировщиками - Страница 34
- Большинство программ проектируются случайным образом - Страница 35
- Проектирование «взаимодействия» против проектирования «интерфейса» - Страница 36
- Отличительные черты продуктов, основанных на программном обеспечении - Страница 37
- Танцующий медведь - Страница 39
- Стоимость дополнительных возможностей программного обеспечения - Страница 40
- Апологеты и уцелевшие - Страница 42
- Наша реакция на когнитивное сопротивление - Страница 44
- Демократизация власти потребителя - Страница 45
- Виноват пользователь - Страница 46
- Программный апартеид - Страница 47
- Часть IIМасштабные издержки - Страница 49
- Управление, ориентированное на крайние сроки сдачи - Страница 50
- Что такое «готово»? - Страница 51
- Закон Паркинсона - Страница 52
- Продукт, вечно не готовый к выпуску - Страница 53
- Поздний выпуск – не беда - Страница 54
- Торг за набор функций - Страница 55
- Кто главный? Программисты - Страница 56
- Возможности не всегда нужны - Страница 57
- Итерации и миф о непредсказуемости рынка - Страница 58
- Скрытые издержки некачественного программного обеспечения - Страница 60
- Дороже разработки ПО обходится только разработка плохого ПО - Страница 61
- Стоимость возможностей - Страница 62
- Издержки прототипирования - Страница 63
- Глава 4Танцующий медведь - Страница 66
- Если это проблема, то почему ее до сих пор не решили? - Страница 67
- Жертва бытовой электроники - Страница 68
- Чем плохи почтовые клиенты - Страница 69
- Чем плохи программы для планирования - Страница 70
- Чем плохи календари - Страница 71
- Массовая веб-истерия - Страница 72
- Что не так с программным обеспечением? - Страница 73
- Программы забывают - Страница 74
- Программы ленивы - Страница 75
- Программы скупы на информацию - Страница 76
- Программы не гибки - Страница 77
- Программы возлагают вину на пользователей - Страница 78
- Программы не несут ответственности - Страница 79
- Глава 5Нелояльность клиентов - Страница 80
- Привлекательность - Страница 81
- Одно сравнение - Страница 83
- Время выхода на рынок - Страница 85
- Часть IIIКак есть суп вилкой - Страница 86
- Вождение на заднем сиденье - Страница 87
- Подготовка катастрофы - Страница 89
- Компьютеры против людей - Страница 92
- Учим собак быть кошками - Страница 93
- Глава 7Ноmo Logicus - Страница 96
- Авиационный тест - Страница 97
- Психология программистов - Страница 98
- Программисты пожертвуют простотой ради контроля - Страница 99
- Программисты обменяют успех на понимание - Страница 100
- Программисты сосредотачиваются на исключительных ситуациях - Страница 101
- Программисты ведут себя грубо и прямолинейно - Страница 103
- Глава 8Отмирающая культура - Страница 105
- Культура программирования - Страница 106
- Повторное использование кода - Страница 107
- Общепринятая культура - Страница 109
- Культура программирования в Мicrоsоft - Страница 110
- Культурная изоляция - Страница 113
- Шкурный интерес - Страница 114
- Дефицитный образ мыслей - Страница 116
- Обесчеловечивает процесс, а не технология - Страница 117
- Часть IVПроектирование взаимодействия – выгодный бизнес - Страница 118
- Персонажи - Страница 119
- Проектируйте для одного персонажа - Страница 120
- Чемодан на колесиках и клейкие бумажки - Страница 121
- Гуттаперчевый пользователь - Страница 122
- Персонаж должен быть конкретным - Страница 123
- Персонаж должен быть воображаемым - Страница 124
- Описание должно быть подробным, а не идеальным - Страница 125
- Реалистичный взгляд на уровень подготовленности - Страница 126
- Персонажи закрывают споры о функциях - Страница 127
- Персонажи нужны проектировщикам и программистам - Страница 128
- Персонаж пользователя, а не покупателя - Страница 129
- Подбор персонажей - Страница 130
- Ключевые персонажи - Страница 131
- Пример: Sony Trans Соm и P@ssport - Страница 132
- Традиционное решение - Страница 133
- Персонажи - Страница 134
- Проектирование для Клевиса - Страница 136
- Глава 10Проектирование ради результата - Страница 138
- Мы решаем задачи, чтобы достичь целей - Страница 139
- Задачи не являются целями - Страница 140
- Программисты занимаются проектированием, ориентированным на задачи - Страница 141
- Проектирование, ориентированное на цели - Страница 142
- Целеориентированные телевизионные новости - Страница 143
- Целеориентированное управление классом - Страница 144
- Цели личные и цели практические - Страница 145
- Принцип соразмерности усилий - Страница 146
- Личные цели - Страница 147
- Корпоративные цели - Страница 148
- Практические цели - Страница 149
- Ложные цели - Страница 150
- И у компьютера есть человеческие черты - Страница 151
- Проектирование и вежливость - Страница 152
- Что такое вежливость? - Страница 153
- Что делает программы вежливыми? - Страница 154
- Вежливая программа интересуется мной - Страница 155
- Вежливая программа относится ко мне уважительно - Страница 156
- Вежливая программа обходительна - Страница 157
- Вежливая программа ведет себя разумно - Страница 158
- Вежливая программа предвидит мои потребности - Страница 159
- Вежливая программа отзывчива - Страница 160
- Вежливая программа не склонна делиться своими личными проблемами - Страница 161
- Вежливая программа в курсе происходящего - Страница 162
- Вежливая программа проницательна - Страница 163
- Вежливая программа уверена в себе - Страница 164
- Вежливая программа всегда сосредоточена - Страница 165
- Вежливая программа покладиста - Страница 166
- Вежливая программа дает мгновенное удовлетворение - Страница 168
- Вежливой программе можно доверять - Страница 169
- Пример: Drumbeat от Elemental - Страница 170
- Расследование - Страница 171
- Кто кому служит - Страница 172
- Проектирование - Страница 173
- Откат - Страница 174
- Прочие моменты - Страница 175
- Глава 11Проектирование для людей - Страница 176
- Сценарии - Страница 177
- Повседневные сценарии - Страница 178
- Обязательные сценарии - Страница 179
- Сценарии исключительных ситуаций - Страница 180
- Адаптирующийся интерфейс - Страница 181
- Вечные середняки - Страница 182
- Представь себе! - Страница 184
- Словарь - Страница 185
- Языковой прорыв - Страница 186
- Реальность смеется последней - Страница 187
- Пример: Logitech Scanman - Страница 188
- Малкольм, боец фронта Всемирной паутины - Страница 189
- Чед Марчетти, мальчик - Страница 190
- DPI Магнум - Страница 191
- Игра «Представь себе!» - Страница 192
- Высококлассная обрезка - Страница 193
- Высококлассное изменение размеров - Страница 194
- Высококлассный поворот изображения - Страница 195
- Первоклассные результаты - Страница 196
- Преодоление разрыва между устройствами и программами - Страница 197
- Меньше значит больше - Страница 198
- Часть VВозвращаемся на место водителя - Страница 200
- Последовательность - Страница 201
- Юзабилити-тестирование - Страница 202
- Юзабилити-тестирование до программирования - Страница 203
- Интеграция юзабилити-тестирования в процесс проектирования - Страница 204
- Многопрофильные команды - Страница 205
- Проектирующие программисты - Страница 206
- Откуда вы знаете? - Страница 207
- Руководства по стилю - Страница 208
- Конфликт интересов - Страница 209
- Фокус-группы - Страница 210
- Визуальное проектирование - Страница 211
- Промышленный дизайн - Страница 212
- Классная новая технология - Страница 213
- Итерации - Страница 214
- Глава 13Управляемый процесс - Страница 215
- Кто на самом деле самый влиятельный? - Страница 216
- Смертельная спираль: на поводу у клиента - Страница 217
- Концептуальная целостность – важное достоинство - Страница 218
- Фаустова сделка - Страница 219
- Прогнозирование - Страница 220
- Принятие ответственности - Страница 221
- Затраты времени - Страница 222
- Удержание управления - Страница 223
- Поиск основы - Страница 224
- Семь раз отмерь - Страница 225
- Производство фильмов - Страница 226
- Хорошая сделка - Страница 228
- Документируйте замысел, чтобы дать ему жизнь - Страница 229
- Проектирование влияет на код - Страница 230
- Проектировочные документы приносят пользу программистам - Страница 231
- Проектировочные документы идут на пользу маркетингу - Страница 232
- Проектировочные документы помогают в разработке документации и технической поддержке - Страница 233
- Проектировочные документы помогают руководителям - Страница 234
- Проектировочные документы выгодны компании в целом - Страница 235
- Кто отвечает за качество продукта? - Страница 236
- Включение проектирования в процесс - Страница 237
- Откуда берутся проектировщики взаимодействия - Страница 238
- Создание команд проектировщиков - Страница 239
- Глава 14Мощь и удовольствие - Страница 240
- Пример налаженного проекта - Страница 241
- Осознанное проектирование взаимодействия - Страница 243
- Польза от перемен - Страница 244
- Почему они не едят пирожных? - Страница 245
- Изменить процесс - Страница 247
Цели личные и цели практические
Выше я утверждал, что сущность качественного проектирования взаимодействия состоит в том, чтобы позволить пользователям достигать практических целей, не отказываясь от целей личных. Хомо логикус и апологеты обычно находят излишним чересчур пристальное внимание к личным целям и стараются этого избегать. Однако различие между двумя видами целей – критическая составляющая успеха.
Для примера возьмем моего коллегу Теда. Он только что прислал мне по электронной почте сообщение, в котором жалуется на свой новый телевизор. Много неприятных часов он провел за чтением руководства, потому что иначе не мог настроить многочисленные режимы ящика. Он предположил, что в телевизоре должен быть экранный диалог, сопровождающий пользователя на каждом шаге настройки и который позволил бы обойтись без чтения руководства. Его решение лучше чтения руководства, но, не будучи проектировщиком, Тед, естественно, подошел к проблеме устаревшим, механическим, образом: сосредоточился на задачах. Экранные диалоги упростили бы задачу настройки режимов, но давайте подойдем к проблеме иначе. Мы взглянем на цели Теда, и это даст нам возможность создать решение, качественно превосходящее то, которое предложил он.
Начнем с оценки целей Теда. Здесь всегда предпочтительно начинать с главного. Очевидно, нам известно, что Тед желает смотреть телевизор. Он только что заплатил уйму денег за новый ящик, поэтому так же очевидно, что он желает воспользоваться преимуществами новых супервозможностей этого телевизора. Эти практические цели непосредственно связаны с задачей настройки нового телевизора.
Но мы не должны ни на секунду забывать, что Тед – человек, а значит, обладает выраженными личными предпочтениями, которые можно назвать целями. Тед не хочет, чтобы новая вещь его унижала, он не хочет, чтобы из него делали идиота. Тед не хочет совершать ошибки. Ему нужно чувство достигнутого результата, и чем скорее, тем лучше. Он хочет развлечься. Эти личные цели жизненно важны. С точки зрения проектировщика взаимодействия они важнее, чем практические цели Теда.
Тед жаловался не на то, что не может смотреть новый телевизор, и не на то, что слишком много заплатил, и не на то, что не может воспользоваться новыми супервозможностями. Он жаловался на то, что телевизор заставил его чувствовать себя глупо. Конечно, Тед выразился иначе, ведь сама фраза «ящик делает из меня идиота» заставляет человека чувствовать себя глупо, но очевидно, что смысл письма был именно такой. Взаимодействуя с телевизором, он случайно делал ошибки. После подключения телевизора у него ушел час, чтобы получить хоть сколько-нибудь удовлетворительный результат. Процесс настройки режимов вряд ли можно назвать развлекательным.
Взаимодействие, присущее продукту, соответствовало практическим целям Теда, но шло вразрез с его наиболее важными личными целями. Особые качества, сделавшие новый телевизор Теда классическим примером высокотехнологичного танцующего медведя, заключены не в способе достижения практических целей владельца, но в том, как продукт не смог удовлетворить его личные цели.
Как бы мы спроектировали новый интерфейс для телевизора, вооруженные информацией о святости личных целей Теда? Во-первых, чтобы владелец быстро почувствовал, что он чего-то достиг, мы должны гарантировать, что телевизор будет хорошо работать сразу после включения. Не нужно, чтобы работали сразу все возможности, но какие-то должны работать, причем хорошо. Очевидно, этот первый тест на удовольствие невозможно пройти при помощи процесса настройки режимов. Разработчики программного обеспечения относятся ко всем режимам одинаково, а потому валят их в одну кучу. Однако мы можем с легкостью предположить, какими должны быть первичные настройки, что позволит телевизору выполнять базовые функции, а пользователю даст отсрочку в знакомстве с прочими, более сложными возможностями продукта. Необходимо вытаскивать параметры из кучи. Это не техническая задача, а простая перестановка приоритетов в проектировании.
Наш проект телевизора подпадает под определение успешного: Тед может вынуть телевизор из коробки, воткнуть его в розетку и сразу же довольно расслабиться в своем кресле, переключая каналы. Большинство практических целей достигнуто, а личным целям при этом ничто не вредит.
Обратите внимание, что отсутствие препятствий в достижении личных целей важнее мгновенного достижения всех практических целей. Это различие также иллюстрирует дополнительные идеи проектирования взаимодействия и обеспечения функциями. Решение должно обеспечить Теду способы достижения всех его практических целей, но проектирование взаимодействия должно четко показать ему, как он может выполнить свои личные задачи.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
- 181
- 182
- 183
- 184
- 185
- 186
- 187
- 188
- 189
- 190
- 191
- 192
- 193
- 194
- 195
- 196
- 197
- 198
- 199
- 200
- 201
- 202
- 203
- 204
- 205
- 206
- 207
- 208
- 209
- 210
- 211
- 212
- 213
- 214
- 215
- 216
- 217
- 218
- 219
- 220
- 221
- 222
- 223
- 224
- 225
- 226
- 227
- 228
- 229
- 230
- 231
- 232
- 233
- 234
- 235
- 236
- 237
- 238
- 239
- 240
- 241
- 242
- 243
- 244
- 245
- 246
- 247
- 248