об интерфейсе, Алан Купер, книга, содержание about face 3, Alan Cooper

Алан Купер об интерфейсе. Краткий курс. 1 часть.

В этой статье, я представлю краткое содержание  книги Алана Купера «об интерфейсе».  Все кто занимается интерфейсами и веб-дизайном, должны прочитать! Книга поможет в организации работы над проектом и возможно изменит ваш взгляд на вещи, которые вас окружают.
об интерфейсе, Алан Купер, книга, содержание about face 3, Alan Cooper
1. Цифровым продуктам необходимы более качественные методы проектирования
Проектирование, по мнению промышленного дизайнера Виктора Папанека (Victor Papanek), есть сознательные и интуитивные усилия по созданию значимого порядка.

Мы предлагаем несколько более подробное определение проектирования, ориентированного на людей:

• понимание желаний, потребностей, мотивации пользователей и контекста, в котором эти пользователи находятся;

• понимание возможностей, требований и ограничений бизнеса, технологии и предметной области;

• использование этих знаний в качестве основы всех планов по созданию продуктов, форма, содержание и поведение которых делают их полезными, удобными и желанными, а также экономически жизнеспособными и технически осуществимыми.

Это определение хорошо подходит для многих дисциплин проектирования, хотя конкретные акценты на форме, содержании или поведении будут зависеть от того, что именно мы проектируем.  Так, в случае
информационного веб-сайта может потребоваться особенное внимание к содержанию, тогда как при проектировании кресла важна главным образом форма.

2. Цифровые продукты грубы

Программы часто обвиняют пользователя в ошибках, в которых нет (или не должно быть) его вины. Сообщения об ошибках вроде приведенного на рис. 1.  выскакивают, словно черт из табакерки, чтобы еще и еще раз возвестить пользователю о его промахе. Вдобавок эти сообщения требуют, чтобы пользователь непременно согласился со своим провалом, щелкнув по кнопке OK.

Рис. 1. Замечательно, спасибо за откровенность. Почему программа
не уведомила библиотеку? О чем она хотела уведомить эту библиотеку?
Почему она говорит об этом нам? С чем мы вообще соглашаемся?
С какой стати сбой в программе – это «OK»?

Программы часто допрашивают пользователя, засыпая его маловразумительными вопросами, на которые пользователь не готов или не склонен отвечать: «Куда ты подевал этот файл?» Снисходительные вопросы, вроде «Вы уверены?» и «Вы действительно хотите удалить этот файл или нажали на клавишу Delete по другой причине?», равно унизительны и неприятны.

3. Цифровые продукты ведут себя неподобающим образом

К примеру, если вы сохраните документ Microsoft Word, распечатаете его, а затем попытаетесь закрыть, программа снова спросит, желаете ли вы сохранить документ! Очевидно, печать документа заставила программу думать, что документ изменился, хотя этого не произошло. «Не, мам, я тебя не слышал!»

4.Почему эти продукты столь плохи?

Так в чем же реальная проблема? Почему индустрия технологий оказывается в целом недееспособной, когда требуется продумать интерактивную составляющую цифровых продуктов? Тому есть три основных причины: отсутствие представления о пользователях, конфликт между потребностями людей и приоритетами разработки, а также отсутствие процесса, позволяющего понимать потребности человека и помогающего в разработке удобной формы и качественного поведения продукта.

5.Эволюция проектирования в промышленности

 

 

 

 

 

 

 

 

 

 

Традиции дизайна, которым следуют корпорации в целях обеспечения желанности создаваемых ими продуктов, не слишком помогают в мире интерактивности. Проектирование поведения – проблема иного рода, требующая более глубокого понимания контекста, а не просто следования правилам визуальной композиции и брендинга. Проектирование поведения требует понимания отношений пользователя          с продуктом – с момента осознания потребности в продукте до момента, когда продукт становится больше не нужен. И важнее всего понимание  того, каким образом пользователь желает применять продукт, какими способами и с какими целями.

6. Выявление целей пользователей

