Несколько слов о сотрудничестве

Мы считаем, что целеориентированный метод состоит из четырех час' тей: процессы, шаблоны, принципы и практика. Эта книга посвящена в основном первым трем составляющим. В заключение мы хотели бы поделиться некоторыми мыслями относительно практики проектиро' вания взаимодействия.

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

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

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

 

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

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

Мы выделяем три важные группы, с которыми проектировщикам взаи' модействия следует наладить особенно интенсивное взаимодействие. Во'первых, это люди, которые принимают решения в деловой сфере и, как говорилось во введении, в конечном счете, отвечают за при' быльность и успех продукта; от них обычно зависит финансирование процесса проектирования. Важно работать в тесном контакте с этими людьми в момент запуска проекта, чтобы уяснить их видение продук' та и определить задачи этапа исследования пользовательской аудито' рии, а затем на этапах выработки требований и проектирования ин' фраструктуры (см. главы 6 и 7), чтобы выработать и закрепить согла' сованное видение продукта. Важно также вовлечь людей, принимаю' щих бизнес'решения, в обсуждения на этапе детализации, поскольку обсуждаемые варианты решений могут повлиять на бюджет и сроки разработки.

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

632 Послесловие: несколько слов о сотрудничестве

 

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

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

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

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

 

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

 

Приложение

Принципы проектирования

Глава 1

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

Глава 2

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

• Целеориентированное взаимодействие отражает пользователь' ские ментальные модели.

• Пользователи не понимают булеву алгебру.

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

• Существенные изменения должны приносить значительные улуч' шения.

Глава 3

• Никто не желает оставаться начинающим.

• Оптимизируйте для середняков.

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

Глава 5

• Не заставляйте пользователей чувствовать себя дураками.

• При проектировании каждого интерфейса сосредотачивайтесь на единственном ключевом персонаже.

Глава 6

• Определите, что должен делать продукт, прежде чем проектиро' вать, каким образом он это будет делать.

• На ранних стадиях проектирования считайте интерфейс вол' шебным.

 

Глава 7

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

• Пользовательский опыт целостен – форму и поведение продукта следует проектировать согласованно.

Глава 9

• Решения о выборе технической платформы следует соотносить с работой по проектированию взаимодействия.

• Оптимизируйте монопольные приложения для работы на пол' ном экране.

• Интерфейс монопольного приложения должен придерживаться консервативного визуального стиля.

• В монопольных приложениях следует применять обогащенные средства ввода.

• Разворачивайте документы в монопольных приложениях на пол' ный экран.

• Временные приложения должны быть простыми, понятными, четкими.

• Временное приложение следует ограничивать одним окном и од' ним представлением.

• Временное приложение должно восстанавливать предыдущее положение и предыдущую конфигурацию.

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

Глава 10

• Каким бы замечательным ни был ваш интерфейс, чем его мень' ше, тем лучше.

• Хорошо оркестрованные пользовательские интерфейсы про' зрачны.

• Следуйте ментальным моделям пользователей.

• Меньше – лучше.

• Позволяйте пользователям управлять, не принуждайте их к диа' логу.

• Держите инструменты под рукой.

• Обеспечивайте немодальную обратную связь.

• Проектируйте наиболее вероятное, будьте готовы к возможному.

• Представляйте информацию с учетом контекста.

• Организуйте непосредственное манипулирование и графический ввод.

 

• Отображайте состояния объектов и статус приложения.

• Избегайте ненужных сообщений.

• Не используйте диалоговые окна, чтобы сообщить, что все нор' мально.

• Избегайте чистого листа.

• Просите прощения, а не разрешения.

• Отделяйте функции от их настройки.

• Не задавайте вопросы – предоставляйте выбор.

• Прячьте рычаги катапультирования.

• Оптимизируйте скорость реакции; предупреждайте о задержках.

Глава 11

• Сокращайте налоговое бремя при любой возможности.

• Не приваривайте дополнительные колеса к велосипеду намертво.

• Не прерывайте работу из'за ерунды.

