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