За некоторыми исключениями, процессоры компьютеров проводят подавляющее большинство времени в бездействии. Да, некоторые процессы требуют интенсивных вычислений, но проистекают совсем не так часто, как нас убеждают создатели аппаратного обеспечения, желающие продавать нам самые новые, и самые замечательные, и самые мощные чудеса электроники. Вряд ли в их интересах, чтобы потребитель знал, что его процессор сильно нагружен лишь на очень коротких дистанциях, а 75-80% времени просто бездействует.
Всего два или три десятилетия тому назад компьютеры были настолько слабыми и настолько дорогими, что любая хорошая идея неминуемо наталкивалась на недостаточную мощность головной машины. Главным вектором развития информатики в те времена стала разработка технологий, снижающих нагрузку на дефицитные вычислительные ресурсы. Такие широко распространенные технологии, как реляционные базы данных, коды АSСII, файловые системы, язык BASIC создавались в основном для того, чтобы снизить нагрузку на компьютер. Программы, написанные в те времена, отдавали приоритет производительности в ущерб другим соображениям, таким как простота применения. Однако уже написанный код неистребим, как сама природа, и многие строки этого старого кода, написанного для старых компьютеров, сегодня работают на современных, невероятно мощных системах.
Обесчеловечивает процесс, а не технология
После выхода в свет фильма Чарли Чаплина «Новые времена» (Modern Times) распространилось мнение, что технология нас обесчеловечивает. Не согласен с таким мнением. Еще до появления технологий тираны, варвары, воины обесчеловечивали своих жертв при помощи кулака и камня. Чтобы сделать человека жестоким, не нужны утонченные инструменты, достаточно взгляда или пинка. Нас делает жестокими не технология. Обесчеловечивают технологи, а точнее говоря – процессы, применяемые технологами для создания обесчеловечивающих продуктов.
Разумеется, чем большим потенциалом обладает технология, тем больший ущерб способны нанести неправильные процессы. И напротив, та же технология при правильном проектировании может стать великим даром человечеству. Высокая технология может пойти в любом направлении, окончательное же воздействие определяют люди, ею управляющие.
Интерактивные системы могут и не быть обесчеловечивающими, но чтобы они не были такими, мы должны перекроить методологию разработки, сделав центром внимания людей, применяющих эти системы. И самое важное изменение для этого процесса – необходимо сначала проектировать интерактивные продукты и только тогда начинать программирование. Следующее по важности изменение состоит в том, чтобы сделать ответственными за проектирование подготовленных проектировщиков взаимодействия. В последующих главах я покажу, чего можно достигнуть, предприняв эти шаги.
Часть IV
Проектирование взаимодействия – выгодный бизнес
Глава 9
Проектирование для удовольствия
Альберт Эйнштейн сказал, что нельзя решить проблему, находясь внутри системы, которая ее породила. Я уделил уже достаточно времени тому, чтобы идентифицировать старый образ мышления и показать, почему он неработоспособен. Теперь настало время поговорить о новом методе, который работает. Начиная с 1992 года я занимался разработкой такого метода, получившего название целеориентированного проектирования (Goal-Directed Design), и проектировщики в моей консультационной компании применяют его во всех проектах. В основе метода лежат нетрадиционные подходы к проблемам, ряд мощных руководящих аксиом, а также некоторые поразительно эффективные мыслительные инструменты. В следующих трех главах я представлю обзор трех наиболее мощных инструментов, а также примеры их применения и результаты, которых можно ожидать.
Принципы действия самых мощных инструментов всегда просты, однако применение таких инструментов весьма нетривиально. Это, несомненно, верно и для инструментов проектирования взаимодействия. Наш самый эффективный инструмент исключительно прост: это точное описание пользователя продукта и его целей. Сложность здесь в том, чтобы создать и применить такое точное описание.
Наиболее очевидный подход состоит в том, чтобы найти реального пользователя и расспросить его, но этот подход неэффективен по ряду причин, и основная из них такова, что жертва определенной проблемы не наделяется автоматически силой, позволяющей эту проблему решить. Реальный пользователь – источник, конечно же, ценный, и мы уделяем большое внимание, но никогда не позволяем напрямую влиять на принимаемое решение.
Работоспособный подход кажется примитивным, но обладает невероятной мощью и эффективен во всех случаях. Мы выдумываем несуществующих пользователей и проектируем для них. Мы называем таких несуществующих пользователей персонажами (personas), и они представляют собой необходимую базу качественного проектирования взаимодействия.
Персонажи25 – не реальные люди, но они представляют реальных людей в процессе проектирования. Это гипотетические архетипы реальных пользователей. Будучи воображаемыми, они, тем не менее, определяются достаточно жестко и точно. На практике мы не столько «выдумываем» персонажи, сколько обнаруживаем их в качестве побочного продукта процесса расследования. Но мы действительно выдумываем их имена и личные сведения.
Персонажи определяются своими целями. Цели же, разумеется, определяются персонажами. Похоже на тавтологию, но это не так. Свойства персонажей выявляются в процессе изучения и анализа так же, как серия тектонических событий выявляется геологами по слоям осадочных пород: присутствие окаменелостей указывает на геологический пласт, а сам геологический пласт указывает на наличие окаменелостей. В следующей главе я много скажу о целях, сейчас же замечу, что мы выявляем их так же, как выявляем персонажи. Мы определяем, какие персонажи имеют отношение к делу, а также их цели в процессе итеративного совершенствования в рамках начального исследования предметной области.
Как правило, мы начинаем с разумного приближения и быстро сосредотачиваемся на правдоподобном наборе персонажей. Данный итеративный процесс похож на итеративный процесс, применяемый разработчиками программного обеспечения при создании продуктов, но имеет одно фундаментальное отличие. Циклическое совершенствование дизайна проекта и его предпосылок происходит быстро и легко, так как мы работаем на бумаге, работаем с текстом. Но циклическое совершенствование реализованного продукта медленнее и сложнее, поскольку здесь необходимо кодирование.
Проектируйте для одного персонажа
Чтобы создать продукт, удовлетворяющий широкую аудиторию пользователей, как подсказывает логика, необходимо возможно больше расширить его функциональность, охватив, таким образом, как можно больше людей. Это ошибочная логика. Вы добьетесь гораздо большего успеха, проектируя для единственного человека.
Представьте, что проектируете автомобиль, удовлетворяющий вкусам широких масс. Можно с легкостью выделить по меньшей мере три подгруппы пользователей: мать с малолетним ребенком, плотник, младший руководящий работник. Мамочке нужна безопасная, надежная машина, просторная, с большими дверями, для перевозки детей, собак, пакетов с покупками и т. д. Плотнику Джо нужен крепкий полноприводный пикап, достаточно большой, чтобы в него поместились лестницы, материалы, мешки с цементом и ящики с инструментами. Младший руководящий работник Сет видит себя в машине спортивного типа с мощным двигателем, жесткой подвеской, откидным верхом и – места в машине должно хватать только на двоих.
Решение задачи показано на рисунке. Такой автомобиль сочетает пожелания каждого водителя: минивэн с откидным верхом, пространством для детей и пиломатериалов. Что за дурацкая, невозможная машина! Даже если ее создать, ее никто не купит. Правильное решение: создать минивэн для Мамочки, пикап для Джо, спортивную машину для Сета.
Создать три различных программных продукта проще, чем создать три автомобиля, потому что единственный продукт, как правило, всегда можно настроить таким образом, чтобы получить три различных варианта поведения (заметим, что работу по настройке нельзя взваливать на пользователя).
Всякий раз, расширяя функциональность, чтобы охватить еще одного пользователя, вы ставите искусственные ограничители в виде лишних возможностей и органов управления программой на пути всех прочих пользователей. Выясняется, что механизмы, приятные одним пользователям, мешают другим получать удовольствие и удовлетворение. Попытка угодить слишком многим может убить продукт, хороший в других отношениях. Однако если спроектировать интерфейс с учетом одного персонажа, ничто не сможет встать между этим персонажем и абсолютным счастьем.
