Чек-лист по проектированию опыта взаимодействия с пользователем

Перевод подробного чек-листа Энтони Хобдэя, который поможет создать качественный интерфейс. Автор включил в него 15 крупных направлений веб-дизайна: контекст, UX-копирайтинг, коммуникацию с пользователем, навигацию, последовательность, элементы интерфейса, мобильный дизайн и многое другое

Далее текст от лица автора

Как люди взаимодействуют

• Когнитивная нагрузка (насколько сильно программа заставляет пользователя думать?)
• Краткосрочная память (люди могут запомнить некоторую краткосрочную информацию, если им это необходимо)
• Пространственная память (пользователи могут запоминать элементы в зависимости от их расположения)
• Распределение (людям легче обрабатывать и запоминать информацию, представленную фрагментарно)
• Распознавание vs воспоминание
• Как люди воспринимают происходящее
• Пользователи не читают (лучше предположить, что они не читают весь текст, представленный в цифровом формате)
• Распределение внимания (конкретная область, на которую человек обращает внимание в данный момент)
• Управление вниманием (например, применение выравнивания, свободного пространства, чтобы обратить внимание пользователя на конкретную область)
• Боковое зрение (люди чётко видят только определённый объект, на который смотрят)
• Ложная слепота (они могут не увидеть элемент по невнимательности)
• Движение привлекает внимание (особенно хорошо люди замечают движение боковым зрением)
• Цвет акцентирует на себе внимание
• Сложность/детализация обращают на себя внимание
• Считывание шаблонов
• Сканирование
• Поиск и принятие удовлетворительного варианта (мы находим что-то, что кажется нам достаточно хорошим, и пробуем это)
• Информационный запах (люди склонны выбирать варианты/действия, которые по их мнению в большей степени связаны с их задачей)
• Поиск информации (они продолжают поиск только тогда, когда им кажется, что выгода перевешивает трудозатраты)
• Принципы гештальта
• Ментальные модели (как пользователь представляет себе процесс, даже если он не понимает, как всё происходит)
• Закон Хика (время принятия решения увеличивается с ростом количества предложенных вариантов)
• Перегрузка выбором (большее количество вариантов заставляет человека прилагать больше когнитивных усилий, необходимых для того, чтобы сделать выбор)
• Доступность (прочитайте про WCAG)
• Предварительная обработка (люди бессознательно воспринимают информацию о том, что их окружает, до того, как сознательно обратят внимание на окружающую их среду)
• Убеждающий дизайн (применение принципов психологии для того, чтобы побудить пользователей действовать определенным образом. Например, дефицит, неприятие потери)
• Закон Миллера (в краткосрочной памяти люди могут одновременно удерживать от 3 до 7 предметов)
• Эффект эстетики и удобства использования (люди считают, что более красивые интерфейсы легче в использовании)
• Привычки (интерфейсы должны поощрять формирование привычек и не мешать им)
• Состояние потока (люди могут входить в состояние усиленной концентрации, и дизайн может им в этом помочь)
• Баннерная слепота (пользователю может быть неинтересен определённый тип контента, например, реклама. Даже если элементы интерфейса на самом деле не являются нежелательным контентом, а просто похожи на него, человек их проигнорирует)
• Направление отображения прогресса и времени (зависит в разных культур. Например, на Западе вперёд = вправо)
• Чтобы побудить пользователей к нужному взаимодействию, сделайте правильные вещи лёгкими для выполнение, а неправильные — трудными
• Если вы хотите, чтобы человек делал что-то в вашем цифровом продукте, сделайте важные вещи приятными
• Хорошая осведомлённость vs новизна, чтобы привлечь внимание (человек с меньшей вероятностью обратит внимание на что-то новое)
• Приемлемая задержка (100 мс — это время задержки, при которой человек её замечает)

Контекст

