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