Присмотревшись к большинству существующих коммерческих программ, веб-сайтов и цифровых продуктов, вы обнаружите, что их пользовательские интерфейсы пугающе далеки от целей пользователей. Эти интерфейсы раз за разом:
• заставляют пользователей чувствовать себя идиотами;
• заставляют пользователей совершать серьезные ошибки;
• требуют слишком больших трудозатрат для эффективной работы;
• не делают опыт пользователя интересным и приятным.

Компании, создающие такие продукты, неверно расставляют приоритеты. В основном они слишком сильно сосредотачиваются на вопросах реализации – и это уводит их в сторону от потребностей пользователей. Даже если компании проявляют чуткость к своим пользователям, они часто бессильны изменить собственные продукты, поскольку сложившийся процесс разработки предполагает, что интер-фейсом следует заниматься после начала работы над программным кодом, а иногда – даже после окончания. Но как невозможно эффективно спроектировать здание после начала строительства, так же невозможно легко заставить программу служить целям пользователя,  когда уже написан значительный объем базового кода.

Важно!

Наконец, даже когда компании сосредотачиваются на пользователях, они уделяют слишком пристальное внимание задачам, которые выполняют пользователи, и упускают из виду цели, ради которых выполняются эти задачи. Программа может быть технологически превосходной, прилежно решать все задачи бизнеса – и при этом являть собой серьезный коммерческий провал. Нельзя игнорировать технологию и задачи, но они представляют собой лишь часть более глобального плана, который включает в себя проектирование с учетом целей пользователей.

7.  Цели, задачи, деятельность

На тот случай, если вы все еще не чувствуете разницу между целями с одной стороны и деятельностью и задачами – с другой, есть простой способ их различать. Цели определяются человеческими мотивами и потому со временем не меняются или меняются весьма незначительно. Деятельность и задачи преходящи, поскольку почти целиком основаны на имеющейся под рукой технологии. К примеру, в поездке из Сент — Луиса в Сан’Франциско вероятные цели человека – скорость, удобство, безопасность. В 1850 году поселенец, желающий скорости и комфорта, путешествовал бы на крытом фургоне и держал бы при себе верное ружье. Сегодня деловой человек, направляющийся из Сент — Луиса в Сан’Франциско, путешествует на реактивном лайнере, а огнестрельное оружие в интересах безопасности ему рекомендуется оставить дома. Цели остались неизменными, однако деятельность и задачи изменились следом за технологиями настолько, что стали в некоторых отношениях прямо противоположными.
Строя проектирование исключительно на основе анализа деятельности и задач, мы рискуем попасть в ловушку устаревших технологий или применить модель, соответствующую целям корпорации, но не отвечающую целям пользователей. Взгляд через призму целей позволяет пользоваться преимуществами современной технологии для исключения лишних задач и радикального упорядочения структуры деятельности. Понимание целей пользователя помогает проектировщикам избавляться от деятельности и задач, которые технология способна выполнять за человека.

8. Проектирование взаимодействия – не гадание на кофейной гуще.

Целеориентированное проектирование – мощный инструмент, отвечающий на самые важные вопросы, которые возникают при описаниии проектировании цифрового продукта:
• Кем являются мои пользователи?
• Чего пытаются достичь мои пользователи?
• Что мои пользователи думают о своих целях сами?
• Какого рода опыт будет для моих пользователей привлекательным и полезным?
• Как должен себя вести мой продукт?
• Как должен выглядеть мой продукт?
• Как пользователи будут взаимодействовать с моим продуктом?
• Как наиболее эффективно реализовать функции моего продукта?
• Как начинающие пользователи будут знакомиться с моим продуктом?
• Каким образом мой продукт сможет придать технологии привлекательный облик и сделать ее понятной и управляемой?
• Как мой продукт может решить проблемы пользователей?
• Как мой продукт поможет в достижении целей тем пользователям, которые редко работают с продуктом или имеют мало опыта?
• Каким образом мой продукт сможет удовлетворить запросы опытных пользователей, которым нужна функциональная мощь и глубина проработки?

9. Пользовательский интерфейс должен следовать пользовательской ментальной модели,  а не модели реализации.