• Руководящие принципы/инструкции/правила платформы
• Закон Якоба («пользователи проводят большую часть времени на других сайтах. Это означает, что они предпочитают, чтобы ваш сайт работал так же, как и все остальные, с которыми они уже знакомы»)
• Внешняя согласованность (вещи должны функционировать так же, как в примерах, увиденных ими вне дизайна)
• Внутренняя согласованность (вещи, которые выглядят одинаково, должны функционировать одинаково)
• Контекст устройства (например, электронные информационные стенды, мобильные телефоны, 3-метровый интерфейс, веб-браузер, нативное приложение, виртуальная реальность, дополненная реальность)
• Количество устройств vs креативность (если мы будем делать дизайн для меньшего количества устройств, то он будет более индивидуальным/креативным)
• Типы интерфейсов (например, текстовый, графический, осязаемый)
• Ситуация, в которой пользователь взаимодействует с интерфейсом (например, ожидание автобуса, ребёнок на руках, спуск с горы на лыжах)
• Изменение интерфейса с учётом ввода новых параметров (например, если пользователь подключает мышь к устройству с сенсорным экраном, интерфейс может измениться, чтобы учитывать наличие мыши)
• Взаимодействия, которые соответствуют контексту (например, меню операционной системы, элементы управления браузером)
• Интеграция (как ПО интегрируется с другими программами, включая системное ПО, и обеспечивает взаимодействие с ними)
• Предварительные знания (насколько хорошо пользователь знает, как взаимодействовать с ПО?)
• Качество соединения (скорость и надежность интернет-соединения пользователя влияют на его опыт взаимодействия. Дизайнер может кое-что сделать, чтобы повлиять на этот аспект)
• Контекстные возможности (сделайте конкретные элементы интерфейса доступными в определенных контекстах. Например, отображайте инструменты для работы с изображениями, когда пользователь с ними взаимодействует)
• Метафора (интерфейс может опираться на знакомые пользователю метафоры)
• Идиоматический дизайн (установите или используйте существующие идиомы из мира взаимодействия и визуального дизайна)
• Понимание «реального мира» (можете ли вы использовать реальный опыт из жизни, который существует за пределами ПО?)

Дизайн клавиатуры и курсора

• Наведение (перемещение курсора по области интерфейса без нажатия)
• Раскрытие при наведении (показ действий в рамках области, когда пользователь наводит на неё курсор)
• Всплывающие подсказки (появляющийся текст, который предоставляет дополнительные сведения об элементе)
• Доступные методы взаимодействия (например, какие кнопки есть на мыши)
• Горячие клавиши (включая сочетания клавиш)
• Взаимодействие только посредством клавиатуры
• Широкие области движения курсора (например, не нужно сразу же скрывать меню, если пользователь случайно вывел курсор за его пределы)
• Контекстное меню (меню, в котором пункты меняются в зависимости от того, где открыто меню)
• Бесконечные углы/края (если разместить элементы управления у истинного края экрана, ими будет легче пользоваться с помощью мыши, поскольку курсор не сможет переместиться за их пределы)
• Курсоры (вы можете изменить изображение курсора, чтобы дать пользователю больше информации о возможных взаимодействиях)

Мобильный дизайн/дизайн для сенсорных устройств

• Доступные жесты/действия касанием
• Расположение элементов управления рядом с большими пальцами
• Ориентация
• Досягаемость большого пальца
• Размер цели касания
• Прямое манипулирование
• Манипулирование только одной рукой
• Клавиатуры, соответствующие вводу (например, при вводе номера телефона появляется числовая клавиатура для ввода цифр)
• Привычные модели касания (например, щёпоть для увеличения)

Навигация

• Последовательность экранов / архитектура приложения
• Просмотр и поиск
• Информационная архитектура (порядок представления информации пользователю. Это огромная тема)
• Люди могут заходить на сайт из поисковой системы
• Двери-ловушки (Trap doors)
• Ориентиры (подсказки, чтобы пользователь понимал, где он находится)
• Иерархическая навигация (многие навигационные структуры ПО — иерархические, и навигационное взаимодействие должно отражать это)
• Вложенная навигация (структура меню в виде иерархии)
• Широта vs глубина (меню может показывать множество вариантов при более плоской иерархии или небольшое количество вариантов в формате глубокой иерархии)
• Навигационные модели (например, «центрально-лучевая»)
• Подсказывайте пользователю, куда он идёт (элементы навигации должны предоставлять человеку достаточное количество информации о том, куда он попадёт, если будет взаимодействовать с ними)
• Прокрутка и плавное смещение (в случае, если невозможно показать весь контент в видимой части страницы)

Композиция

