Алан Купер. Об интерфейсе

Прочитал книгу Алана Купера, Роберта Реймана, Дэвида Кронина “Об интерфейсе. Основы проектирования взаимодействия”. Сразу скажу, что читал я её очень-очень тяжело: много очевидных для меня вещей и воды.

Первое, что надо бы запомнить слово в слово: качественное проектирование требуется для того, чтобы пользователи работали более эффективно. Приемы в начале проекта при проектировании всем хорошо знакомы, ибо этот процесс идентичен процессу выявления требований, однако я нашел любопытное расширение. Алан  Купер называет его «Целеориентированным проектированием» и оно позволяет более точно понять назначение продукта и его свойства, поведение и т.п.:

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

В дополнение, в другом разделе книги приведен следующий список вопросов целеориентированного проектирования:

• Цели: что делает ваш день хорошим? а плохим?
• Возможности: какие виды деятельности сейчас отнимают у вас
• время?
• Приоритеты: что для вас наиболее важно?
• Информация: что помогает вам принимать решения?
• Другой полезный тип вопросов – системоориентированные вопросы:
• Функция: что вы чаще всего делаете при помощи этого продукта?
• Частота: какими модулями продукта вы пользуетесь чаще всего?
• Предпочтения: какие стороны этого продукта вам особенно полюбились? Что вызывает восхищение?
• Отказы системы: как вы справляетесь с проблемами в функционировании системы?
• Профессиональность: какие приемы вы используете для ускорения работы?
• Для бизнес продуктов могут быть полезны вопросы, ориентированные на рабочий процесс:
• Процесс: что вы сделали сегодня на работе первым делом? А что после этого?
• Повторяющиеся действия и их регулярность: как часто вы это делаете? Что вы делаете еженедельно и каждый месяц, но не каждый день?
• Исключения: каков типичный рабочий день? Что стало бы необычным событием?
• Чтобы лучше понять мотивацию пользователей, можно применять вопросы, ориентированные на мировоззрение и отношение к окружающему:
  • Устремления: чем бы вы хотели заниматься через пять лет?
  • Избегание: что вы предпочли бы не делать? что откладываете?
  • Мотивация: что вам больше всего нравится в вашей работе (или жизни)? какие вопросы вы всегда решаете в первую очередь?

 Вот аспекты продукта, для оценки которых юзабилити тестирование особенно эффективно:

• Наименование. Осмысленны ли названия разделов и надписи на кнопках? Возможно, какие-то из этих слов воспринимаются легче, чем другие?
•  Архитектура. Осмысленно ли информация разбита на категории? Расположены ли информационные элементы в тех местах, где их ожидают найти потребители?
• Первое знакомство и доступность. Легко ли новые пользователи находят базовые элементы интерфейса? Понятны ли инструкции? Есть ли в них необходимость?
• Эффективность. Могут ли потребители эффективно решать конкретные задачи? Ошибаются ли они? При выполнении каких шагов? Как часто?

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

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

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

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

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

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

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

Важные рекомендации при проектировании и демонстрации результата:

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

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

1. Следуйте ментальным моделям пользователей.
2. Меньше – лучше.
3. Позволяйте пользователям управлять, не принуждайте их к диалогу.
4. Держите инструменты под рукой.
5. Обеспечивайте немодальную обратную связь.
6. Проектируйте наиболее вероятное, будьте готовы к возможному.
7. Предоставляйте информацию о контексте.
8. Организуйте непосредственное манипулирование и графический ввод.
9. Отображайте состояния объектов и статус приложения.
10. Избегайте ненужных сообщений.
11. Не используйте диалоговые окна, чтобы сообщить, что все нормально.
12. Избегайте чистого листа.
13. Просите прощения, а не разрешения.
14. Отделяйте функции от их настройки.
15. Не задавайте вопросы – предоставляйте выбор.
16. Прячьте рычаги катапультирования.
17. Оптимизируйте скорость реакции; предупреждайте о задержках.
18. Скрывайте кнопки, нажатие на которые ведет к серьезным последствиям.

Типичные ошибки, заложенные в поведение интерфейса, а так же ряд рекомендаций:

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

И пример рекомендованного сообщения об ошибке:

 

Психбольница в руках пациентов

Начал читать эту книгу, сначала плевался.. Плевался до 71-й станицы, потом у меня открылись глаза, это потрясающе..

