Алан купер об интерфейсе краткое содержание

Обновлено: 08.07.2024

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

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

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

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

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

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

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

Like this:

3 thoughts on “ Алан Купер. Об интерфейсе ”

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

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Итак, после почти двухмесячного перерыва мы продолжаем нашу дискуссию.

Русскоязычную аудиторию я поздравляю с праздником Защитника Отечества.

За этот период я успел отметить свой день рождения. В честь этого Ozon.ru предложил мне свою акцию сделать заказ с 5% скидкой и бесплатной доставкой. Этим я и поспешил воспользоваться, чтобы заказать книги Алана Купера "Психбольница в руках пациентов" и "Об интерфейсах", которые уже давно хотел прочесть.

Итак, из первой книги мы узнали, что психбольница -- это мир, в котором всё большую роль начинает играть программное обеспечение, а пациенты -- это разработчики этого ПО. Именно от них в конечном счёте зависит насколько удобно нам будет пользоваться этими продуктами. Часто программисты пишут так как удобно им, и для людей таких как они. Из этого делается логичный вывод, что программисты ни в коем случае не должны заниматься проектированием взаимодействия. Проектировщики взаимодействия должны начать работу до написания кода. Разумеется, из любого правила есть исключения, следует помнить, что сам Алан Купер -- в прошлом программист. А потому я таки всё ещё верю, что моя попытка совместить в себе и программиста, и проектировщика для этого проекта может быть не безуспешной.

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

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

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

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

Тем не менее расскажу о наиболее интересных мыслях возникших по мере чтения. Во-первых, читая о системе отмен, я вдруг понял, что типичная операция удаления текста -- это тоже отмена, отмена ввода текста. Теоретически можно реализовать отмену, так чтобы BackSpace стал именно не просто удалением, а именно отменой в выделенном контексте. При этом с первым нажатием он может отменять в выделенном фрагменте форматирование текста, а уже вторым -- ввод различных фрагментов этого текста. Повтор же (скажем в виде клавиши Insert) будет строго отвечать за повторный ввод ранее удалённого текста и повторное его форматирование.

Такая идиома может при хорошей проработке стать отличным ходом в совершенствовании системы отмен.

Другая мысль, которую чётко изложил Алан Купер на страницах своей книги -- это положительная обратная связь в виде звукового сопровождения. Это означает, что озвучивать надо не отрицательные события ошибок, а обратно положительные события системы (успешное выполнения задания и т.д.). Алан Купер утверждает, что звуки в компьютерах обычно раздражают не потому, что они противны, а потому что они сопровождают всегда отрицательные события. Отрицательные же события должны сопровождаться тишиной. В действительности я и раньше задумывался о том, что в играх звуковое сопровождение во многом помогает управлению персонажами, в отличие от работы. В том числе голосовые подсказки вроде "Ваш форт атакован" или "Не достаточно денег" оказываются весьма полезными. Но почему в рабочем окружении всё оказывается не так радужно я не понимал.

В тоже время Джеф Раскин где-то писал, что полосы прокрутки являются явно не интуитивной составляющей интерфейса. Я бы, конечно, не поверил Джефу, если бы сам не видел как человек далёкий от компьютеров, имея в виду, что документ нужно пролистать ниже (дальше), показывал руками вверх (имея ввиду движение именно документа, а не "камеры"). Алан Купер же считает это хорошей идиомой современных интерфейсов, хотя и не рекомендует использовать горизонтальную прокрутку для текстовых данных.

Джеф Раскин описывает Zoom-интерфейс как прекрасную идиому взаимодействия. Алан Купер говорит, что Zoom обычно понятен только IT-специалистам, а логический Zoom вовсе понятен только разработчикам.

Джеф Раскин пишет о том, что сама идея приложений не очень хороша, и что пользователю нужна большая интеграция, а Алан Купер -- ни о чём подобном нигде не упоминает.

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

Возвращаясь к Blender 3D, скажу, что прочитав книги Алана Купера, я вдруг понял, что его мощный интерфейс, в котором невозможно разобраться без подробной документации, является следствием плохого (отсутствующего) проектирования. По сути во многом это просто нагромождение функций. Впрочем нельзя также забывать, что изначально он проектировался для использования в узком кругу дизайнеров, для которых он был профессиональным инструментом. Изначально в нём многие функции вообще были доступны только горячими клавишами. Конечно, это частично оправдывает такой дизайн, тем не менее нельзя забывать, что улучшая свой продукт для среднего пользователя вы во многом делаете лучше и профессионалу.

На изображениях статьи вы можете видеть всю мощь процедурных текстур: это морской пейзаж, горный ночной пейзаж, ковёр. Апофеозом этих возможностей является модель глаза. Она примечательна не только тем, что полностью состоит из процедурных текстур, но также обладает эффектом красного глаза, когда источник света светит в зрачок прямо. Вены на глазу видны только с краёв, даже если мы попытаемся посмотреть на него сбоку. Наконец легко сделать так, чтобы расширение зрачка регулировалось одним единственным числом (от 0,0 для максимально расширенного зрачка до 1,0 для максимально суженного). На рисунках вы можете видеть кошачий глаз с расширением 0,44 и 1,0.

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

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

Уроки и туториалы запись закреплена

Алан Купер
Об интерфейсе. Основы проектирования взаимодействия (2009)

Когда в 1995 году увидело свет первое издание "About Face", идея проектировать продукты исходя из целей людей казалась революционной. Благодаря работам Алана Купера и других первопроходцев, проектирование взаимодействия получило сегодня широкое признание как уникальная и крайне важная дисциплина, однако эта работа далека от завершения. Авторы полностью обновленного издания, признанные мировые эксперты в вопросах создания интерфейсов, детально описывают разработанный в компании Cooper и примененный во множестве проектов целостный подход к проектированию взаимодействия, ориентированный на цели пользователя. Отличительной чертой книги является ее практическая направленность - значительную часть издания занимает подробный разбор принципов и шаблонов проектирования взаимодействия. Большое внимание уделено новым информационным средам: веб-приложениям, мобильным приложениям, киоскам и т. п.

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

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

Прочитав книгу от корки до корки я полностью солидарен с Алексом Фольмером (разработчиком ПО), автором цитаты: "В области проектирования пользовательских интерфейсов книга Купера - один из тех основополагающих трудов, чтение которых - что-то вроде обряда посвящения." Книга невероятно раскрыла мне глаза на проблемы современных интерфейсов операционных. Читать полностью

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

Очень информативная книга. Бесспорно, не так увлекательно читается, как "Психбольница в руках пациентов" (что вполне извинительно ввиду гораздо большего объёма), но может служить очень грамотным и полным источником при разработке и анализе интерфейсов. Из разряда "Надо прочесть". Если хочешь чему-то научиться, конечно. Но "Психбольницу. " лучше. Читать полностью

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

Библия. Просто библия для юзабилиста и любого, кто пишет программы. Must read. Потому что программа с полезнейшим функционалом, но неудобная в использовании - ничто.

Читайте также:

Алан купер об интерфейсе краткое содержание

Share this:

Like this:

3 thoughts on “ Алан Купер. Об интерфейсе ”

Leave a Reply Cancel reply

Уроки и туториалы запись закреплена