• На Западе время идёт слева направо
• Близость
• Плотность информации (количество информации, отображаемой в заданном пространстве)
• Пространственная осведомлённость (например, кнопка с указателем «направо» при нажатии приведёт пользователя направо)
• Пространственно связанные области (например, панель свойств не должна быть выше или короче содержимого, на которое она влияет)
• Вайфреймы
• Визуальный вес (контраст и размер)
• Teasing continuation — визуальные подсказки, которые позволяют предположить, что на странице представлено больше контента или информации за пределами того, что отображается в данный момент
• Влияние иерархии (элементы управления, влияющие на большие области приложения, должны быть расположены дальше к краям)
• Пары «поле-значение» (данные часто находятся в паре «название поля/значение поля»)
• Отзывчивый дизайн (как композиция реагирует на разные размеры экрана?)
• Паттерны в композиции (существуют общие решения проблем при размещении отдельных элементов)
• Смещение контента (плохо, если контент «прыгает», например, из-за загрузки, в то время как пользователь пытается с ним взаимодействовать)
• Управление окнами (располагайте различные самодостаточные области интерактивности, такие как окна, по-разному)
• Скелетные загрузочные экраны (абстрактные формы, которые показывают макет экрана, пока он полностью не загрузится)

Последовательность задач

• Удаление (удалите шаги, которые пользователь не должен выполнять)
• Прогрессивное раскрытие (показывайте все поэтапно, а не сразу)
• Соответствие основного действия заявленной цели (язык, используемый в основном/предпочтительном действии, должен соответствовать заявленной цели, то есть, название элемента должно соответствовать его функции)
• Запасные выходы (всегда предоставляйте пользователю возможность отказаться от выполнения задачи)
• Следующие шаги (полезно предусмотреть действие, которое человек предпримет в дальнейшем, даже если он завершил задачу)
• Сохранение прогресса (если пользователю нужно отвлечься от задачи, он должен иметь возможность вернуться в ту же точку, из которой вышел)
• Циклы команд (сделайте шаги между многократно используемыми элементами управления максимально простыми)
• Поощрение концентрации внимания, когда это уместно (используйте такие понятия, как модальность, чтобы побудить пользователя сосредоточиться на конкретной задаче до её завершения)
• Условные элементы (показывайте отдельные элементы пользователю только тогда, когда они уместны)

Элементы интерфейса

• Представление состояния элемента vs действие над элементами управления
• Лучшие практики для каждого элемента интерфейса
• Закон Фиттса (чем больше элемент по размеру и ближе расположен, тем легче на него нажать)
• Функциональная простота vs кажущаяся простота (работает просто vs выглядит просто. Часто эти понятия противоречат друг другу)
• Способы придать элементам отличительные черты (форма, цвет, размер и яркость)
• Скевоморфизм
• Обозначение (подсказки интерфейса, которые говорят пользователю, что он может выполнить какое-либо действие)
• Ложное обозначение (визуальные подсказки, которые оказываются неверными)
• Общие признаки взаимодействия (например, цвет, форма)
• Иконки vs названия (иконки выглядят более аккуратными и помогают распознаванию, но пользователь легче воспринимает текст, чем иконки)
• Что могут отображать символы/обозначения (ощущение, объект, действие, концепцию)
• Располагайте элементы управления рядом с тем, на что они влияют
• Состояния элементов управления (элементы управления, такие как кнопки, могут иметь различные состояния. Функция состояний — информировать пользователя. Например, неактивное состояние, ошибка, состояние при наведении)
• Не добавляйте в интерфейс слишком много элементов. Это затруднит понимание дизайна пользователем
• Обозначение интерактивности — используйте визуальные способы для обозначения интерактивности

Формы

• Стиль поля для заполнения
• Отметка необязательных или обязательных полей для заполнения
• Заполнители/плейсхолдеры (текст внутри поля по умолчанию, чтобы пользователь понял, что именно нужно написать в поле)
• Названия полей, а не заполнители/плейсхолдеры (удобно использовать поля формы, если у них есть названия и они не зависят от заполнителей/плейсхолдеров)
• Выравнивание полей формы
• Состояния ошибок в полях (поля могут иметь связанные с ними сообщения об ошибках, если пользователь заполнил форму неправильно)
• Сообщения об ошибках под конкретным полем vs общие сообщения об ошибках (лучше показывать сообщение об ошибке рядом с полем)
• Лучшие практики для функции автозаполнения и дизайна полей для пароля
• Понимание того, какой элемент лучше выбрать в конкретном случае, если они похожи. Например, что лучше: радиокнопки и чекбоксы
• Проверка правильности данных (логика для проверки правильности заполнения поля или формы)

Коммуникация