В программе Adobe Photoshop пользователь имеет возможность регулировать цветовой баланс и яркость изображения при помощи функции Варианты (Variations). В интерфейсе этой функции вместо полей ввода численных значений цветов (модель реализации) предлагается набор миниатюр, различающихся настройками цветового баланса (рис. 3).
Пользователю достаточно щелкнуть по миниатюре, наиболее точно представляющей желаемую коррекцию цвета. Этот интерфейс приближен к ментальной модели действия, ибо пользователь – вероятно, художник или дизайнер – думает о том, как должно выглядеть изображение, а не об абстрактных числах. Когда модель представления программы приближена  к пользовательской ментальной модели, из интерфейса уходит избыточная сложность, поскольку пользователь получает когнитивную инфраструктуру, которая ясно указывает, как могут быть достигнуты его цели и удовлетворены его потребности.

10. Интерфейсы, спроектированные инженерами, следуют модели реализации

Даже интерфейс Windows временами соскальзывает к модели реализации. Если перетащить мышью файл из одной папки в другую в пределах одного жесткого диска 1, система интерпретирует это как команду «Переместить», то есть файл удаляется из первой папки и попадает во вторую, что хорошо соответствует ментальной модели. Однако перетаскивание файла с диска C на диск D будет воспринято как команда«Копировать», то есть файл будет добавлен во вторую папку, но не будет удален из первой. Истоки этого поведения находятся в модели реализации – в том, каким образом работает файловая система. При перемещении файла из одной папки в другую в пределах одного диска операционная система всего лишь переносит запись имени файла в таблице размещения файлов. Стирания и повторной записи файла при этом не происходит. Однако перенос файла  на другой диск требует физического копирования данных на целевой диск. Чтобы соответствовать ментальной модели пользователя, система должна после копирования удалить оригинал, хотя это и противоречит модели реализации.
Такая непоследовательность поведения компьютера при выполнении двух, казалось бы, похожих действий способна порождать у пользователей значительный когнитивный диссонанс (путаницу, возникающую в результате столкновения двух противоречащих друг другу картин реальности), что, в свою очередь, затрудняет освоение этого простого взаимодействия. Чтобы добиться желаемого результата, пользователь должен понимать, что поведение компьютера зависит от физической природы конкретных видов устройств хранения данных.
При определенных условиях трактовка перетаскивания файла с диска на диск как команды «Копировать» может быть желательным поведением системы, особенно при копировании файлов с жесткого диска на сменные носители вроде USB’ накопителей типа flash, поэтому многие люди       не осознают, что это лишь побочный эффект модели реализации.
Однако по мере развития компьютерной техники логические тома перестают представлять собой только физические диски, и этот побочный эффект все реже оказывается полезным, а напротив, начинает раздражать, поскольку нам приходится держать в голове особенности поведения каждого вида накопителей.

11. Не копируйте артефакты механической эры в пользовательских интерфейсах без учета возможностей информационной эры.

Возьмем для примера календарь. В физическом мире календари сделаны из бумаги и разбиты на страницы по месяцам. Таков разумный компромисс, основанный на размерах листа бумаги, папки, портфеля и ящиков стола. Программы, содержащие визуальное представление календаря, встречаются повсеместно и почти всегда отображают месяцы по одному. Даже если программа способна показать сразу несколько месяцев, как, скажем, Outlook, дни все равно выводятся в виде последовательностей длиной в один месяц.  Почему?

