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