Скачать 5.84 Mb.
|
Проектирование как процесс определения продукта В промышленности значение термина «проектирование» (design), к несчастью, стало слишком узким. Для многих разработчиков и руководителей оно означает то, что происходит на третьей диаграмме процессов с рис. 1.1, - косметическую операцию на модели реализации (подробнее в главе 2). Однако при правильном применении (как показано на четвертой диаграмме процессов на рис. 1.1) проектирование выявляет требования пользователя к продукту и формирует подробное представление о поведении и внешнем виде продукта. Иначе говоря, проектирование дает настоящее определение продукта, основанное на целях пользователей, потребностях бизнеса и ограничениях технологии. Проектировщики как исследователи Если проектирование и есть определение продукта, проектировщикам необходимо смотреть на вещи более широко, нежели принято в традиционном дизайне, особенно когда предметом проектирования являются сложные интерактивные системы. Одна из проблем существующего процесса разработки состоит в том, что роли участников чрезмерно узки: исследователи исследуют, а проектировщики проектируют (рис. 1.4). Результаты исследований поль-  Рис. 1.4. Проблематичный процесс проектирования. Исторически исследования и проектирование существовали раздельно, каждым направлением занимались свои специалисты. Под исследованиями, до недавнего времени понимали преимущественно маркетинговые исследования, а проектирование слишком часто ограничивали визуальным дизайном или поверхностным промышленным дизайном. В последнее времярамки исследований целевой аудитории расширились и включают в себя получение качественных этнографических данных. Однако без подключения проектировщиков к процессу исследований связь между данными исследований и проектными решениями остается в лучшем случае призрачной 50 Глава 1. Проектирование, ориентированное на цели зовательской аудитории и рынка анализируются маркетологами и специалистами по юзабилити, а затем сплавляются проектировщикам или программистам. В этой модели не хватает системных средств для перевода и синтеза результатов исследований в интерфейсные решения. Один из способов решения проблемы для проектировщиков - научиться быть исследователями. Существует неопровержимый довод в пользу участия проектировщиков в исследованиях. Эмпатия, или способность чувствовать то, что чувствуют другие люди, является одним из самых мощных инструментов проектировщиков. Прямые и обширные контакты с пользователями, без которых не обходится серьезное исследование, погружают проектировщиков в мир пользователей и заставляют думать о пользователях задолго до того, как речь пойдет о выработке решений. Одна из наиболее опасных практик при создании продукта - изоляция проектировщику от пользователей, поскольку это не дает появиться эм-патическому знанию. Кроме того, обычному исследователю часто сложно понять, какая информация о пользователях существенна с точки зрения проектирования. Вовлечение проектировщиков в исследование снимает оба этих вопроса. В практике авторов проектировщики получают навыки использования методов, описанных в главе 4, и в дальнейшем самостоятельно проводят исследования без дополнительной поддержки. Описанное решение жизнеспособно при условии, что у вашей команды есть время и ресурсы, чтобы полноценно подготовить проектировщиков для использования этих методов. В противном случае более уместна будет смешанная команда, состоящая из проектировщиков и специалистов по исследованию пользовательской аудитории. Хотя проведение исследований проектировщиками позволяет нам сделать несколько шагов навстречу целеориентированным решениям, между результатами исследований и детальными решениями по-прежнему остается разрыв. Как мы сейчас увидим, в картине не хватает нескольких фрагментов. От исследований к проектированию: модели, требования, инфраструктура Весьма немногие из распространенных методов проектирования включают в себя средства эффективного и систематического преобразования знаний, собранных в ходе исследований, в детальную спецификацию интерфейса. Мы уже указали на одну из причин этого: исторически сложилось так, что проектировщики выключены из цикла исследований, а потому им приходится полагаться на чужие представления о поведении и желаниях пользователей. Другая же причина состоит в том, что очень немногие подходы фиксируют поведение пользователей в форме, пригодной для формирования Целеориентированный процесс проектирования 51 определения продукта. Вместо того чтобы давать информацию о целях пользователей, большинство методов предоставляют информацию на уровне задач. Информация такого типа хорошо подходит для создания компоновочных схем, моделирования рабочего процесса и преобразования функций в элементы пользовательского интерфейса, но далеко не столь полезна для определения общей инфраструктуры, отражающей то, чем продукт является, что он делает и как это соответствует различным потребностям пользователей. Для преодоления разрыва нам требуется строгий систематический процесс создания моделей пользователей, определения требований к пользовательскому интерфейсу и преобразования их в общую концепцию взаимодействия (рис. 1.5). Задача целеориентированного проектирования - устранить существующий в процессе разработки цифровых продуктов разрыв между исследованиями пользовательской аудитории и проектированием эффективно сочетая новые и уже известные подходы.  Рис. 1.5. Процесс целеориентированного проектирования Обзор процесса Целеориентированное проектирование сочетает в себе методы этнографии, интервью с заинтересованными в проекте лицами, маркетинговые исследования, моделирование пользователей, проектирование на основе сценариев, а также базовый набор принципов и шаблонов проектирования взаимодействия. Оно позволяет создавать решения, соответствующие потребностям и целям пользователей с одной стороны, а также бизнес-требованиям и технологическим ограничениям - с другой. Процесс можно грубо разделить на шесть стадий: исследования, моделирование, выработка требований, определение общей инфраструктуры, детализация и сопровождение (рис. 1.5). Эти стадии соответствуют пяти видам деятельности, составляющим процесс проектирования взаимодействия согласно Джиллиан Крэмптон Смит (Gillian Crampton Smith) и Филипу Тэйбору (Philip Tabor), - понимание, абстрагирование, структурирование, отображение, детализация, - но с более выраженным акцентом на моделировании поведения пользователей и определении поведения систем. 52 Глава 1. Проектирование, ориентированное на цели Оставшаяся часть главы содержит высокоуровневый обзор пяти стадий целеориентированного проектирования. В главах с 4 по 7 приводится более подробное описание процессов для каждой из стадий. На рис. 1.6 представлена развернутая диаграмма процесса, включающая основные проблемы проектирования и точки взаимодействия. Исследования На стадии исследований для сбора качественных данных о существующих и/или потенциальных пользователях продукта применяются такие этнографические методы, как полевые наблюдения и полевые интервью. Помимо этого, если того требует предметная область, может проводиться конкурентный анализ, обзор маркетинговых исследований, обзор статей о технологиях, материалов по стратегии брендинга, а также индивидуальное интервьюирование лиц, принимающих решения, разработчиков, специалистов в предметной области и экспертов по технологии. Одним из основных результатов полевых исследований и интервью с пользователями является набор поведенческих шаблонов - характерных поведенческих моделей, помогающих классифицировать варианты использования будущего или существующего продукта. Анализ этих поведенческих шаблонов позволяет определять цели и мотивы (частные и общие желаемые результаты применения продукта). В деловой и технической областях такие поведенческие шаблоны часто совпадают с бизнес-ролями пользователей; в случае потребительской продукции - соответствуют стилю жизни пользователей. Поведенческие модели и связанные с ними цели пользователей являются основой персонажей, которые создаются на стадии моделирования. Маркетинговые исследования помогают находить и проводить отбор персонажей, укладывающихся в бизнес-модели. Интервью с лицами, принимающими решения, обзоры литературы и аудит пользовательского интерфейса продуктов дают проектировщикам возможность глубже вникнуть в предметную область и проливают свет на цели бизнеса, атрибуты бренда и технические ограничения, которые следует учесть при проектировании. В главе 4 приводится более подробная информация о целеориентиро-ванных методах исследований. Моделирование На стадии моделирования поведенческие шаблоны и шаблоны рабочих процессов, выявленные путем анализа результатов полевых исследований и интервью, собираются вместе в виде моделей предметной области и моделей пользователей. Модели предметной области могут включать информационные потоки и диаграммы рабочих процессов. Пользовательские модели, или персонажи, - это подробные и структурированные архетипы пользователей, которые представляют собой различные Целеориентированный процесс проектирования 53  Рис. 1.6. Процесс целеориентированного проектирования в деталях 54 Глава 1. Проектирование, ориентированное на цели устойчивые комбинации поведенческих моделей, склонностей, взглядов, целей, мотивов, обнаруженных на стадии исследований. Персонажи становятся главными действующими лицами описательной методики проектирования, основанной на сценариях. На стадии определения инфраструктуры персонажи способствуют генерации концепций взаимодействия, на стадии детализации обеспечивают обратную связь, позволяющую улучшить внутреннюю согласованность дизайна и его соответствие целям, а также служат мощным инструментом коммуникации, помогающим разработчикам и руководителям видеть, на чем основывается дизайн, и ранжировать функции продукта исходя из потребностей пользователей. На стадии моделирования проектировщики применяют разнообразные методологические инструменты для синтеза, дифференциации и ранжирования персонажей. Проектировщики выявляют различные типы целей и связывают типы возможных моделей поведения с персонажами таким образом, чтобы не оставалось белых пятен и не возникало повторений. Конкретное направление проектирования выбирается путем сопоставления целей персонажей и создания иерархии приоритетов, основанной на том, насколько широко цели того или иного персонажа покрывают цели других персонажей. Процесс присвоения персонажам типов определяет, насколько серьезное влияние каждый персонаж окажет на окончательную форму и поведение продукта. Подробно о персонажах и разработке целей мы поговорим в главе 5. Выработка требований Методы проектирования, применяемые проектными командами на стадии выработки требований, обеспечивают столь нужную связь между пользовательскими и всеми прочими моделями и инфраструктурой проекта. Здесь используются сценарные методы проектирования с одним важным нововведением: сценарии концентрируются не на абстрактных задачах пользователей, но прежде всего на достижении целей и удовлетворении потребностей конкретных персонажей. Персонажи дают понимание того, какие задачи действительно важны и почему, что приводит к созданию интерфейса, минимизирующего число задач (усилий), но при этом увеличивающего отдачу от них. Персонажи становятся главными участниками этих сценариев, и проектировщики изучают пространство возможных решений посредством своего рода ролевой игры. Для каждого интерфейса/ключевого персонажа процесс проектирования на данном этапе включает в себя анализ данных, связанных с персонажем, и анализ функциональных потребностей (выраженный в терминах объектов, действий и контекстов), сформированных и ранжированных с помощью целей персонажей, их моделей поведения, а также особенностей взаимодействия с другими персонажами в различных контекстах. Целеориентированный процесс проектирования 55 Такой анализ выполняется посредством последовательного уточнения контекстного сценария. Отправной точкой служит описание «одного дня жизни» персонажа, применяющего продукт, которое намечает высокоуровневые точки соприкосновения с продуктом, после чего происходит пошаговая детализация. Помимо требований, определяемых сценарием, проектировщики рассматривают навыки персонажа и его физические возможности, равно как и вопросы, связанные со средой применения продукта. Происходит также учет и балансирование целей бизнеса, желаемых атрибутов бренда и технических ограничений с целями и потребностями персонажа. На выходе этого процесса возникает сбалансированный перечень требований, включающий в себя пользовательские требования, требования бизнеса и технические ограничения, которым продукт должен удовлетворять. Определение инфраструктуры На стадии определения инфраструктуры команда проектировщиков создает общую концепцию продукта, определяя концепцию поведения, графического оформления и, если требуется, физической формы. Проектировщики взаимодействия синтезируют инфраструктуру взаимодействия при помощи контекстных сценариев в сочетании с еще двумя важнейшими методологическими инструментами. Первый инструмент - набор общих принципов проектирования взаимодействия, которые способствуют определению уместного в контексте различных ситуаций поведения системы. Главы 2 и 3, а также вся вторая часть книги посвящены высокоуровневым принципам проектирования взаимодействия, работающим на стадии определения инфраструктуры. Второй важнейший методологический инструмент - это набор шаблонов проектирования взаимодействия, являющихся решением (вариации здесь зависят от контекста) для соответствующих типов когда-то проанализированных проблем. Принципиально эти шаблоны очень похожи на шаблоны архитектурного проектирования, созданные Кристофером Александером (Christopher Alexander). Позже Эрих Гамма (Erich Gamma) и его коллеги познакомили с шаблонами проектирования и отрасль программирования. Шаблоны проектирования взаимодействия выстроены в иерархию и эволюционируют с появлением новых контекстов. Их функция - не загнать творчество проектировщика в рамки, а дать ему точку опоры для решения сложных задач, снабдив проверенными знаниями о проектировании. Когда информационные и функциональные потребности описаны на таком высоком уровне, они преобразуются в элементы дизайна в соответствии с принципами взаимодействия, а затем структурируются при помощи шаблонов и принципов в эскизы дизайна и описание поведения. Результатом этого процесса является определение инфраструктуры взаимодействия - устоявшаяся концепция проекта, задающая логическую и примерную формальную структуру для последующей детализации. Эта детализация выполняется на следующей стадии при 56 Глава 1. Проектирование, ориентированное на цели помощи последовательных итераций более узко сфокусированных сценариев. Такой подход часто представляет собой баланс проектирования «сверху вниз» (опирающегося на шаблоны) и проектирования «снизу вверх» (опирающегося на принципы). Когда продукт обретает физическую форму, проектировщики взаимодействия и промышленные дизайнеры в тесном сотрудничестве прорабатывают различные векторы ввода и возможные форм-факторы продукта, используя сценарии для выявления всех «за» и «против» по каждому варианту. Как только множество вариантов сокращается до нескольких многообещающих, промышленные дизайнеры начинают создавать первые физические прототипы, чтобы проверить принципиальную работоспособность концепции взаимодействия в целом. На этой ранней стадии крайне важно, чтобы промышленные дизайнеры не уходили в свободный полет и не порождали концепции, оторванные от поведения продукта. Как только начинается формирование инфраструктуры взаимодействия, проектировщики интерфейсов создают несколько вариантов визуальной инфраструктуры, которую иногда еще называют стратегией визуального языка. Для разработки вариантов типографики, цветовых решений и визуального стиля они задействуют атрибуты бренда, а также представление об общей структуре интерфейса. Детализация Стадия детализации схожа со стадией определения инфраструктуры, но в большей степени сосредоточена на подробностях реализации. Проектировщики взаимодействия фокусируются на согласованности задач, используя ключевые (пошаговые) маршруты, а также проверочные сценарии, дающие максимально подробные пути прохождения по пользовательскому интерфейсу. Графические дизайнеры определяют наборы начертаний и размеров шрифтов, пиктограмм и других визуальных элементов с очевидным ожидаемым назначением1 и четкой визуальной иерархией, чтобы в итоге обеспечить пользователю приятный опыт взаимодействия с продуктом. Промышленные дизайнеры (если их участие требуется) принимают окончательное решение по материалам и совместно с инженерами прорабатывают схемы сборки и другие технические аспекты. Завершением стадии детализации становится подробная проектная документация - спецификация формы и поведения в бумажном или интерактивном формате (в зависимости от ситуации). В главе 6 применение персонажей, сценариев, принципов и шаблонов на стадиях выработки требований, определения инфраструктуры и детализации описано более подробно. Ожидаемое назначение (англ. affordance) - воспринимаемые и фактические качества объекта, преимущественно фундаментальные, которые определяют возможные способы обращения с этим объектом. Подробнее см главу 13. -Примеч. науч.ред. Целеориентированный процесс проектирования 57 Сопровождение разработки Даже очень продуманное и проверенное проектное решение не позволяет предусмотреть все препятствия и технические осложнения на пути разработчиков. Мы на своем опыте знаем, насколько важно оставаться в контакте с разработчиками, чтобы отвечать на их вопросы, возникающие в процессе создания продукта. Часто требуется корректировать проектные решения, упрощать их по мере того, как команда разработчиков назначает приоритеты отдельным фрагментам своей работы и урезает проект, чтобы уложиться в сроки. Если в тот момент, когда возникла нужда в таких решениях, команда проектировщиков недоступна, разработчикам приходится самостоятельно искать выход в условиях дефицита времени, что в конечном итоге может не лучшим образом сказаться на целостности продукта. Ключ к успеху продукта - цели, а не возможности И разработчики, и маркетологи часто говорят о продуктах в терминах функций и возможностей. Это вполне естественно, поскольку именно так разработчики создают программы - функция за функцией. Список функций - один из способов выразить ценность продукта для потенциального покупателя (хотя, конечно, довольно ограниченный). Проблема в том, что подобные списки содержат абстрактные концепции, дающие лишь скудное представление о том, каким образом пользователи могут повысить свою эффективность и обрести счастье, используя предлагаемые технологии. Сузив определение продукта до списка функций и возможностей, мы проходим мимо замечательного шанса поставить возможности технологий на службу человеческим потребностям и целям. Слишком часто функции наших продуктов представляют собой лишь мозаику модных технологических новшеств, построенных на основе требований маркетологов или домыслов разработчиков, которые уделяют прискорбно мало внимания опыту взаимодействия пользователей с продуктом. Успешный проектировщик взаимодействия обязан держать цели пользователей в поле зрения даже в хаосе и под давлением цикла разработки продукта. Хотя в этой книге описаны и многие другие техники и инструменты, к целям пользователей мы будем возвращаться постоянно. Они - та основа, на которую должно опираться проектирование взаимодействия. Целеориентированный процесс с его четкими логическими обоснованиями проектных решений облегчает сотрудничество с инженерами и деловыми людьми, а также гарантирует, что проектирование происходит не по наитию и не является капризом творческой мысли либо отражением личных предпочтений участников разработки. 58 Глава 1. Проектирование, ориентированное на цели ПРИНЦИП проектирования Проектирование взаимодействия - не гадание на кофейной гуще. Целеориентированное проектирование - мощный инструмент, отвечающий на самые важные вопросы, которые возникают при описании и проектировании цифрового продукта:
Остальная часть этой книги посвящена ответам на перечисленные вопросы. Мы предложим вам инструменты, проверенные годами работы над сотнями продуктов, - инструменты, которые помогут вам выявить ключевых пользователей, понять их цели и транслировать это понимание в успешные проектные решения. 2 Модели реализации и ментальные модели В компьютерной отрасли часто используют термин компьютерная грамотность. Ученые мужи любят разглагольствовать о том, что у некоторых она есть, а у других нет, и о том, как обладающие ею преуспеют в информационном обществе, а остальным суждено сгинуть в социо-экономических разломах. Однако компьютерная грамотность- это просто эвфемизм, с помощью которого пользователей заставляют подстраиваться под чуждую им машинную логику, вместо того чтобы приблизить программные продукты к образу мышления пользователей. В этой главе мы поговорим о том, как недостаточное понимание пользователей и их подхода к программным продуктам подпитывает разделение людей на «компьютерно грамотных» и «компьютерно неграмотных» и как программы, более соответствующие особенностям мышления и деятельности людей, способны устранить эту проблему. Модели реализации В каждой машине есть механизм, благодаря которому она выполняет свое предназначение. Так, кинопроектор создает волшебную движущуюся картинку за счет хитроумной цепи движущихся деталей. Он испускает очень яркий свет, в течение доли секунды проходящий через маленькую прозрачную фотографию. Затем он на долю секунды перекрывает свет, чтобы подставить под луч света следующую маленькую фотографию. Тогда он снова на мгновение открывает лампу. Эта последовательность действий выполняется двадцать четыре раза в секунду. Программные продукты не имеют механизмов в обычном понимании - на место узлов из движущихся частей пришли алгоритмы и модули кода, сообщающиеся друг с другом. Представление о том, как в действительности работает машина или программа, Дональд 60 Глава 2. Модели реализации и ментальные модели Норман (Norman, 1989) и другие называют системной моделью; мы предпочитаем термин модель реализации, поскольку такая модель описывает подробности реализации программы в коде. Пользовательские ментальные модели Кинозрителю, пришедшему на захватывающую драму, легко забыть про тонкости, связанные с перфорацией кинопленки и работой обтюратора. В действительности многие посетители кинотеатров очень слабо представляют себе, как работает проектор и чем он отличается от телевизора. В представлении зрителя проектор просто выдает движущуюся картинку на большой экран. Это и называется пользовательской ментальной моделью, или концептуальной моделью. Чтобы пользоваться сложным устройством, человеку вовсе не нужно знать в деталях, как оно функционирует на самом деле, а потому он создает упрощенную мысленную схему, достаточно мощную для описания взаимодействия с устройством, но не всегда отражающую его реальную внутреннюю механику. К примеру, многие люди считают, что, когда они включают пылесос или блендер в розетку на стене, электричество начинает течь из стены в прибор, словно вода, по маленькой черной трубке электрошнура. Эта ментальная модель абсолютно адекватна с точки зрения использования бытовой электротехники. Тот факт, что модель реализации электрической сети не содержит ничего похожего на жидкость, путешествующую по проводам, и что электрический потенциал меняет знак 100 раз в секунду, для пользователя значения не имеет, хотя энергокомпании приходится знать все эти тонкости. В цифровом мире различия между пользовательской ментальной моделью и моделью реализации зачастую весьма ощутимы. Мы склонны игнорировать то обстоятельство, что сотовый телефон работает не так, как стационарный; он представляет собой приемопередатчик, способный в ходе двухминутного разговора сменить с пяток базовых станций сотового оператора. Однако это знание не помогает нам понять, как пользоваться телефоном. Расхождения между моделью реализации и ментальной моделью становятся особенно сильными в случае с программными приложениями, где сложность реализации зачастую так высока, что пользователь почти теряет возможность устанавливать простые механистические связи между своими действиями и реакциями программы. Занимаясь на компьютере цифровым монтажом звука или созданием визуальных спецэффектов вроде морфинга, мы лишены аналогий с механическим миром, так что наши ментальные модели неизбежно отличаются от модели реализации. Даже если связи будут видны, для большинства людей они останутся непонятными. Модели представления 61 Модели представления Лицом программного или цифрового продукта, как его видят люди, является его поведение, создаваемое программистом или проектировщиком. Это представление вовсе не должно быть точным описанием того, что происходит внутри компьютера, но, к несчастью, зачастую именно им и является. Возможность демонстрировать функционирование компьютера в отрыве от производимых им в реальности действий проявляется в программном обеспечении сильнее, чем в любой другой среде. Она позволяет сообразительному проектировщику скрывать некоторые из наиболее малопривлекательных особенностей того, как программа выполняет свою работу. Этот разрыв между реализацией и предлагаемым объяснением служит источником третьей модели, возникающей в цифровом мире, - модели представления. Модель представления - это избранный проектировщиком способ предъявления пользователю функционирования программы. Дональд Норман (Norman, 1989) называет это просто моделью проектирования. В мире программного обеспечения модель представления программы может (и часто должна) достаточно сильно отличаться от внутренней архитектуры программы. Например, операционная система может изображать сетевой файловый сервер так же, как простой локальный диск. Эта модель не отражает того, что физически диск может быть удален на многие километры. У понятия «модель представления» нет широко распространенного аналога в механическом мире. На рис. 2.1 представлены отношения, связывающие все три описанные модели. Чем ближе к пользовательской ментальной модели окажется модель представления, тем легче будет пользователю работать с программой и понимать ее. Наоборот, модель представления, слишком сильно приближенная к модели реализации, обычно значительно затрудняет освоение и применение программы при условии, что ментальные модели, которые пользователь строит для своих задач, отличаются от модели реализации программы (а это условие практически всегда выполняется). Все мы склонны создавать ментальные модели, упрощающие реальность. Поэтому, конструируя модели представления, которые проще моделей реализации, мы помогаем пользователю лучше понять продукт. К примеру, нажатие на педаль тормоза в автомобиле может вызывать в мыслях образ рычага, который упирается в колесо и замедляет его за счет трения. В реальном же механизме присутствуют гидравлические цилиндры и шланги, а также металлические колодки, сжимающие перфорированный диск; однако мы выбрасываем все это из головы, создавая более эффективную, хотя и менее точную ментальную модель. В случае с программами мы, например, представляем себе, что лист электронной таблицы прокручивается и являет нам новые ячейки, когда мы нажимаем на полосу прокрутки. Ничего такого в дейст- 62 Глава 2. Модели реализации и ментальные модели  Рис. 2,1. Внутреннее устройство программного обеспечения часто оказывается данностью и продиктовано различными ограничениями технического и делового характера. Модель того, как в действительности работает программа, называется моделью реализации. То, как пользователи воспринима ют свои задачи и как программа помогает в решении этих задач, есть ментальная модель взаимодействия с программой. Она основана на представлениях пользователей о том, как они решают свои задачи, и о том, как может работать компьютер. То, как проектировщики преподносят работу програм мы пользователю, называется моделью представления. В отличие от двух предшествующих моделей, она является тем аспектом программного обеспечения, который в значительной степени поддается контролю со стороны, проектировщиков. Одна из важнейших целей проектировщика — максимально приблизить модель представления к ментальной модели пользователей. Таким образом, проектировщикам очень важно детально знать, как целевые пользователи видят работу, выполняемую с помощью программы вительности не происходит: нет никакого листа с ячейками, вместо него - плотно упакованная структура данных со значениями, связанными друг с другом посредством указателей, на основе которых программа синтезирует в реальном времени новое изображение на экране. Понимание того, как в действительности работает программа, помогает ее использовать, однако это понимание обходится весьма дорого. Упрощение внешних проявлений процессов и ситуаций - один из наиболее эффективных способов, которыми компьютер может помочь человеку. Как следствие, пользовательские интерфейсы, построенные на основе ментальных моделей пользователей, существенно выигрывают по сравнению с интерфейсами, которые всего лишь отражают модель реализации. ПРИНЦИП проектирования Пользовательский интерфейс должен следовать пользовательской ментальной модели, а не модели реализации. В программе Adobe Photoshop пользователь имеет возможность регулировать цветовой баланс и яркость изображения при помощи функции Варианты (Variations). В интерфейсе этой функции вместо полей ввода численных значений цветов (модель реализации) предлагается набор миниатюр, различающихся настройками цветового баланса (рис. 2.2). Пользователю достаточно щелкнуть по миниатюре, наиболее точно Модели представления 63  Рис. 2.2. Adobe Photoshop дает замечательный пример интерфейса, основанного на пользовательской ментальной модели. Диалоговое окно Варианты (Variations) предлагает набор миниатюр, варьирующихся по цветовому балансу и яркости с регулируемым шагом. Пользователю достаточно щелкнуть по миниатюре, наиболее точно представляющей желаемую коррекцию цвета. Выбранное изображение становится точкой отсчета для новых вариантов. Этот интерфейс следует ментальной модели художника, которому требуется получить определенный конечный вид изображения, а не набор абстрактных чисел представляющей желаемую коррекцию цвета. Этот интерфейс приближен к ментальной модели действия, ибо пользователь - вероятно, художник или дизайнер - думает о том, как должно выглядеть изображение, а не об абстрактных числах. Когда модель представления программы приближена к пользовательской ментальной модели, из интерфейса уходит избыточная сложность, поскольку пользователь получает когнитивную инфраструктуру, которая ясно указывает, как могут быть достигнуты его цели и удовлетворены его потребности. ПРИНЦИП проектирования I Целеориентированное взаимодействие отражает пользовательские ментальные модели. 64 |
