- •Алан Купер Психбольница в руках пациентов
- •Содержание
- •Часть 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. Мощь и удовольствие
- •Пример налаженного проекта
- •Осознанное проектирование взаимодействия
- •Польза от перемен
- •Почему они не едят пирожных?
- •Изменить процесс
Осознанное проектирование взаимодействия
В большинстве компаний проектирование основного продукта или услуги считается важнейшим умением. В мире высокотехнологических продуктов, основанных на программном обеспечении, считается (и ошибочно), что проектирование продукта находится в компетенции инженерного персонала. В действительности акт творения состоит из двух частей: проектирования и программирования. Готовность разрешить проектировщикам взаимодействия работать с важнейшим элементом бизнеса наряду с инженерами требует значительных культурных перемен.
В любой компании, независимо от ее специализации, сотрудники знают, что имеют определенные обязанности. Так, в компании, производящей катушки для динамиков, руководитель производства знает, что хотя его задача заключается в покупке лучшего сырья по наинизшей цене, он не сможет подписать контракт с поставщиком, пока не получит одобрение совета компании. Руководитель производства не очень разбирается в юридических вопросах контрактного дела, однако знает, что не стоит создавать трудности своей компании, пренебрегая советом профессионалов в области контрактов и сделок. Даже не разбираясь в контрактном деле, точнее, как раз поэтому, руководитель знает, что необходимо привлечь юриста.
Приемщик в грузовом доке, обладая самым низким рангом, знает, что уполномочен расписываться лишь за грузы, доставка которых уже оговорена, но не уполномочен расписываться за иные.
Основатель и президент компании, выпускающей катушки, также вполне осознает необходимость участия юристов на всех уровнях. Он не имеет профильного юридического образования, а потому советуется с помощником, прежде чем подписывать какие-либо документы.
Ни один из этих людей не обладает специальными знаниями в области юриспруденции, но каждый полностью осознает важность участия юриста. Никто в Компании ничего не подпишет, пока юристы не подтвердят, что это можно сделать. Сама по себе компания осознает необходимость в таком присмотре и даже, временами, вмешательстве.
Такое осознание, распространяющееся на всю компанию, верно и для других областей.
Когда катушечной компании потребовалось новое производственное здание, она наняла стороннего профессионала, архитектора. Руководитель производства и президент хорошо разбираются в особенностях производственных мощностей, однако знают, что их понимание нюансов конвейерной работы и строительства зданий поверхностно. Никому в этой компании и в голову не придет расширять производство, не посоветовавшись сначала с архитектором. Архитектор переводит потребности пользователей в термины, понятные строителям.
То же верно и для рекламы. Руководитель отдела маркетинга не будет просить рабочего описать выгоды продукта для брошюры или для профильного отраслевого журнала. Каждый в компании, независимо от опыта, понимает, что реклама - дело профессионалов, и что специалисты по рекламе могут обеспечить компании отличный пиар. Разумеется, эти специалисты могут быть сотрудниками компании, как могут быть и наняты в рекламном агентстве. Оба варианта хороши.
Приведенная аналогия не идеальна. Ни архитектура, ни юридическая консультация для производственной компании не лежат в сфере основного занятия. Однако программирование - это создание продукта, а именно создание продукта, как правило, и считается занятием компании. Учитывая непосредственное влияние продукта на бизнес, можно ожидать, что любая компания будет вдвойне осторожна, чтобы бразды правления не попали в плохие руки, - еще более осторожна, чем в случае с рекламой, архитектурой или приобретением чего-либо.
Мы должны сделать так, чтобы в компании поняли: проектирование взаимодействия представляет собой область, требующую профессиональных навыков, и что интерактивные продукты нельзя просто конструировать инженерными способами, их следует еще и проектировать, чтобы добиться успеха на открытом рынке.