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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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