• Не заставляйте пользователей просить разрешения.

• Разрешайте ввод везде, где имеется вывод.

• Адаптируйте интерфейс под типичную навигацию.

• Пользователи готовы прикладывать усилия соразмерно резуль' тату.

Глава 12

• Компьютер работает, а человек думает.

• Программный продукт должен вести себя как тактичный чело' век.

• Следует запоминать все, что выбирает пользователь.

Глава 13

• Люди предпочитают добиваться успеха, а не всеведения.

• Все идиомы необходимо изучать; хорошую идиому достаточно изучить только один раз.

• Никогда не подгоняйте интерфейс под метафору.

Глава 14

• Основой визуального интерфейса являются визуальные шабло' ны.

• Элементы, различающиеся поведением, должны различаться и визуально.

• Доносите до пользователей функцию и поведение визуально.

• Удаляйте элементы, пока продукт не сломается, а затем верните последний удаленный элемент на место.

 

• Графически представляйте тип объекта; текстом описывайте сам объект.

• Придерживайтесь стандарта, если нет действительно стоящей альтернативы.

• Единство оформления не подразумевает косности в решениях.

Глава 17

• Управление дисками и файлами не входит в список целей поль' зователей.

• Сохраняйте документы и настройки автоматически.

• Помещайте файлы туда, где пользователи смогут их найти.

• Диски – технологический трюк, а не конструктивный элемент.

Глава 18

• В ошибках может и не быть вашей вины, но вы несете за них от' ветственность.

• Выполняйте проверку, а не редактирование.

Глава 19

• Полноценная визуальная обратная связь – ключ к успешному непосредственному манипулированию.

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

• Используйте курсорные подсказки для отражения смысла слу' жебных клавиш.

• Одиночный щелчок выбирает информационный объект либо из' меняет состояние элемента управления.

• Двойной щелчок означает одинарный щелчок с последующим действием.

• Если курсор находится над объектом или данными, событие

«кнопка нажата» должно приводить к выделению этого объекта или данных.

• Когда курсор находится над элементом управления, событие

«кнопка нажата» означает подготовку к действию, событие

«кнопка отпущена» приводит к выполнению действия.

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

• Применяйте курсорные подсказки для передачи отзывчивости элементов интерфейса.

• Выделение должно быть визуально отчетливым и недвусмыс' ленным.

• Потенциальные цели должны визуально демонстрировать свою готовность принимать объекты.

 

• Курсор при перетаскивании должен визуально ассоциироваться с объектом'источником.

• Любая цель перетаскивания, до которой можно добраться про' круткой, должна быть доступна посредством автоматической прокрутки.

• Компенсируйте дребезг перетаскивания.

• Любая программа, в которой требуется точное выравнивание, должна предлагать пользователю верньер.

Глава 20

• Диалоговое окно – это еще одна комната; не ходите в комнату без веской причины.

• Встраивайте функции в то окно, где они применяются.

• Полезность любой идиомы взаимодействия зависит от контекста.

Глава 21

• Большое количество диалоговых окон, перегруженных элемен' тами управления, не гарантирует качество пользовательского интерфейса.

• Используйте ссылки для навигации, а кнопки и кнопки'значки – для выполнения действий.

• Выделяйте наиболее важные элементы списков с помощью пик' тограмм.

• Ни в коем случае не используйте горизонтальную прокрутку текста.

• Применяйте ограничивающие элементы управления для полу' чения ограниченных данных.

• Чтобы отобразить информацию, недоступную для редактирова' ния, используйте элементы, предназначенные только для вывода.

Глава 22

• Используйте меню для обучения пользователей.

• Блокируйте пункты меню всегда, когда их функции теряют смысл.

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

Глава 23

• Инструментальные панели обеспечивают возможность быстрого доступа к часто используемым функциям для опытных пользо' вателей.

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

 

Глава 24

• Реализуйте основное взаимодействие в основном окне.

• Применение диалоговых окон оправдано для функций, не вхо' дящих в основной поток взаимодействия.

