Текст ошибки должен соответствовать известному состоянию системы и безопасному следующему действию. Вежливость не исправляет неизвестный статус заявки.
Состояние заявки за сообщением
Фраза "Ошибка 500" описывает техническую категорию, но не объясняет, принята ли заявка. Я сначала выясняю реальное состояние системы: запрос не дошёл, результат неизвестен или запись точно создана. Текст должен соответствовать этому состоянию.
Если статус неизвестен, нельзя уверенно писать "попробуйте снова" без оценки риска дубля. Иногда нужен безопасный повтор или проверка состояния. Исправление текста не заменяет надёжную серверную логику.
Три ошибки требуют разных ответов
Ниже учебные формулировки. Перед применением разработчик должен подтвердить состояние, сохранение данных и доступное действие. Обещание в тексте нельзя сделать точнее, чем знание системы.
- Неверный формат поля. Вместо "Некорректный ввод" - "Введите адрес в формате name@example.ru". Сообщение связано с полем; остальные введённые данные сохраняются, если это допустимо.
- Запрос точно не отправлен. Если приложение надёжно знает это состояние, можно написать: "Не удалось отправить заявку. Проверьте подключение и повторите отправку". Если введённое сохранено, сообщите об этом только после проверки.
- Ответ не получен, статус неизвестен. "Подтверждение ещё не получено. Проверяем статус заявки" подходит только при работающей проверке статуса. Если её нет, нужен предусмотренный продуктом путь помощи; безусловный повтор может создать дубль.
Для каждого состояния выпишите доступные переходы: исправить поле, повторить безопасный запрос, дождаться проверки или обратиться за помощью. Уточните, можно ли закрыть экран и вернуться. Нельзя одновременно советовать ждать и делать ту же отправку ещё раз, если система не защищает от повторов.
После редакторской правки проверьте ошибки на реальном узком экране, с клавиатуры и с вспомогательными технологиями. Полезность сообщения определяется тем, может ли человек понять состояние и восстановить путь. Вежливый тон помогает, но не заменяет этого действия.
Действие для восстановления
В рекомендациях Nielsen Norman Group сообщения об ошибках рассматриваются через ясность и помощь пользователю. Я предлагаю проверять три вещи: что не получилось, что уже сохранено и какое действие доступно. Например, для неверного формата email полезнее показать ожидаемый формат рядом с полем.
Не обвиняю человека формулировкой "вы неправильно заполнили". Объясняю требование: "Введите адрес в формате name@example.ru". Не раскрываю внутренние подробности и чувствительные сведения, которые не нужны для исправления.
Введённые данные и доступность
Если после ошибки исчезают заполненные поля, пользователь оплачивает технический сбой своим временем. Я проверяю, что можно сохранить безопасно и на какой срок. Для чувствительных данных требования могут быть иными; универсальное правило "сохранять всё" здесь не подходит.
Сообщение должно быть доступно рядом с проблемой и понятно без одного только красного цвета. Проверяю фокус, чтение с клавиатуры и связь сообщения с полем. Если помощь открывается отдельно, человек не должен терять исходный шаг.
Проверка восстановления
После изменения смотрю, можно ли исправить ввод и завершить задачу. Проверяю разные состояния: пустое поле, неверный формат, потеря сети, повторный запрос. Один красивый макет не показывает, что все эти переходы работают.
Если после ошибки человек не знает, как продолжить, рекомендую обратиться ко мне за консультацией и разбором продукта. Помогу описать состояния и план проверки восстановления.
Примечания и источники
- Nielsen Norman Group: рекомендации для сообщений об ошибках
- Nielsen Norman Group: ограничения подсказок внутри полей вместо постоянных подписей
Это практический разбор, а не обещание роста показателей. Применимость советов зависит от вашего сценария, аудитории и качества данных. Примеры в статье иллюстративные.