Бумажные календари отображали месяцы по одному из’за ограничений, связанных с размерами бумаги, а конец месяца выглядел удобной точкой разрыва. Экраны компьютеров не столь ограни-чены, однако большинство проектировщиков настойчиво копируют этот артефакт механической эры (рис. 4). На компьютере календарь запросто может быть непрерывной прокручиваемой последовательностью из дней, недель или месяцев, как показано на рис. 5. Запланировать что-либо на период с 28 августа по 4 сентября просто, если недели следуют одна за другой непрерывно, а не разнесены волей проектировщика по месяцам. К тому же сетка в электронных календарях практически всегда имеет фиксированный размер ячеек. Почему нельзя изменять ширину колонок с днями или высоту строк с неделями, как в электронной таблице?
Вам, вероятно, хотелось бы увеличить размер клеток выходных дней, чтобы обозначить их важность в сравнении с буднями. Если вы – деловой человек, рабочая неделя в вашем календаре потребует больше пространства, чем неделя отпуска. Эти идиомы столь же хорошо известны, как и электронные таблицы, то есть их вполне можно считать универсальными; однако представления механической эры укоренились так глубоко, что мало кому из разработчиков программ удается отойти от них.

 

 

 

 

 

 

 

 

 

 

 

 

 

12. Новички, эксперты и середняки 

Вечные середняки.Большинство пользователей – не начинающие и не эксперты; они середняки.

Принцип проектирования — Никто не желает оставаться начинающим.

Хорошо сбалансированный пользовательский интерфейс во многом строится по тому же принципу. Вместо того чтобы потакать потребностям новичков или экспертов, он направлен главным образом на удовлетворение нужд вечных середняков. В то же время он обеспечивает механизмы, достаточные для эффективной работы «крайних» составляющих аудитории.

Качественно спроектированный интерфейс веб-сайта должен помогать пользователям быстро осваивать навигацию и функциональность. Здесь стоит обратить внимание на тот факт, что даже клиент, уже посетивший ваш сайт несколько раз и знакомый с вашими предложениями, а также в целом с идиомами взаимодействия, характерными для интернет-пространств, может заходить к вам недостаточно часто, чтобы запомнить, как сайт организован. Поэтому взаимодействие с сайтом важно делать как можно более прозрачным и очевидным. Кроме того, в последнее время набирает популярность идея отслеживать действия пользователя на сайте и на этой основе адаптировать сайт к потребностям пользователя. В этой связи полезно использовать cookie’файлы, чтобы идентифицировать новых посетителей и предлагать им ненавязчивую помощь при первом обращении к сайту.

Наша цель состоит не в том, чтобы угождать начинающим, – равно как и не в том, чтобы подгонять середняков быстрее становиться экспертами. Наша цель тройственна: быстро и безболезненно переводить
начинающих в середняки, не создавать препятствий на пути середняков, желающих стать экспертами, и – самое главное – следить за тем, чтобы вечные середняки, оставаясь в своей части спектра навыков,
были счастливы.

Начинающие, несомненно, – люди чувствительные, и деморализовать новичка очень легко. Однако не следует забывать, что человек никогда не ставит перед собой цели оставаться начинающим. Никто не хочет быть новичком. Это лишь обряд инициации, через который должны пройти все. Хорошие программы сокращают этот обряд, не заостряя на нем внимания.

Считайте пользователей людьми очень умными, но очень занятыми.

Новый пользователь должен быстро усвоить используемые в программе понятия и уловить ее предназначение, иначе он от нее откажется. Поэтому первоочередная задача проектировщика – убедиться, что программа адекватным образом отражает ментальные модели задач пользователя. Возможно, между сеансами работы с программой пользователь не будет помнить, какая в точности команда требовалась для работы с определенным объектом, но, если концептуальная структура интерфейса соответствует его ментальной модели, он определенно запомнит такие важные понятия, как отношения между объектами и действиями.
Переход начинающих в разряд середняков требует дополнительной помощи со стороны программы, но эта дополнительная помощь станет для них обузой, как только они достигнут цели. Отсюда следует, что любая предлагаемая вами дополнительная поддержка не должна быть фиксированной частью интерфейса. Она должна уметь исчезать тогда, когда необходимость в ней отпала. Новички часто полагаются на меню при изучении и исполнении команд. Каким бы медленным и тяжеловесным инструментом ни были меню – они полны и подробны, и это дает чувство уверенности. Открываемые командами меню диалоговые окна (если таковые имеются) также должны содержать (краткие) пояснения и удобную кнопку отмены (Cancel).

