Interface prototyping (rus), Requirement management (rus)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

akiselev_screen

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

akiselev_screen_cooper

 

Advertisements
Standard

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

  1. Для лучшей ориентации по главам в конце книги есть перечень основных описанных принципов:
    Глава 1
    • Проектирование взаимодействия – не гадание на кофейной гуще.
    Глава 2
    • Пользовательский интерфейс должен следовать пользовательской ментальной модели, а не модели реализации.
    • Целеориентированное взаимодействие отражает пользовательские ментальные модели.
    • Пользователи не понимают булеву алгебру.
    • Не копируйте артефакты механической эры в пользовательских интерфейсах без учета возможностей информационной эры.
    • Существенные изменения должны приносить значительные улучшения.
    Глава 3
    • Никто не желает оставаться начинающим.
    • Оптимизируйте для середняков.
    • Считайте пользователей людьми очень умными, но очень занятыми.
    Глава 5
    • Не заставляйте пользователей чувствовать себя дураками.
    • При проектировании каждого интерфейса сосредотачивайтесь на единственном ключевом персонаже.
    Глава 6
    • Определите, что должен делать продукт, прежде чем проектировать, каким образом он это будет делать.
    • На ранних стадиях проектирования считайте интерфейс волшебным.
    Глава 7
    • Никогда не демонстрируйте вариант, который не нравится вам самим, потому что именно этот подход может понравиться заинтересованному лицу.
    • Пользовательский опыт целостен – форму и поведение продукта следует проектировать согласованно.
    Глава 9
    • Решения о выборе технической платформы следует соотносить с работой по проектированию взаимодействия.
    • Оптимизируйте монопольные приложения для работы на полном экране.
    • Интерфейс монопольного приложения должен придерживаться консервативного визуального стиля.
    • В монопольных приложениях следует применять обогащенные средства ввода.
    • Разворачивайте документы в монопольных приложениях на полный экран.
    • Временные приложения должны быть простыми, понятными, четкими.
    • Временное приложение следует ограничивать одним окном и одним представлением.
    • Временное приложение должно восстанавливать предыдущее положение и предыдущую конфигурацию.
    • Киоски следует оптимизировать в расчете на пользователей, не имеющих опыта работы с ними.
    Глава 10
    • Каким бы замечательным ни был ваш интерфейс, чем его меньше, тем лучше.
    • Хорошо оркестрованные пользовательские интерфейсы прозрачны.
    • Следуйте ментальным моделям пользователей.
    • Меньше – лучше.
    • Позволяйте пользователям управлять, не принуждайте их к диалогу.
    • Держите инструменты под рукой.
    • Обеспечивайте немодальную обратную связь.
    • Проектируйте наиболее вероятное, будьте готовы к возможному.
    • Представляйте информацию с учетом контекста.
    • Организуйте непосредственное манипулирование и графический ввод.
    • Отображайте состояния объектов и статус приложения.
    • Избегайте ненужных сообщений.
    • Не используйте диалоговые окна, чтобы сообщить, что все нормально.
    • Избегайте чистого листа.
    • Просите прощения, а не разрешения.
    • Отделяйте функции от их настройки.
    • Не задавайте вопросы – предоставляйте выбор.
    • Прячьте рычаги катапультирования.
    • Оптимизируйте скорость реакции; предупреждайте о задержках.
    Глава 11
    • Сокращайте налоговое бремя при любой возможности.
    • Не приваривайте дополнительные колеса к велосипеду намертво.
    • Не прерывайте работу из-за ерунды.
    • Не заставляйте пользователей просить разрешения.
    • Разрешайте ввод везде, где имеется вывод.
    • Адаптируйте интерфейс под типичную навигацию.
    • Пользователи готовы прикладывать усилия соразмерно результату.
    Глава 12
    • Компьютер работает, а человек думает.
    • Программный продукт должен вести себя как тактичный человек.
    • Следует запоминать все, что выбирает пользователь.
    Глава 13
    • Люди предпочитают добиваться успеха, а не всеведения.
    • Все идиомы необходимо изучать; хорошую идиому достаточно изучить только один раз.
    • Никогда не подгоняйте интерфейс под метафору.
    Глава 14
    • Основой визуального интерфейса являются визуальные шаблоны.
    • Элементы, различающиеся поведением, должны различаться и визуально.
    • Доносите до пользователей функцию и поведение визуально.
    • Удаляйте элементы, пока продукт не сломается, а затем верните последний удаленный элемент на место.
    • Графически представляйте тип объекта; текстом описывайте сам объект.
    • Придерживайтесь стандарта, если нет действительно стоящей альтернативы.
    • Единство оформления не подразумевает косности в решениях.
    Глава 17
    • Управление дисками и файлами не входит в список целей пользователей.
    • Сохраняйте документы и настройки автоматически.
    • Помещайте файлы туда, где пользователи смогут их найти.
    • Диски – технологический трюк, а не конструктивный элемент.
    Глава 18
    • В ошибках может и не быть вашей вины, но вы несете за них ответственность.
    • Выполняйте проверку, а не редактирование.
    Глава 19
    • Полноценная визуальная обратная связь – ключ к успешному
    непосредственному манипулированию.
    • В задачах, связанных с навигацией и выделением, обеспечивай’
    те поддержку как мыши, так и клавиатуры.
    • Используйте курсорные подсказки для отражения смысла слу’
    жебных клавиш.
    • Одиночный щелчок выбирает информационный объект либо из’
    меняет состояние элемента управления.
    • Двойной щелчок означает одинарный щелчок с последующим
    действием.
    • Если курсор находится над объектом или данными, событие
    «кнопка нажата» должно приводить к выделению этого объекта
    или данных.
    • Когда курсор находится над элементом управления, событие
    «кнопка нажата» означает подготовку к действию, событие
    «кнопка отпущена» приводит к выполнению действия.
    • Передавайте отзывчивость элементов интерфейса с помощью ви’
    зуальных подсказок.
    • Применяйте курсорные подсказки для передачи отзывчивости
    элементов интерфейса.
    • Выделение должно быть визуально отчетливым и недвусмыс’
    ленным.
    • Потенциальные цели должны визуально демонстрировать свою
    готовность принимать объекты.
    638 Приложение
    • Курсор при перетаскивании должен визуально ассоциироваться
    с объектом’источником.
    • Любая цель перетаскивания, до которой можно добраться про’
    круткой, должна быть доступна посредством автоматической
    прокрутки.
    • Компенсируйте дребезг перетаскивания.
    • Любая программа, в которой требуется точное выравнивание,
    должна предлагать пользователю верньер.
    Глава 20
    • Диалоговое окно – это еще одна комната; не ходите в комнату без
    веской причины.
    • Встраивайте функции в то окно, где они применяются.
    • Полезность любой идиомы взаимодействия зависит от контекста.
    Глава 21
    • Большое количество диалоговых окон, перегруженных элемен’
    тами управления, не гарантирует качество пользовательского
    интерфейса.
    • Используйте ссылки для навигации, а кнопки и кнопки’значки –
    для выполнения действий.
    • Выделяйте наиболее важные элементы списков с помощью пик’
    тограмм.
    • Ни в коем случае не используйте горизонтальную прокрутку
    текста.
    • Применяйте ограничивающие элементы управления для полу’
    чения ограниченных данных.
    • Чтобы отобразить информацию, недоступную для редактирова’
    ния, используйте элементы, предназначенные только для вывода.
    Глава 22
    • Используйте меню для обучения пользователей.
    • Блокируйте пункты меню всегда, когда их функции теряют
    смысл.
    • Используйте одинаковые пиктограммы для элементов управле’
    ния, решающих одни и те же задачи.
    Глава 23
    • Инструментальные панели обеспечивают возможность быстрого доступа к часто используемым функциям для опытных пользователей.
    • Предусматривайте всплывающие подсказки для всех элементов
    управления, расположенных на инструментальной панели или представленных пиктограммами.
    Глава 24
    • Реализуйте основное взаимодействие в основном окне.
    • Применение диалоговых окон оправдано для функций, не входящих в основной поток взаимодействия.
    • Диалоговые окна подходят для объединения элементов управления и информации, связанных с одним объектом предметной области или с одной функцией приложения.
    • Используйте глаголы в заголовках функциональных диалоговых окон.
    • Используйте названия объектов в заголовках диалоговых окон свойств.
    • Визуально выделяйте различия между модальными и немодальными диалоговыми окнами.
    • Используйте единообразные терминальные команды внутри немодальных диалоговых окон.
    • Не допускайте динамического изменения надписей на терминальных кнопках.
    • Информируйте пользователя о том, что приложение занято.
    • Никогда не используйте временные диалоговые окна для вывода
    сообщений об ошибках или сообщений, требующих подтверждения.
    • У всех идиом взаимодействия есть практические ограничения.
    • Не создавайте многострочные вкладки.
    Глава 25
    • Диалоги с сообщениями об ошибках прекращают работу из-за ерунды; их следует избегать.
    • Делайте так, чтобы ошибки были невозможны.
    • Программа унижает пользователей, когда сообщает, что они ошиблись.
    • Не расспрашивайте – действуйте.
    • Все действия должны быть обратимыми.
    • Помогайте пользователям избегать ошибок при помощи немодальной обратной связи.
    Глава 26
    • Предлагайте информацию о клавиатурных сокращениях в меню Справка.
    • Предложите пользователям коллекции шаблонов, готовых к применению.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s