Я сейчас разрабатываю Систему1, опирающуюся на уже реализованную Систему2. Чтобы понять Систему2 я ломал мозг дня 2, если не больше, и то не без посторонней помощи.. ТЗ на систему 1 надо завершить к концу января. Я прямо напарываюсь на то, о чём пишет Алан Купер: Если срок сдачи объекта – первое июня (я: считай, февраля), то наступление июня не всегда означает, что здание готово. А следовательно: Уже первое июня (я: февраля), следовательно, продукт готов. «В тираж» – говорят они, и срок сдачи становится единственным признаком завершенности проекта.

Причём, о том, чтобы пользователь смог работать с системой без обучения, чтения документации, и, очевидно, ощущения, что он “идиот”, я как-то не задумывался. Я всегда считал, что документация снимет все вопросы и недопонимания, который возникли из-за того, что у меня не хватило времени/ума/желания на проработку всего и вся и я реализовал процесс вот так. Да к тому же есть обучение и служба поддержки. Кстати, следует добавить, что зачастую существующая архитектура просто бы треснула при реализации интуитивно понятного интерфейса общения пользователя с записями БД.

Итого, я прочитал 4 страницы (от 71-й), а мой взгляд на мир рухнул – я всегда гонялся за сроком (держа в голове бюджет), а не за тем, чтобы всё было в первую очередь сделано предельно понятно и очевидно..  Осталось теперь переосмыслить и понять как это засунуть в спринты и рекомендации скорее выкатить продукт, чтобы посмотреть, как на него отреагирует рынок.. То есть сейчас у меня в голове явное противоречие.

Ну да ладно, читаю далее и делюсь мыслями и цитатами:

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

Далее я уткнулся в техническую поддержку – я всегда считал это выгодной услугой, и чем система хуже и запутаннее, тем лучше эту услугу продавать.Если уж у нас эту запутанность купили.. Так же я знал, что существует другой мир, , где поддержку дарят своим клиентам. Я даже знаю представителя этого мира – Microsoft, тратящий на это 800 МЛН долларов в год. И что же я вижу: Спросите любого, кому пришлось поработать в службе технической поддержки любой компании, создающей приложения для настольных компьютеров, и этот человек скажет, что большая часть его времени и усилий уходит на разъяснение вопросов,связанных с файловой системой. Можно сказать, что мой мир рухнул полтора раза…

Ещё любопытный материал про прототипы приведен, но у меня прототипы всегда были лишь рисунками. Так что я не могу оценить всю трагичность ситуации, хотя я слышал про успешные продажи прототипов (сырых или подлатанных), видимо, есть и обратные ситуации. Ценность прототипа в знаниях, приобретенных в процесс е его создания, а совсем не в коде. Мудрый разработчик Фредерик Брукс говорит: «Планируйте выбросить одну версию». Так или иначе, вы ее выбросите, так почему не запланировать это событие ссамого начала?

Читая о прототипах я бы ещё следующее добавил – меньше кнопок! Нужно стремиться к простоте интерфейса.

Какие есть ещё проблемы у программ:

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

Ещё одна важная цитата, я думаю, большинство ей и так следует, но на всякий случай:

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

…

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

К описанному выше ещё следует добавить производительность, отказоустойчивоть и проч. Это я, кстати, уже на 120 стр. Читая дальше, я в очередной раз убедился, что крайне важно и необходимо четко понимать цель создания ПО.

Чтобы ещё мне хотелось бы скопипастить на будущее.. Вот этот часто встречаемый тезис: Знаменитый идеолог UNIX ЭрикРеймонд (Eric Raymond) говорит: «Хорошие программисты знают, что писать, великие -что надо использовать повторно».

Часть 4 я бы вообще рекомендовал прочитать, основное привожу:

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

Пользователь не должен терять связи с начальным меню (если есть меню видео …. игры), то при переходе на уровень глубже в видео пользователь теряет возможность выбора игр.. Кроме того, если выбирать видео, то надо иметь понимание – что это будут за фильмы, сколько их и тп. А если выбирать фильм, то иметь его описание. Как-то так..

Ещё полезно держать в голове: Цели – не то же самое, что задачи. Цель – это конечное состояние, тогда как задача -переходный процесс, необходимый для достижения цели. Очень важно различать задачи и цели, ведь их так легко спутать. Зачастую программисты ориентируются на задачи, а не на цели. Правда в моей реальности этим должен заниматься в первую очередь аналитик..

