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