• Диалоговые окна подходят для объединения элементов управле' ния и информации, связанных с одним объектом предметной об' ласти или с одной функцией приложения.

• Используйте глаголы в заголовках функциональных диалого' вых окон.

• Используйте названия объектов в заголовках диалоговых окон свойств.

• Визуально выделяйте различия между модальными и немодаль' ными диалоговыми окнами.

• Используйте единообразные терминальные команды внутри не' модальных диалоговых окон.

• Не допускайте динамического изменения надписей на терми' нальных кнопках.

• Информируйте пользователя о том, что приложение занято.

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

• У всех идиом взаимодействия есть практические ограничения.

• Не создавайте многострочные вкладки.

Глава 25

• Диалоги с сообщениями об ошибках прекращают работу из'за ерунды; их следует избегать.

• Делайте так, чтобы ошибки были невозможны.

• Программа унижает пользователей, когда сообщает, что они ошиблись.

• Не расспрашивайте – действуйте.

• Все действия должны быть обратимыми.

• Помогайте пользователям избегать ошибок при помощи немо' дальной обратной связи.

Глава 26

• Предлагайте информацию о клавиатурных сокращениях в меню

Справка.

• Предложите пользователям коллекции шаблонов, готовых к при' менению.

 

Библиография

[Alexander, 1964] Alexander, Christopher. Notes on the Synthesis of Form.

Harvard University Press, 1964.

[Alexander, 1977] Alexander, Christopher. A Pattern Language. Oxford University Press, 1977.

[Alexander, 1979] Alexander, Christopher. The Timeless Way of Building.

Oxford University Press, 1979.

[Bertin, 1983] Bertin, Jacques. Semiology of Graphics. University of Wis' consin Press, 1983.

[Beyer and Holtzblatt, 1998] Beyer, Hugh, and Holtzblatt, Karen. Contextu- al Design. Morgan Kaufmann Publishers, 1998.

[Borchers, 2001] Borchers, Jan. A Pattern Approach to Interaction Design.

John Wiley and Sons, 2001.

[Borenstein, 1994] Borenstein, Nathaniel S. Programming As If People Mattered. Princeton University Press, 1994.

[Buxton, 1990] Buxton, Bill. «The ‘Natural’ Language of Interaction: A Perspective on Non'Verbal Dialogues.» Laurel, Brenda, ed. The Art of Human-Computer Interface Design. Addison'Wesley, 1990.

[Carroll, 1995] Carroll, John M. ed. Scenario-Based Design. John Wiley and Sons, 1995.

[Carroll, 2000] Carroll, John M. Making Use: Scenario-based Design of Hu- man-Computer Interactions. The MIT Press, 2000.

[Constantine and Lockwood, 1999] Constantine, Larry L., and Lockwood,

Lucy A. D. Software for Use. Addison'Wesley, 1999.1

[Constantine and Lockwood, 2002] Constantine, Larry L., and Lockwood, Lucy A. D. forUse Newsletter #26, October 2002.

[Cooper, 1999] Cooper, Alan. The Inmates Are Running the Asylum. SAMS/ Macmillan, 1999.2

1 Константайн Л., Локвуд Л. «Разработка программного обеспечения». – Пер. с англ. – СПб.: Питер, 2004.

2 Купер А. «Психбольница в руках пациентов. Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие», дополненное издание. – Пер. с англ. – СПб.: Символ'Плюс, 2009.

 

[Crampton and Tabor, 1996] Crampton Smith, Gillian, and Tabor, Philip.

«The Role of the Artist'Designer.» Winograd, Terry, ed. Bringing De- sign to Software. Addison'Wesley, 1996.

[Csikszentmihalyi, 1991] Csikszentmihalyi, Mihaly. Flow: The Psychology of Optimal Experience. HarperCollins, 1991.

[DeMarco and Lister, 1999] DeMarco, Tom, and Lister, Timothy R. People- ware. Dorset House, 1999.1