Очень любопытно было прочитать про вежливые программы, это на стр 208. Они, например, по умолчанию в результатах поиска выдают то, что я чаще всего выбирал по такому же запросу ранее и тп. Она должна всегда выводить полезную для принятия решения информацию, выводить вменяемые числа, а не сумму $0,00 или $8943702624,23. Или, если я 50 раз говорил, что действительно хочу печатать страницу, и ни разу не передумал, то, может хватит мне выводить это окно..

На странице 227 я снова встречаю горячо любимые  сценарии..  Они бывают повседневными (и самыми важными), обязательными, исключительных ситуаций. Так же мне встретился и словарь терминов. В конце я опять услышал совет использовать итеративный подход. Уже в который раз…

Ну и главное:  проектируйте взаимодействие пользователя и системы заранее – до программирования (пока этим занимаюсь я – аналитик)..

Отзыв о книге по проектированию интерфейсов

Итак, название книги – “Дизайн пользовательского интерфейса. Искусство мыть слона“, а её автор – Влад В. Головач.

Наиболее полезной информацией для меня было следующее:

• «Правило 7±2», гласящее, что раз емкость кратковременной памяти человека редко бывает большей девяти элементов, то есть делать меню большего размера неэффективно. Это правило я успешно забыл после окончания института..
• Определение Юзабилити —это показатель количества операторских ошибок,скорости взаимодействия с продуктом, скорости обучения навыкам взаимодействия и субъективной удовлетворенности определенных пользователей продукта, достигающих определенных целей/мотивов в определенной среде.
• Разрабатывать интерфейсы лучше мелкими итерациями. Лучше сначала создать ужасный интерфейс и его постепенно улучшать.
• Все интерфейсы плохие: всё недостаточно хорошее – плохое. Поскольку улучшить можно всё, всё – плохо.
• Необходимо удостовериться, что трудозатраты на улучшение интерфейса действительного того стоят.
• Необходимо учитывать категории будущих пользователей и их особенности (например, их уровень компьютерной грамотности)
• Существуют различные подходы к дизайну интерфейсов, например “Дизайн, ориентированный на пользователя”

Для создания хорошего интерфейса необходимо:

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

Вопросы эти приходят из перечисленных автором в книге концепций качества интерфейсов. Например, из концепции показателей Шнейдермана приходят первые три:

1 Можно ли ускорить взаимодействие пользователя с этим интерфейсом?

2 Где в этом интерфейсе места, которые могут продуцировать человеческие ошибки? Можно ли изменить эти фрагменты?

3 Что в этом интерфейсе не способствует обучению? Что пользователюнужно знать, чтобы успешно взаимодействовать с этим интерфейсом? Есть ли в этом перечне что-то, чего сам интерфейс не сообщает пользователю?

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

4 Известно ли мне о пользователях что-нибудь, что делает этот интерфейс плохим?

5 Удовлетворяет ли этот интерфейс все известные мне мотивы пользователей?

6 Совместим ли этот интерфейс со средой, в которой работают пользователи?

7 Если и по этим вопросам всё хорошо, переходим к проверке, как выполняются в интерфейсе задачи пользователей. Соответственно,этот вопрос звучит как «Есть ли задачи, которые неэффективно отрабатываются интерфейсом?». Как правило, достаточно проговорить вслух (а ещё лучше написать), как в этом интерфейсе пользователь выполняет все свои задачи (лучше всего писать о себе, а не о абстрактном пользователе, например «Из меню Документ я открываю окно настроек зета-преобразования, ввожу значение 40 в поле Количество человек, затем открываю…»). Как правило, такая проверка выявляет множество несоответствий или попросту пропущенных кусков. Если это произошло, возвращаемся к самому первому вопросу. Если нет, задаем себе последний вопрос:

8 Сексуален ли этот интерфейс и можно ли его сделать ещё сексуальнее? Как видите, вопросов всего восемь и в них нет ничего особо страшного. Есть только одна хитрость: у любого продукта много функций и,соответственно, цельных «кусков» интерфейса.

Итого:

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

Выступление на WUD 2010

Могу сразу отметить, что я в это время сидел в офисе, а Денис Бесков проводил презентацию под названием “Компании, проектирующие  интерфейсы на заказ. Обзор рынка”.
Если бы не новая работа, то выступал бы я…

Видео

Презентация 

Обзор рынка проектирования интерфейсов 2010 from Denis Beskov

Отзывы

Например, здесь или здесь.