• Цель (важно донести до пользователя цель приложения или экрана)
• Обратная связь (когда ПО показывает пользователю результат его действий)
• Типы обратной связи (функциональная: когда объект действует так, как должен. Дополненная: обратная связь, добавленная дизайнером для передачи информации. Неотъемлемая: обратная связь, которая естественным образом связана с выполняемым действием, например, движение клавиш клавиатуры)
• Избыточность обратной связи (в идеале для того, чтобы показать пользователю, что что-то изменилось, следует использовать несколько способов)
• Стили обратной связи «рассказать или показать» (вы можете либо рассказать пользователю о том, что происходит, либо показать)
• Предвосхищение (ПО должно сообщать пользователю о том, что произойдёт дальше)
• Предварительный просмотр изменений (в идеале человек в реальном времени может увидеть результат своих действий по мере того, как перебирает разные варианты)
• Цвета, которые выполняют функцию обозначения/указания (цвета, которым дизайнеры придают определённое значение)
• Ассоциативные цвета (цвета, которые вызывают в сознании пользователей конкретные ассоциации)
• Разговорный дизайн (создавайте интерфейс так, как будто это человек, который разговаривает с пользователем)
• Эмоциональный дизайн (разрабатывайте ПО таким образом, чтобы вызывать определённые эмоции у человека, который его использует)
• Контекстно-ориентированное общение (стиль общения должен соответствовать контексту, в котором люди будут использовать ПО)
• Уведомления (стиль общения с пользователем вне программы)
• Встроенные, обходные и блокирующие типы ошибок (встроенные: дают пользователям понять, что есть проблема. Обходные: дают пользователям понять, что им необходимо перейти в другое место, чтобы исправить ошибку. Блокирующие: программа не может помочь пользователю исправить ошибку)
• Селектор языка, а не страны (языки необязательно привязаны к странам, поэтому позвольте пользователю выбрать конкретный язык)
• «Мой» vs «ваш» интерфейс (интерфейс взаимодействует с позиции пользователя или интерфейса?)
• Пустые состояния (пустые экраны в любом случае должны коммуницировать с пользователем)
• Локализация (перевод интерфейса на другие языки/учёт особенностей культуры)
• Простая коммуникация (более простая коммуникация будет понятна большему количеству людей)
• Полезная анимация (анимация может помочь людям разобраться в том, как работает интерфейс)

Копирайтинг

• Хорошо написанные сообщения об ошибках (пользователь должен знать, что произошло и что он может с этим сделать)
• Конкретные действия (названия действий должны быть чёткими, чтобы пользователь понимал, что произойдёт)
• Микротекст (короткие части текста в интерфейсе, которые помогают пользователям с ним взаимодействовать.)
• Вспомогательный текст (короткий текст, который объясняет что-либо, например, поле формы ввода)
• Читабельность (хорошая типографика означает, что пользователь может прочитать слова в интерфейсе)
• Короткие названия действий для сканирования (короткие названия в списке действий помогают пользователю увидеть доступные варианты)
• Заголовки групп действий (вы можете использовать заголовок для группы действий, чтобы добавить больше контекста и написать более короткие названия для самих действий)
• Типы текста в интерфейсе (заголовки, названия кнопок и других интерактивных элементов, описания, пустые состояния, названия, элементы управления, поля ввода текста, переходный текст, сообщения о подтверждении, об ошибках, уведомления)
• Сокращение (сокращения в тексте помогают вёрстке, но делает его менее понятным)
• Голос и тон (голос в программе должен быть постоянным, но тон может меняться в зависимости от ситуации)

Первое впечатление

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

Прямое манипулирование

• Моделируемая физика взаимодействия (например, буксировка — для выполнения операций перемещения и копирования. Выбранный объект «буксируется» к новой позиции, например, можно «физически» двигать окно/пиктограмму по экрану или «отбуксировать» файл в корзину; или метод резиновой нити, когда чтобы изменить размер окна, пользователь двигает курсор перпендикулярно ребру окна и вызывает движение только этого ребра)
• Физическое качество (Если окна, буферы и другие элементы данных реагируют/поступают как «физические сущности», то для работы с ними «нужны физические действия», а не команды)
• Тактильная обратная связь (например, вибрация в телефоне)
• Анимационные кривые и другие свойства анимации (скорость и движение анимации подчиняются правилам. С их помощью мы можете сделать анимацию более естественной, например, добавить смягчение или затухание)
• Метафоры прокрутки (пользователь перемещает страницу через область просмотра или перемещает область просмотра вдоль страницы? Это влияет на ожидания направления прокрутки)
• Подсказки о пространственном взаимодействии (например, экран, который появляется снизу, подсказывает, что его можно убрать, перетащив обратно вниз)
• Постоянство/неизменность объекта (когда с помощью анимации, композиции и других дизайн-решений элементы не исчезают и не появляются как по волшебству, а ведут себя так, как будто они всегда находились на своих местах)