[Dillon, 2001] Dillon, Andrew. «Beyond Usability: Process, Outcome and Af' fect in Human Computer Interaction.» Paper presented at the Lazerow Lecture at the Faculty of Information Studies, University of Toronto, March 2001. Находится по адресу www.ischool.utexas.edu/~adillon/ publications/beyond_usability.html.

[Gamma, et al., 1995] Gamma, Erich, et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison'Wesley Professional, 1995.2

[Garrett, 2002] Garrett, Jesse James. The Elements of User Experience.

New Riders Press, 2002.3

[Gellerman, 1963] Gellerman, Saul W. Motivation and Productivity. Ama' com Press, 1963.

[Goodwin, 2001] Goodwin, Kim. «Perfecting Your Personas.» Cooper News- letter, July/August 2001.

[Goodwin, 2002] Goodwin, Kim. «Getting from Research to Personas: Har' nessing the Power of Data.» User Interface 7 West Conference, 2002.

[Goodwin, 2002a] Goodwin, Kim. Cooper U Interaction Design Practicum Notes. Cooper, 2002.

[Grudin and Pruitt, 2002] Grudin, J., and Pruitt, J. «Personas, Participatory Design and Product Development: An Infrastructure for Engagement.» PDC’02: Proceedings of the Participatory Design Conference, 2002.

[Heckel, 1994] Heckel, Paul. The Elements of Friendly Software Design.

Sybex, 1994.

[Horn, 1998] Horn, Robert E. Visual Language. Macro Vu Press, 1998.

[Horton, 1994] Horton, William. The Icon Book: Visual Symbols for Compu- ter Systems and Documentation. John Wiley & Sons, 1994.

 

1 Демарко Т., Листер Т. «Человеческий фактор: успешные проекты и коман' ды». – Пер. с англ. – СПб.: Символ'Плюс, 2005.

2 Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. «Приемы объектно'ориен' тированного проектирования. Паттерны проектирования». – Пер. с англ. – СПб.: Питер, 2001, 2007.

3 Гарретт Д. «Веб'дизайн: книга Джесса Гарретта. Элементы опыта взаимо' действия». – Пер. с англ. – СПб.: Символ'Плюс, 2008.

 

[Johnson, 2000] Johnson, Jeff. GUI Bloopers. Morgan Kaufman Publishers, 2000.

[Jones and Marsden, 2006] Jones, Matt, and Marsden, Gary. Mobile Inter- action Design. John Wiley & Sons, 2006.

[Kobara, 1991] Kobara, Shiz. Visual Design with OSF/Motif. Addison'Wes' ley, 1991.

[Korman, 2001] Korman, Jonathan. «Putting People Together to Create Go' od Products.» Cooper Newsletter, September 2001.

[Krug, 2000] Krug, Steve. Don’t Make Me Think! New Riders Press, 2000.1

[Kuniavsky, 2003] Kuniavsky, Mike. Observing the User Experience. Mor' gan Kaufmann Publishers, an Imprint of Elsevier, 2003.

[Kuutti, 1995] Kuutti, Kari. «Work Processes: Scenarios as a Preliminary Vocabulary.» Carroll, John M., ed. Scenario-based Design. John Wiley and Sons, Inc., 1995.

[Laurel, 1991] Laurel, Brenda. Computers as Theatre. Addison'Wesley, 1991.

[Lidwell, Holden, and Butler, 2003] Lidwell, William; Holden, Kritina; But' ler, Jill. Universal Principles of Design. Rockport Publishers, 2003.

[MacDonald, 2003] MacDonald, Nico. What Is Web Design? Rotovision 2003.

[McCloud, 1994] McCloud, Scott. Understanding Comics. Kitchen Sink Press, 1994.

[Mikkelson and Lee, 2000] Mikkelson, N., and Lee, W. O. «Incorporating us' er archetypes into scenario'based design.» Proceedings of UPA 2000 (2000).

[Miller, 1968] Miller, R. B. Response time in man'computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference, Vol. 33, 267–277 (1968).