Экспертам временами требуются экзотические возможности, причем некоторые из этих возможностей они могут использовать очень часто. В то же время эксперты определенно выступают за более быстрый доступ к регулярно используемым инструментам из рабочего набора, который может быть довольно большим. Иначе говоря, экспертам нужны короткие пути ко всему. Экспертам нравятся новые мощные функции. Их уровень владения программой позволяет им не испытывать беспокойства по поводу возрастающей сложности.

Вечные середняки разделяют функции на регулярно используемые и применяемые лишь изредка. Пользователь может экспериментировать с непонятными возможностями, но вскоре он выявит – вероятно, подсознательно – рабочий набор часто используемых инструментов и будет требовать, чтобы инструменты из этого набора были размещены на самом видном месте в пользовательском интерфейсе – там, где их будет легко найти и запомнить. Вечные середняки обычно знают о существовании дополнительных возможностей – хотя могут не нуждаться в них и не представлять себе,
как с ними работать. Однако знание о наличии таких возможностей добавляет вечному середняку уверенности, убеждает его, что он совершил правильный выбор, когда сделал ставку на эту программу.

13. Роли пользователей

Хорошо проработанные персонажи охватывают все те же виды отношений, что и роли, но выражают их в виде целей и дают примеры в повествовательной форме. В итоге как проектировщикам, так и заинтересованным лицам становится проще понимать последствия проектных решений в «человеческой» перспективе. Описание целей персонажей задает контекст и структуру для задач, указывая, как культурная среда и рабочий процесс влияют на поведение. Кроме того, сосредоточение на ролях пользователей вместо более сложных шаблонов поведения может привести к чрезмерному выхолащиванию отличительных признаков, определяющих похожесть и непохожесть пользователей. Можно создать персонажа, представляющего потребности нескольких ролей (скажем, при проектировании мобильного телефона путешествующий коммивояжер может представлять также потребности занятого руководителя, который постоянно находится в разъездах). Может оказаться также, что одну роль выполняют разные люди, которые по’разному мыслят и действуют (скажем,сотрудник отдела закупок в химической промышленности может думать о своей работе совсем иначе, чем такой же сотрудник в производстве бытовой электроники). В случае потребительских товаров роли практически бесполезны. Если вы проектируете веб’сайт для автомобильной компании, роль «покупатель автомобиля» не имеет смысла как средство проектирования: разные люди очень по’разному подходят к вопросу приобретения автомобиля.

14. Цели
В то время как персонажи задают контекст для шаблонов вариантов поведения, цели являются стимулами этого поведения. Персонаж без целей полезен в качестве инструмента коммуникации, но теряет ценность в качестве средства проектирования. Цели пользователя – это призма, через которую проектировщики должны рассматривать функции продукта. Функциональность и поведение продукта должны быть ориентированы на достижение целей пользователей через решение задач – причем посредством минимально возможного числа этих задач. Помните, что задачи – лишь средство движения вперед, а цель – и есть действительный пункт назначения.

15. Цели пользователей и когнитивные процессы обработки
В своей книге «Emotional Design» (Norman, 2005) Дон Норман выдвигает идею о том, что проектирование продукта должно затрагивать три различных уровня когнитивной и эмоциональной обработки, которые он называет физиологическим, поведенческим и аналитическим.
Идеи Нормана, основанные на годах исследований человеческого сознания, предлагают внятную структуру для процесса моделирования реакции пользователей на продукт и бренд, а также рациональный
контекст для интуитивных догадок, давно будораживших умы профессиональных проектировщиков.
Вот три уровня когнитивной обработки по Норману:
•  Физиологический.  Самый непосредственный уровень обработки, на котором человек реагирует на визуальные и другие сенсорные аспекты продукта еще до того, как случится какое’либо значимое
взаимодействие. Обработка на физиологическом уровне позволяет нам быстро принимать решения о том, что хорошо или плохо, безопасно или опасно. Это одна из замечательных особенностей человеческого поведения, но ее эффективная поддержка входит в число наиболее сложных задач при создании цифровых продуктов. Малкольм Гладуэлл (Malcolm Gladwell) исследует этот уровень когнитивной обработки в своей книге «Blink»1. Еще более подробное изучение принятия решений на интуитивном уровне предпринято в книгах «Sources of Power» Гэри Клейна (Gary Klein) и «HareBrain, Tortoise Mind» Гая Клэкстона (Guy Claxton).