Концепции

• Время отклика (в идеале ПО должно реагировать как можно быстрее)
• Лёгкость обнаружения (насколько легко обнаружить элемент в интерфейсе)
• Скрытые, но полезные (многие взаимодействия полезны, но скрыты, и это правильно)
• Микровзаимодействия (короткие моменты взаимодействия в интерфейсе)
• Многозадачность (насколько хорошо ПО поддерживает человека, который выполняет несколько задач одновременно?)
• Где, что, как (где находятся пользователи, на что они смотрят, как они могут взаимодействовать)
• Эвристики (например, эвристики Nielsen Norman Group)
• Шаблоны взаимодействия (существуют общие приемлемые решения для конкретных проблем интерфейса)
• Акцент внимания на главных элементах, и снижение уровня внимания в отношении второстепенных элементов
• Поощрение типовых действия, а не редко встречающихся
• Встать на путь и уйти с пути (если вы хотите, чтобы человек что-то сделал, вы можете встать на его путь. Если он уже хочет это сделать, вам следует отойти в сторону)
• Доступность с учётом временных ограничений (например, человек со сломанной рукой может пользоваться только одной рукой)
• Последовательность в представлении
• Простота
• Закон сохранения сложности/закон Теслера (для любой системы существует определенное количество сложности, которое нельзя сократить; взаимодействие пользователей с приложениями так же важно, как и сами приложения. Во многих случаях дизайнеру следует потратить лишнюю неделю на упрощение приложения, а не заставлять людей тратить лишнюю минуту на использование сложной программы)
• Лучший выход из строя (если ПО выходит из строя, оно должно это делать наилучшим возможным способом)
• Модальность (что-то является модальным, если оно меняет режим работы ПО, когда оно активно, например, режим редактирования)
• Интуиция (насколько легко человеку разобраться в ПО при знакомстве с ним?)
• Возможности (возможности взаимодействия с программой, даже те, о которых пользователь может не знать)
• Позиция приложения (вы можете проектировать ПО по-разному в зависимости от того, является ли оно монопольным, временным, фоновым или паразитическим).
• Типы ПО (ваши подходы/методы/шаблоны проектирования будут меняться в зависимости от типа ПО, которое вы разрабатываете)
• Не полагайтесь на память пользователя (например, не просите его запоминать информацию на одном экране при переходе к другому)
• Кастомизация (люди могут менять интерфейс/информацию в соответствии со своими предпочтениями)
• Персонализация (приложение может автоматически меняться в соответствии с предпочтениями пользователя)
• Начинающие, среднестатистические и опытные пользователи (вы разработали интерфейс для всех трёх уровней взаимодействия?)
• Количество кликов vs уверенность (количество кликов, необходимое для того, чтобы выполнить задачу, не так важны, как уверенность пользователя в том, что он делает)
• Тёмные паттерны (некоторые дизайнеры используют неэтичные методы, чтобы побудить пользователя к действию)
• Геймификация (в приложениях дизайнеры могут применять игровые механики, чтобы стимулировать вовлечённость)
• Принцип надёжности (закон Постела) (согласно ему, данные, отправляемые вами другим, должны быть как можно меньшего размера и как можно лучше соответствовать стандарту. Однако вы сами можете принимать на вход не совсем стандартные данные, если у вас получится их обработать)
• Предотвращение vs отмена (вы можете спросить пользователя, уверен ли он в выполнении действия, или позвольте ему выполнить действие, а потом отменить его)
• Семиотика (наука о знаках, например, иконках)
• Ясность (текст, типографика, макет, цвета и многое другое помогают облегчить понимание дизайна)
• Гибкость vs удобство использования (чем гибче интерфейс, тем сложнее сделать его удобным)
• Расширение vs создание нового (расширяете ли вы существующую функцию или создаете новую?)
• Ускорители (например, сочетания клавиш или другие методы, которые люди могут использовать, чтобы ускорить выполнение задачи)
• Визуальная иерархия (визуально даёт понять, какие элементы более важные, а какие — менее)
• Колоритность (количество символов/цветов/анимации/эффектов в элементах интерфейса, которые реагируют на взаимодействие с пользователем)
• Визуальный вес (яркость, размер, сложность и другие факторы делают некоторые элементы такими, чтобы они привлекали к себе больше внимания)
• Четыре способа упростить (удалить, упорядочить, скрыть, вытеснить)
• Очевидное всегда побеждает (сделать взаимодействие очевидным — самый безопасный подход)
• Существительные и глаголы (как правило, интерфейс рассматривают, как набор вещей и действий)
• Прерываемые анимации (сделайте так, чтобы анимации изящно реагировали, если пользователь хочет прервать их каким-либо действием)
• Интуитивно понятный vs эффективный (некоторые программы более эффективны, но ими трудно научиться пользоваться)
• Необходимое трение (некоторые действия опасны, например, удаление, и добавление препятствий для их выполнения — хорошая вещь)
• Мелкие проблемы (множество мелких неудобств при взаимодействии с интерфейсом могут превратиться в большую проблему)
• Быстрое ПО (люди предпочитают, чтобы ПО было настолько быстрым, насколько это возможно)
• Восприятие скорости (даже если ПО медленное, вы можете сделать его быстрее с помощью дизайна)
• Продвижение (иногда полезно информировать пользователя о том, что может ему пригодиться, но о чём он не знает. Но это может его раздражать)
• Избыточность управления (пользователь может выполнять действия разными способами, например, с помощью сочетания клавиш, выбора иконки на панели инструментов и пункта меню)
• Раздутость (как правило, ПО называют раздутым, если оно содержит слишком много функций в небольшом когнитивном пространстве)
• Эффективность (насколько быстро человек может выполнить задачу)
• Действенность (насколько хорошо помогает выполненная задача)
• Похожесть функций (какие функции люди часто используют в связке?)
• Контент (вы можете сделать контент центром внимания, предоставив ему больше места в интерфейсе, а также если упростите интерфейс)
• Фактор увлекательности (действительно ли интерфейс настолько увлекателен, что пользователи захотят изучать его?)
• Прямое и косвенное управление (например, кнопка управляет чем-то ещё. Это означает, что вы можете сделать её более чёткой. Изменение размера изображения щипком — прямое, но менее понятное действие)
• Источники ввода (например, мышь, клавиатура, сенсорный экран, датчики движения, света)
• Личный, информационный, контекстный контент (в ситуациях, когда контент может меняться, вы можете выбирать его, отталкиваясь от этих категорий)
• Дизайн, ориентированный на разработку (дизайн интерфейса, отражающий то, как закодировано ПО. Как правило, это плохая идея)
• Правило койота (например, не наказывайте пользователя, если он слишком рано отпустил клавишу при нажатии сочетания клавиш (например Ctl+A))
• Единственная цель vs общее использование (ПО существует в спектре от «выполняет одно действие» до «является инструментом для выполнения многих действий»)
• Время переключения (проектирование взаимодействия — проектирование времени переключения в интерфейсе)
• Фокус приложения или элемента (приложение или элемент имеет фокус, если он готов принимать входящие данные)
• Масштабируемость (будет ли интерфейс продолжать работать, если контент/элементы внезапно удвоятся?)
• Случайное обучение (когда человек видит в интерфейсе что-то, что учит его взаимодействовать с интерфейсом)
• Обучаемость (интерфейс работает так, чтобы человек узнавал о нём больше по мере его использования? Например, демонстрация пустого состояния, где должны находиться некоторые данные, вместо скрытия этой области)
• Составление схем (отношения и связи между одним набором элементов и другим, например, взаимодействие выключателей света со светильниками в комнате)
• Бескомпромиссное ПО (ПО, которое использует один способ выполнения работы, основанный на убеждении создателя, что этот способ — лучший)
• Вовлечённость (насколько интерфейс вовлекает пользователя?)
• Промахи и ошибки (промах — правильное намерение, но неправильное действие. Ошибка — неправильное намерение)
• Намерения vs сопровождение (чем больше намерений у пользователя, тем меньше он нуждается в помощи при возникновении потенциальных проблем)
• Аспекты обратной связи — реакции элементов интерфейса на действия пользователя (время, расположение, направление, динамика (состояние, скорость, ускорение, сила), модальность (сенсорный), соответствие использованию человеком). Их можно разделить в ПО)
• Переломный момент удобства (даже небольшое количество дополнительных удобств может сделать ПО полезным)

Методы дизайна взаимодействий

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