[Mitchell and Shneiderman, 1989] Mitchell, J. and Shneiderman, B. Dyna' mic versus static menus: An exploratory comparison. SIGCHI Bulletin, Vol. 20 No. 4, 33–37 (1989).

[Moggridge, 2007] Moggridge, Bill. Designing Interactions. The MIT Press, 2007.

[Morville, 2005] Morville, Peter. Ambient Findability. O’Reilly Media, 2005.2

[Mulder and Yaar, 2006] Mulder, Steve, and Yaar, Ziv. The User Is Always Right. New Riders Press, 2006.

 

1 Круг С. «Веб'дизайн: книга Стива Круга. Не заставляйте меня думать!», 2'е издание. – Пер. с англ. – СПб.: Символ'Плюс, 2008.

2 Морвиль П. «Тотальная видимость. Как наши находки меняют нас». – Пер. с англ. – СПб.: Символ'Плюс, 2008.

 

[Mullet and Sano, 1995] Mullet, Kevin, and Sano, Darrell. Designing Visual Interfaces. Sunsoft Press, 1995.

[Nass and Reeves, 1996] Nass, Clifford, and Reeves, Byron. The Media Equa- tion: How People Treat Computers, Television, and New Media Like Real People and Places. Cambridge University Press, 1996.

[Nelson, 1990] Nelson, Theodor Holm. «The Right Way to Think about Soft' ware Design.» Laurel, Brenda, ed. The Art of Human-Computer Inter- face Design. Addison'Wesley, 1990.

[Newman and Lamming, 1995] Newman, William M., and Lamming, Michael

G. Interactive System Design. Addison'Wesley, 1995.

[Nielsen, 1993] Nielsen, Jakob. Usability Engineering. Academic Press, 1993.

[Nielsen, 2000] Nielsen, Jakob. Designing Web Usability. New Riders Press, 2000.1