Поведенческий. Средний уровень обработки, позволяющий нам контролировать простое, повседневное поведение. Этот уровень, по Норману, представляет большую часть человеческих действий.
Норман утверждает – и в этом он прав, – что традиционно в практике проектирования и юзабилити рассматривался почти исключительно этот уровень когнитивной обработки. Поведенческая обработка способна усиливать или сглаживать как более низкоуровневые физиологические реакции, так и более высокоуровневые аналитические. И, наоборот, физиологические и аналитические реакции способны усиливать или сглаживать реакции уровня поведения.

Аналитический. Самый поздний уровень обработки, на котором происходит сознательное изучение и анализ уже приобретенного опыта. Аналитическая обработка способна усиливать или сглаживать поведенческую обработку, но не оказывает прямого влияния на физиологические реакции. Этот уровень когнитивной обработки доступен только через память, но не через прямое взаимодействие или восприятие. С точки зрения проектирования наиболее интересный аспект аналитической обработки состоит в том, что посредством анализа и рефлексии мы способны интегрировать наш опыт обращения со спроектированными артефактами в более широкий жизненный опыт и со временем увязывать смыслы и ценности непосредственно с артефактами.

При обсуждении физиологического уровня часто всплывает заблуждение о том, что при проектировании на этом уровне речь идет о создании красивых вещей. Программы для ведения боевых действий и системы радиотерапии – вот всего два примера ситуации, где проектирование красоты может оказаться неподходящим направлением приложения усилий. Действительный смысл проектирования на физиологическом уровне – в том, чтобы произвести впечатление, то есть вызвать уместную в определенном контексте психическую или эмоциональную реакцию, а не только в эстетике. Красота – и связанные с ней ощущения возвышенности и удовольствия – лишь малая часть палитры вызывающего эмоции проектирования. Проигрыватель MP3’музыки и сетевая банковская система требуют очень разных воздействий на пользователя.

Интересный факт: исследователям в области юзабилити удалось показать, что пользователи изначально считают привлекательные интерфейсы более удобными – и эта уверенность зачастую сохраняется еще долго после того, как пользователь приобрел достаточный опыт обращения с интерфейсом и обладает неоспоримыми свидетельствами обратного (Dillon, 2001). Возможно, причина в том, что пользователи, вдохновленные видимой простотой использования, прикладывают больше усилий для изучения сложных интерфейсов, а впоследствии не желают соглашаться с тем, что время было потрачено зря.

16. От требований к пользовательскому интерфейсу: общая инфраструктура и детализация

Мы обнаружили, что если при проектировании сложного поведения и взаимодействия сразу сфокусироваться на пиксельной прорисовке, дизайне элементов интерфейса и конкретных аспектах взаимодействия, это может помешать эффективному проектированию исчерпывающей инфраструктуры, охватывающей все варианты поведения продукта. Используя подход «сверху вниз», мы можем начать с общей картины и создавать решения, не вдаваясь в детали, чтобы сохранить фокус разработки на самом главном – обеспечении достижения целей и удовлетворении требований персонажей.

Пересмотр сделанного – нормальное явление в мире проектирования. Нет смысла тратить слишком много времени или сил на создание макетов, которые все равно будут отброшены или модифицированы. Мы обнаружили, что раскадровки с эскизами в сочетании со сценариями’рассказами – весьма эффективный способ исследовать и обсуждать решения проектирования, не неся излишних расходов и не порождая ненужной инерции.

17. Создание инфраструктуры взаимодействия

Общая инфраструктура взаимодействия задает не только высокоуровневую компоновку экранов, но также рабочий процесс, поведение и организацию продукта. Следующие шесть шагов составляют процесс
создания общей инфраструктуры взаимодействия:

