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