- •Алан Купер Психбольница в руках пациентов
- •Содержание
- •Часть IV. Проектирование взаимодействия - выгодный бизнес 3
- •Глава 9. Проектирование для удовольствия 3
- •Глава 10. Проектирование ради результата 32
- •Глава 11. Проектирование для людей 66
- •Часть V. Возвращаемся на место водителя 93
- •Глава 12. В отчаянных поисках эргономики 93
- •Глава 13. Управляемый процесс 108
- •Глава 14. Мощь и удовольствие 129
- •ЧастьIv. Проектирование взаимодействия - выгодный бизнес Глава 9. Проектирование для удовольствия
- •Персонажи
- •Проектируйте для одного персонажа
- •Чемодан на колесиках и клейкие бумажки
- •Гуттаперчевый пользователь
- •Персонаж должен быть конкретным
- •Персонаж должен быть воображаемым
- •Описание должно быть подробным, а не идеальным
- •Реалистичный взгляд на уровень подготовленности
- •Персонажи закрывают споры о функциях
- •Персонажи нужны проектировщикам и программистам
- •Персонаж пользователя, а не покупателя
- •Подбор персонажей
- •Ключевые персонажи
- •Пример: Sony Trans Соmи p@ssport
- •Традиционное решение
- •Персонажи
- •Проектирование для Клевиса
- •Глава 10. Проектирование ради результата
- •Мы решаем задачи, чтобы достичь целей
- •Задачи не являются целями
- •Программисты занимаются проектированием, ориентированным на задачи
- •Проектирование, ориентированное на цели
- •Целеориентированные телевизионные новости
- •Целеориентированное управление классом
- •Цели личные и цели практические
- •Принцип соразмерности усилий
- •Личные цели
- •Корпоративные цели
- •Практические цели
- •Ложные цели
- •И у компьютера есть человеческие черты
- •Проектирование и вежливость
- •Что такое вежливость?
- •Что делает программы вежливыми?
- •Вежливая программа интересуется мной
- •Вежливая программа относится ко мне уважительно
- •Вежливая программа обходительна
- •Вежливая программа ведет себя разумно
- •Вежливая программа предвидит мои потребности
- •Вежливая программа отзывчива
- •Вежливая программа не склонна делиться своими личными проблемами
- •Вежливая программа в курсе происходящего
- •Вежливая программа проницательна
- •Вежливая программа уверена в себе
- •Вежливая программа всегда сосредоточена
- •Вежливая программа покладиста
- •Вежливая программа дает мгновенное удовлетворение
- •Вежливой программе можно доверять
- •Пример: Drumbeat от Elemental
- •Расследование
- •Кто кому служит
- •Проектирование
- •Прочие моменты
- •Глава 11. Проектирование для людей
- •Сценарии
- •Повседневные сценарии
- •Обязательные сценарии
- •Сценарии исключительных ситуаций
- •Адаптирующийся интерфейс
- •Вечные середняки
- •Представь себе!
- •Словарь
- •Языковой прорыв
- •Реальность смеется последней
- •Пример: Logitech Scanman
- •Малкольм, боец фронта Всемирной паутины
- •Чед Марчетти, мальчик
- •Dpi Магнум
- •Игра «Представь себе!»
- •Высококлассная обрезка
- •Высококлассное изменение размеров
- •Высококлассный поворот изображения
- •Первоклассные результаты
- •Преодоление разрыва между устройствами и программами
- •Меньше значит больше
- •ЧастьV. Возвращаемся на место водителя Глава 12. В отчаянных поисках эргономики
- •Последовательность
- •Юзабилити-тестирование
- •Юзабилити-тестирование до программирования
- •Интеграция юзабилити-тестирования в процесс проектирования
- •Многопрофильные команды
- •Проектирующие программисты
- •Откуда вы знаете?
- •Руководства по стилю
- •Конфликт интересов
- •Фокус-группы
- •Визуальное проектирование
- •Промышленный дизайн
- •Классная новая технология
- •Итерации
- •Глава 13. Управляемый процесс
- •Кто на самом деле самый влиятельный?
- •Смертельная спираль: на поводу у клиента
- •Концептуальная целостность - важное достоинство
- •Фаустова сделка
- •Прогнозирование
- •Принятие ответственности
- •Затраты времени
- •Удержание управления
- •Поиск основы
- •Семь раз отмерь
- •Производство фильмов
- •Хорошая сделка
- •Документируйте замысел, чтобы дать ему жизнь
- •Проектирование влияет на код
- •Проектировочные документы приносят пользу программистам
- •Проектировочные документы идут на пользу маркетингу
- •Проектировочные документы помогают в разработке документации и технической поддержке
- •Проектировочные документы помогают руководителям
- •Проектировочные документы выгодны компании в целом
- •Кто отвечает за качество продукта?
- •Включение проектирования в процесс
- •Откуда берутся проектировщики взаимодействия
- •Создание команд проектировщиков
- •Глава 14. Мощь и удовольствие
- •Пример налаженного проекта
- •Осознанное проектирование взаимодействия
- •Польза от перемен
- •Почему они не едят пирожных?
- •Изменить процесс
Польза от перемен
В мире программного обеспечения так много апологетов, а их влияние настолько велико, что власть этой касты ослабевает очень медленно. Но эта власть ослабнет обязательно. Для этого достаточно, чтобы люди поняли: технологии не обязательно должны быть бесчеловечными. Чем чаще пользователи будет сталкиваться с программами, не унижающими их человеческое достоинство, тем быстрее они будут терять терпение, встречаясь с иными программами, которые оскорбляют и раздражают их. Они пинками погонят танцующих медведей прочь.
Когда пользователей таких продуктов было немного, все они были и непосредственными участниками процесс а, а потому понимали, насколько революционна эта технология. По мере проникновения технологии во все сферы жизни все меньше причастившихся осознают, насколько это достижение велико. Они не готовы простить продукту некачественное взаимодействие только потому, что создание этого продукта отняло много сил.
Следование за технологией кажется идеей неплохой, однако результатом обычно становятся утомляющие продукты, более сложные наследники тех, что уже были созданы. Проектирование взаимодействия позволяет вырваться из этого круга и создавать продукты, которые делают то, что никогда раньше не делалось.
Проектирование взаимодействия делает продукт привлекательным, награждая уникальным рыночным преимуществом - преданностью покупателей. Если покупателя осчастливил ваш продукт, этот человек надолго останется клиентом вашей компании и вашего брэнда. Если же ваш продукт - очередной танцующий медведь, клиенты будут оглядываться в поисках более простых и дружелюбных альтернатив.
Проектирование взаимодействия может сократить затраты времени на разработку продукта. Если вы заранее знаете, что именно следует создавать, то потратите меньше времени на поиски верного пути.
Создание правильного продукта - всегда итеративный процесс. Чтобы добиться точности в деталях, требуется несколько попыток. Проектирование взаимодействия позволяет значительно уменьшить количество итераций. Выпуск каждой новой версии продукта сопряжен с огромными затратами, поэтому, уменьшая количество версий с четырех до двух, вы экономите массу денег и времени.
Процесс разработки удешевляется, если версий становится меньше и код выбрасывается не в таких количествах. Программисты часто жалуются, что наши проекты требуют создания более сложного кода, и зачастую они правы. Однако в целом размер кода получается обычно меньшим. Стоимость кода не сильно растет с увеличением сложности, однако значительно растет с увеличением объема. Каждую лишнюю строку кода необходимо тестировать, отлаживать и поддерживать.
Почему они не едят пирожных?
Я живу и работаю в Кремниевой Долине, штат Калифорния. Практически все знакомые мне люди вовлечены в индустрию высоких технологий. Мы все обеспечены, образованны, географически и социально мобильны, замечательно управляемся с компьютерами, сотовыми телефонами, видеомагнитофонами, банкоматами и всеми прочими представителями зверинца продуктов, основанных на программном обеспечении. Когда я обедаю в Crescent Park Grill или Spago, посетители за соседними столиками все время обсуждают клиент-серверные архитектуры и веб-интерфейсы. Восхитительное место для жизни, но оно не дает представления о большинстве жителей этой страны, не говоря уже обо всей планете. Здесь в Долине наши оценки качества высокотехнологических продуктов могут искажаться легко и радикально. Мы забываем, насколько сложно в действительности применять эти продукты.
Десять лет назад консультант по розничным продажам Сеймур Меррин (Seymour Merrin) сказал, что нам проще было убедить покупателей, что программами легко пользоваться, чем сделать так, чтобы программами было легко пользоваться. Высказывание Меррина было циничным, однако он также выражал удивление, что нам сошла с рук столь наглая ложь. Сегодня его слова все еще справедливы, но рост высоких технологий не оставляет возможности и дальше выезжать на одном цинизме - нам требуется настоящее решение.
Люди знают, что компьютерами очень трудно пользоваться, однако предполагают, что тому есть причины. Большинство считает, что лучше уже и быть не может.
Простые пользователи, не вовлеченные в индустрию компьютеров, приходят в крайнее раздражение из-за сложных в применении продуктов, тогда как люди, занятые созданием продуктов, в массе своей удовлетворены состоянием дел. Программистам не кажется, что компьютерами сложно пользоваться, поэтому они готовы терпеть некоторые вещи, пока есть возможность поиграть в технологические игры, создавая новых классных танцующих медведей.
Что до остальных из нас, мы получаем программы, соответствующие требованиям, а требовали мы до сих пор очень немного. Разработчики программ засыпают нас штучками, примочками, возможностями, которые нам не нужны, которые мы никогда не применяем, но вынуждены оплачивать. Мы требуем, чтобы программы не сбоили, поэтому программы подвергаются исчерпывающему тестированию и, как следствие, обладают разумной надежностью. Мы требуем новых версий немедленно, и компании выпускают версии с безумной скоростью. Но, не задумываясь о том, что жизнь может стать лучше, мы не требуем, чтобы продукты стали мощными и приятными, поэтому продукты и остаются слабыми, угнетающими.
Время от времени у потребителей появляются призрачные надежды, что следующая волна технологии, скажем, распознавание голоса, сделает программные продукты простыми в применении. Надеяться на это наивно и неумно. Мне грустно видеть, как апологеты грубо подыгрывают таким надеждам.
Программное обеспечение уместно сравнить с пластилином - оно может принимать любую форму, какая будет угодна авторам. Они не создают простые в применении программы не потому, что это невозможно, а потому, что не умеют. Чтобы не признавать этот неудобный факт, они заявляют, что лучше сделать просто невозможно «по техническим причинам». Пользователи компьютеров, программистами не являющиеся, вынуждены соглашаться со специалистами и страдать, или же не соглашаться со специалистами и - вот именно - все равно страдать. Не будучи специалистами, они не способны предлагать собственные решения, поэтому к ним относятся как к бесполезным нытикам.
Штат Детройт производил гигантские хромированные прожорливые автомобили и лицемерно утверждал: «Мы даем потребителям то, что им нужно». Во время нефтяного кризиса семидесятых японцы вышли на рынок с экономичными небольшими автомобилями и нанесли Детройту удар, который не забудется никогда. Сегодня автомобильная индустрия Америки проявляет гораздо большее уважение к желаниям потребителя и уже не осмеливается утверждать, что все знает лучше.
Япония захватила позиции на автомобильном рынке, выполнив желания пользователей, о которых те и не подозревали. При этом потребители способны отличить хорошую вещь от плохой, если им дадут ее увидеть. Точно так же высоты в проектировании программного взаимодействия сегодня остаются свободными, они не захвачены никем. Мiсrоsоft уязвима не меньше, чем General Motors в 1974 году.
Массовый рынок потребителей, не знакомых с технологическими тонкостями, охотно принимает простые в применении продукты, что и подтверждает взрывной рост среды Web. Люди, привлеченные простотой ее использования, точно так же оценят качественно спроектированные продукты, делающие сложные вещи простыми для пользователей.
Потребители, не знакомые с тонкостями технологии и не принадлежащие к анклавам вроде Кремниевой Долины, не будут требовать изменений просто потому, что не могут образовать сплоченную группу. Разумеется, хорошее от плохого они отличают, но только после того, как хорошее и плохое появляется на полках магазинов.
Изменения произойдут только тогда, когда люди, принимающие участие в процессе и способные повлиять на ранние стадии развития продуктов, заинтересуются решением этой проблемы. Программисты вовлечены в конфликт интересов, а потому мой призыв адресован апологетам в самом сердце этой индустрии высоких технологий. Современные бизнесмены вовлечены в жизнь этой индустрии, хотят они того или нет. Вряд ли еще остались в мире предприятия, не вставшие на путь внедрения информационных технологий.
Ни один из современных нам продуктов, основанных на программном обеспечении, не способен дать мощь и удовольствие от применения людям, не входящим в число одержимых технологией. Инженерное же сообщество просто сообщает, что пользователям придется получить «компьютерное образование». Полагаю, в историю эта фраза войдет наравне со знаменитым и снисходительным. «Почему они не едят пирожных?» Марии-Антуанетты. Французская революция дала народу хлеб, а грядущая революция проектирования даст народу технологию.