1. Определение форм-фактора, типа приложения и способов управления.
2. Определение функциональных и информационных элементов.
3. Определение функциональных групп и иерархических связей между ними.
4. Макетирование общей инфраструктуры взаимодействия.
5. Создание ключевых сценариев.
6. Выполнение проверочных сценариев для верификации решений.

18. Продукт как человеческое существо

существует мощный способ представить идеальный опыт пользователя (который необходимо отразить в контекстных сценариях концептуального уровня) – притвориться, что инструмент, продукт или система – волшебные. Точно так же, притворившись, что система – это человек, мы получим мощный инструмент для структурирования деталей уровня взаимодействия.

Взаимодействие с цифровой системой должно по тону и приносимой пользе напоминать общение с вежливым и внимательным человеком (Cooper, 1999).Определяя варианты взаимодействия и поведения наряду с функциональными элементами и группами, спросите себя: что сделал бы человек, который рад помочь? На что похоже тщательно продуманное и взвешенное взаимодействие? Гуманно ли продукт поступает с ключевым персонажем? Какими способами программа может информировать пользователя, не мешая ему при этом работать? Как она может свести к минимуму усилия персонажа в достижении его целей? К примеру, мобильный телефон, ведущий себя, как вдумчивый человек, знает, что после завершения разговора с абонентом, отсутствующим в телефонной книжке, возможно, потребуется записать туда его телефонный номер, и потому предоставляет простой и очевидный способ это сделать. Невнимательный к человеку телефон вынуждает пользователя записывать номер на тыльной стороне ладони, после чего лезть в телефонную книгу и создавать новую запись.

19. Макетирование общей инфраструктуры взаимодействия

Разумно сделать несколько набросков, отражающих различные варианты расположения высокоуровневых контейнеров внутри интерфейса. Начинать следует с самой схематичной визуализации: каждую
функциональную группу или контейнер представляет прямоугольник с названием, общую картину дополняют описания связей различных областей (рис. 7).

Не пропускайте этап изучения инфраструктуры в целом, не позволяйте деталям отдельных частей интерфейса отвлекать вас (хотя попытки представить содержимое каждого из контейнеров помогут решить, как расположить элементы и сколько пространства под них отвести). Для проектирования на уровне отдельных интерфейсных элементов будет еще уйма времени, а попытка заняться ими слишком рано связана с риском утратить при движении вперед логичность интерфейса. Уровень абстрактности «фазы прямоугольников» позволяет с легкостью исследовать массу способов представления информации и функциональности и при необходимости вносить радикальные изменения. Часто оказывается полезным попробовать несколько вариантов расположения областей и выполнить проверочные сценарии – и только тогда остановиться на лучшем решении. Трата слишком больших сил и времени на мелкие детали на ранней стадии проектирования затрудняет проектировщикам смену курса в сторону более правильного решения. Выбросить результаты работы и попробовать иной подход легче, когда затраты невелики.

Создание макета общей компоновки – процесс итерационный, и эту работу лучше выполнять небольшой сплоченной группой из графического дизайнера, промдизайнера и одного’двух проектировщиков взаимодействия (в идеале – проектировщика взаимодействия и «коммуникатора» – человека, который думает в терминах текстового описания продукта). По нашему опыту простая белая доска – лучший инструмент для создания первоначальных набросков. Она способствует совместной работе, обсуждениям и, разумеется, позволяет быстро все стереть и нарисовать заново. В таком варианте цифровой фотоаппарат – простое средство моментальной фиксации идей для последующего их рассмотрения.
Когда макеты достигают разумного уровня детализации, можно переходить к использованию компьютерных инструментов рисования.

20. Раскадровка

Применение набросков с низким уровнем детализации в сочетании с повествовательным ключевым сценарием позволяет создать живое описание того, как предложенное проектное решение помогает персонажам достигать их целей. Каждое взаимодействие между пользователем и продуктом можно описать одним или несколькими слайдами. Переход между слайдами позволяет проверить связность и ход взаимодействия.

21.Создание визуальной инфраструктуры. исследование визуального языка