[Nielsen, 2002] Nielsen, Jakob. UseIt.com (веб'сайт).

[Norman, 1989] Norman, Donald. The Design of Everyday Things. Curren' cy Doubleday, 1989.2

[Norman, 1994] Norman, Donald. Things That Make Us Smart. Perseus Publishing, 1994.

[Norman, 1998] Norman, Donald A. The Invisible Computer. The MIT Press, 1998.

[Norman, 2005] Norman, Donald. Emotional Design. Basic Books, 2005.

[Papanek, 1984] Papanek, Victor. Design for the Real World. Academy Chi' cago Publishers, 1984.3

[Perfetti and Landesman, 2001] Perfetti, Christine, and Landesman, Lori.

«The Truth About Download Times» UIE.com, 2001.

[Pinker, 1999] Pinker, Stephen. How the Mind Works. W. W. Norton & Company, 1999.

[Preece, Rogers, and Sharp, 2007] Preece, Jenny; Rogers, Yvonne and Sharp, Helen. Interaction Design. John Wiley & Sons, 2007.

[Raskin, 2000] Raskin, Jeff. The Humane Interface. Addison'Wesley Pro' fessional, 2000.4

1 Нильсен Я. «Веб'дизайн: книга Якоба Нильсена». – Пер. с англ. – СПб.: Символ'Плюс, 2000.

2 Норман Д. «Дизайн промышленных товаров». – Пер. с англ. – М.: Вильямс, 2008; Норман Д. «Дизайн привычных вещей». – Пер. с англ. – М.: Вильямс, 2006.

3 Папанек В. «Дизайн для реального мира». – Пер. с англ. – М.:Издатель Д. Аронов, 2004.

4 Раскин Д. «Интерфейс: новые направления в проектировании компьютер' ных систем». – Пер. с англ. – СПб.: Символ'Плюс, 2003.

 

[Reimann, 2001] Reimann, Robert M. «So You Want to Be an Interaction De' signer.» Cooper Newsletter, June 2001.

[Reimann, 2002] Reimann, Robert M. «Bridging the Gap from Research to Design.» Panel Presentation, IBM Make IT Easy Conference (2002).

[Reimann, 2002a] Reimann, Robert. «Perspectives: Learning Curves.» Rede- sign Magazine, Dec. 2002.

[Reimann, 2005] Reimann, Robert. «Personas, Scenarios, and Emotional De' sign». UXMatters.com (2005).

[Reimann and Forlizzi, 2001] Reimann, Robert M., and Forlizzi, Jodi. «Role: Interaction Designer.» Presentation to AIGA Experience Design 2001.

[Rheinfrank and Evenson, 1996] Rheinfrank, John, and Evenson, Shelley.

«Design Languages.» Winograd, Terry, ed. Bringing Design to Software.

Addison'Wesley, 1996.

[Rombaur and Becker, 1975] Rombaur, Irma S., and Becker, Marion Rom' baur. The Joy of Cooking. Scribner, 1975.

[Rosenfeld and Morville, 1998] Rosenfeld, Louis, and Morville, Peter. Infor- mation Architecture. O’Reilly, 1998.1

[Rudolf, 1998] Rudolf, Frank. «Model'Based User Interface Design: Succes' sive Transformations of a Task/Object Model.» Wood, Larry E., ed. User Interface Design: Bridging the Gap from User Requirements to Design. CRC Press, 1998.

[Saffer, 2006] Saffer, Dan. Designing for Interaction. Peachpit Press, 2006.

[Schо..n and Bennett, 1996] Schо..n, D., and Bennett, J. «Reflective Conversa' tion with Materials.» Winograd, Terry, ed. Bringing Design to Software. Addison'Wesley, 1996.

[Schumann, et al., 1996] Schumann, J., Strothotte, T., Raab, A., and Laser, S. Assessing the Effect of Non-Photorealistic Rendered Images in CAD. CHI 1996 Papers, pp. 35–41 (1996).

[Shneiderman, 1998] Shneiderman, Ben. Designing the User Interface.

Addison'Wesley, 1998.

[Simon, 1996] Simon, Herbert. The Sciences of the Artificial. The MIT Press, 1996.

[Snyder, 2003] Snyder, Carolyn. Paper Prototyping. Morgan Kaufmann Pub' lishers, an Imprint of Elsevier, 2003.

[SRI Consulting Business Intelligence, 2002] SRI Consulting Business Intel' ligence. «Welcome to VALS.» SRI'BC.com (2002).

 

 

1 Розенфельд Л., Морвиль П. «Информационная архитектура в Интернете», 2'е издание. – Пер. с англ. – СПб.: Символ'Плюс, 2005.

 

[Tidwell, 2006] Tidwell, Jennifer. Designing Interfaces. O’Reilly Media, 2006.1

[Tufte, 1983] Tufte, Edward. The Visual Display of Quantitative Informa- tion. Graphic Press, 1983.

[Van Duyne, Landay, and Hong, 2002] Van Duyne, Douglas K., Landay, Ja' mes A., Hong, Jason I. The Design of Sites. Addison'Wesley, 2002.

[Veen, 2000] Veen, Jeffrey. The Art and Science of Web Design. New Riders Press, 2000.

[Verplank, et al., 1993] Verplank, B., Fulton, J., Black, A., and Moggridge, B.

«Observation and Invention: Use of Scenarios in Interaction Design.» Tu' torial Notes, InterCHI’93, Amsterdam, 1993.

[Weiss, 2000] Weiss, Michael J. The Clustered World: How We Live, What We Buy, and What It All Means About Who We Are. Little Brown & Company, 2000.

[Winograd, 1996] Winograd, Terry, ed. Bringing Design to Software. Read' ing, MA: Addison'Wesley, 1996.

[Wirfs-Brock, 1993] Wirfs'Brock, Rebecca. «Designing Scenarios: Making the Case of a Use Case Framework.» SmallTalk Report, November/De' cember 1993.

[Wixon and Ramey, 1996] Wixon, Dennis, and Ramey, Judith, eds. Field Methods Casebook for Software Design. John Wiley and Sons, 1996.

[Wood, 1996] Wood, Larry E. «The Ethnographic Interview in User'Centered Task/Work Analysis.» (1996).