Предметом исследования являются такие переменные, как цвет, шрифт, оформление панелей, а также общие качественные характеристики и «материальные» свойства интерфейса (например, воспринимается ли интерфейс как стеклянный или как бумажный?).

Создавая визуальный стиль, важно учитывать также особенности среды и склонности персонажей. Экраны, с которыми человек будет работать при ярком освещении или на некотором расстоянии, требуют более контрастных и более насыщенных цветов. Пожилым и близоруким людям требуется более крупный и более читаемый шрифт. При первом обсуждении с заинтересованными лицами мы обычно показываем от трех до пяти различных вариантов графического дизайна.
С проектированием взаимодействия дела обстоят иначе – обычно демонстрируется один оптимальный вариант интерфейса. Что же касается визуальной части, может существовать целый ряд стилей, сопря’
гающихся с ключевыми словами и целями. И разумеется, «красота – в глазах смотрящего». Мы обнаружили, что зачастую мнение заинтересованных лиц относительно цветов, которые следует применять в
интерфейсе, попросту непредсказуемо.
Часто полезно создать один или два крайних варианта, в которых интерфейс имеет перекос в ту или иную сторону. Так проще продемонстрировать различия в подходах, что помогает заинтересованным лицам выбрать направление движения. Позже в ходе проектирования еще будет возможность выправить перекошенный визуальный стиль. При этом все представленные заинтересованным лицам варианты должны быть разумными и подходящими. Если вам не нравится один из вариантов, именно его выберут заинтересованные лица – это почти неписаное правило.

Никогда не демонстрируйте вариант, который не нравится вам самим, потому что именно этот подход может понравиться заинтересованному лицу.

22. Создание физической инфраструктуры. Совместно с проектировщиками взаимодействия обсудить форм-фактор и способы управления.

Принимая решения, следует помнить, в частности, об эмоциональных целях персонажа, взглядах, привычках, факторах среды, а также о ключевых словах, связанных с опытом и брендом, исследованиях рынка, стоимости производства и желаемой розничной стоимости продукта. Стоимость шарнира может привести к превышению бюджета по аппаратной части, а внутренние компоненты (такие как аккумуляторы) способны оказывать значительное влияние на форму, так что ранние проверки реалистичности вариантов продукта, проведенные совместно с инженерами’механиками и электриками, обязательны. Пользовательский опыт целостен – форму и поведение продукта следует проектировать согласованно.

23. Детализация формы и поведения

На этапе детализации происходит перевод раскадровок в полноценные
экраны, отражающие пользовательский интерфейс с точностью до от’
дельных пикселов.

Проработайте все возможные представления и диалоговые окна. На этапе детализации дизайнерам следует создать и поддерживать в актуальном состоянии руководство по визуальному стилю. Программисты, используя такое руководство, могут корректно применять элементы дизайна, создавая низкоприоритетные части интерфейса, на которые у проектировщиков обычно не хватает времени и ресурсов. Одновременно с этим промдизайнеры совместно с инженерами работают над финальным «конструктором» и его сборкой.
Конечные результаты проектирования могут быть самыми разнообразными, но, как правило, мы создаем спецификации формы и поведения продукта в печатном виде. Этот документ включает эскизы экранов с пояснениями, достаточно детальными для того, чтобы программисты могли писать код, а также подробные раскадровки, иллюстрирующие поведение продукта в динамике. Может оказаться полезным создать еще и интерактивный прототип на основе технологии HTML или Flash – он дополнит документацию и более доходчиво проиллюстрирует некоторые нюансы взаимодействия. При этом следует помнить, что одних лишь прототипов обычно недостаточно, чтобы передать неявные шаблоны, принципы и обоснования решений, – а их жизненно необходимо передать программистам. Независимо от выбранного формата документации команда проектировщиков должна работать в тесном сотрудничестве с разработчиками вплоть до завершения реализации. Требуется бдительность, чтобы гарантировать, что результаты проектирования точно и без искажений превратятся в законченный продукт.

 

 

 

история развития радиорекламы

One thought on “Алан Купер об интерфейсе. Краткий курс. 1 часть.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *