Сообщение об ошибке в клиентской инструкции: как объяснить состояние и доступное действие

Хорошее сообщение об ошибке помогает понять, какое действие не завершилось, что известно о данных и как продолжить. Для этого сначала проверьте поведение формы или инструмента, затем напишите текст для одного конкретного состояния. Ниже Вы соберёте карточку сообщения и проверите, можно ли по ней исправить ситуацию без догадок и опасного повторения операции.

Материал пригодится владельцу небольшого бизнеса, редактору клиентской памятки и специалисту, который согласует тексты интерфейса с разработчиком. Здесь рассматривается сообщение рядом с действием, например загрузкой файла. Подробный поиск причин по нескольким веткам разбирает диагностическая статья для клиента. Сообщение должно дать ближайшее продолжение, даже если вся причина сбоя пока неизвестна.

Выберите одно действие и наблюдаемое состояние

Начните с глагола пользователя: прикрепить файл, отправить запрос, сохранить запись. Затем определите, на каком шаге возникло препятствие. «Не удалось прикрепить файл» и «Не получено подтверждение отправки» описывают разные состояния. В первом случае можно проверять требования к вложению, во втором сначала потребуется выяснить, дошёл ли запрос. Одинаковая кнопка повторения для этих ситуаций может оказаться неверной.

Запишите короткий сценарий без редакторских украшений: человек выбрал файл, нажал кнопку, инструмент отказал в загрузке. Укажите, как именно зафиксирован отказ: виден результат проверки формата, получен ответ сервера или подтверждение вообще не пришло. Текст «сервер недоступен» нельзя выводить только из того, что пользователь не увидел результата. Причина и наблюдение должны оставаться различимыми.

Полезная граница сценария заканчивается там, где читатель может выбрать ближайший шаг. Если в описание приходится включать несколько независимых неисправностей, разделите карточки. Для одной можно дать конкретное исправление; для другой потребуется статус «результат неизвестен» и проверка истории. Один общий абзац со всеми возможными причинами превращает сообщение в справочник, которым трудно воспользоваться в момент остановки.

Определите также место текста. В инструкции это может быть блок после описания шага, а в интерфейсе — пояснение рядом с соответствующим полем. Если сообщение пересказывается в статье, сохраните точную формулировку интерфейса отдельно от пояснения автора. Читателю должно быть понятно, какой текст он действительно увидит, а какой добавлен для объяснения процесса.

Соберите факты о результате и сохранности данных

До написания сообщения выясните три вещи: выполнено ли действие, что осталось введённым и какое продолжение предусмотрено. Ответы должен подтвердить ответственный за продукт или проверка в разрешённой тестовой среде. Редактор не может обещать сохранность формы, исходя из того, что поля ещё видны на экране: после обновления они могут исчезнуть. Наличие файла на устройстве тоже не подтверждает его загрузку.

Сохранность удобно описывать по объектам. Исходный файл находится у пользователя, введённые поля пока доступны в открытой форме, отправленная заявка имеет подтверждённый статус. Это отдельные утверждения с разными основаниями. Вместо общего «Ваши данные сохранены» выберите точное проверенное сообщение, например о сохранении конкретного черновика. Если подтверждения нет, сообщите предел знания и не предлагайте закрывать страницу без необходимости.

Для рабочей карточки используйте такие поля. Они нужны редакции и не обязательно целиком попадают на экран:

Если столбцы не помещаются, прокрутите таблицу вбок.

Если сценарий меняет важные рабочие данные, сначала согласуйте условие остановки. Допустимость повторной операции зависит от её устройства. Повторное чтение списка и повторная отправка заказа имеют разные последствия; редактору нужно получить конкретный ответ, а не распространять привычку «попробуйте ещё раз» на все кнопки.

Напишите сообщение из необходимых смысловых частей

Первая часть называет, что не получилось: «Файл не прикреплён». Следующая сообщает проверенное состояние: «Остальные поля остались в открытой форме». Затем идёт доступное действие: «Выберите файл подходящего формата и прикрепите его снова». Это редакционная модель, а не обязательное число предложений. Для простого неверного значения может хватить одной фразы с названием поля и допустимым форматом.

В пояснении W3C к критерию Error Identification автоматическое обнаружение ошибки ввода связывается с определением проблемного элемента и текстовым описанием ошибки. Это основание назвать конкретное поле, а не ограничиваться красной рамкой. Критерий относится к ошибкам ввода; его нельзя выдавать за полную инструкцию по любому сетевому сбою или за подтверждение доступности всей страницы.

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

Уберите оценку человека. «Вы неправильно заполнили форму» не показывает место исправления. Точнее назвать условие, которому не соответствует значение. При этом не смягчайте сообщение настолько, что исчезает смысл: фраза «кажется, что-то пошло не так» не позволяет отличить отказ от ожидания. Спокойный тон совместим с прямым указанием на незавершённое действие.

Предложите исправление только при известном способе

В пояснении W3C к Error Suggestion рекомендация исправления связана с известным способом устранения ошибки и содержит исключения для безопасности и назначения материала. Практический вывод для редактора: не придумывайте совет только ради того, чтобы сообщение заканчивалось глаголом. Если исправление неизвестно, дайте действующий маршрут уточнения и обозначьте, какие сведения нужны.

Совет должен быть исполним в текущем состоянии. Если файл отвергнут из-за подтверждённого несоответствия формату, назовите допустимый формат по реальным требованиям инструмента. Если причина не определена, не направляйте человека менять формат наугад. Перечень требований должен находиться рядом с выбором файла или быть доступен по понятной ссылке. Точные ограничения берутся из продукта, а не из похожего сервиса.

Названия кнопок сверяйте с экраном. «Нажмите “Повторить”» полезно только там, где такая кнопка действительно есть и её действие согласовано. В клиентской статье используйте пояснение рядом с точным названием: откройте историю отправок через соответствующий пункт меню, если он предусмотрен. Без такого пункта нельзя обещать, что пользователь самостоятельно проверит результат именно этим способом.

Для неопределённого результата разделите уточнение и повторение. Сначала требуется установить состояние операции; потом можно решать, нужно ли повторять действие. Не назначайте универсальное время ожидания без основания. Если у продукта нет подтверждённого интервала, лучше указать проверяемое событие или официальный канал поддержки, чем обещать восстановление через произвольное количество минут.

Разберите учебный пример без выдуманных функций

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

Исходный вариант сообщения: «Ошибка загрузки. Повторите попытку». Он не называет требование и предлагает повторить то же действие. В пределах заданного сценария уместнее: «Файл не прикреплён: здесь принимается PDF. Остальные поля остались в открытой форме. Выберите PDF-файл и прикрепите его». Слово «здесь» относится к конкретному полю; в самостоятельной инструкции его лучше заменить названием поля.

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

Второй учебный вариант меняет только одно условие: ответ на отправку не получен. Предыдущее сообщение уже не подходит. Пока результат неизвестен, нельзя уверенно писать «заявка не отправлена» и приглашать к повторной отправке. Для реального инструмента потребуется согласованный маршрут выяснения статуса. В демонстрационном тексте такой маршрут не выдумывается: отсутствие факта означает, что карточка ещё не готова к публикации.

При подготовке серии примеров сохраняйте эти различия явно. Не используйте один удачный текст как универсальную заготовку. Удобство короткой формулировки не компенсирует ложное утверждение о данных. Для каждого состояния проверьте все глаголы: «прикреплён», «отправлен», «сохранён», «принят». Они описывают разные события и требуют собственных оснований.

Свяжите сообщение с местом исправления

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

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

Не передавайте ошибку только цветом. В пояснении должно оставаться название проблемы, даже если оформление не видно или человек воспринимает страницу иначе. При проверке макета попробуйте прочитать текст без цветовых акцентов. Если непонятно, к какому полю относится сообщение, добавьте название. Иконка может помочь заметить блок, но не должна быть единственным носителем смысла.

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

Подготовьте маршрут в поддержку без лишних данных

Если самостоятельного исправления нет, сообщите, как передать вопрос и что поможет найти нужное событие. Используйте только существующий канал бизнеса. Не обещайте круглосуточный ответ, конкретный срок или восстановление, если такие условия не установлены. Ссылка «свяжитесь с нами» без доступного контакта оставляет пользователя на месте; реальный переход должен быть частью приёмки сообщения.

Состав сведений определяйте по задаче поддержки. Может быть полезен идентификатор операции, если он действительно отображается и безопасен для передачи по этому каналу. Скриншот просите только когда он нужен, объясняя, какие области следует скрыть. Не требуйте пароль, полный документ с данными клиентов или секретный ключ, чтобы подтвердить обычную ошибку формата. Инструкция не должна расширять сбор сведений по привычке.

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

До обращения предупредите о необходимом сохранении работы только в подтверждённых пределах. Если можно скопировать введённый текст, это действие следует проверить; если копирование запрещено правилами продукта или недоступно, не предлагайте его. Предупреждение перед действием с риском потери данных имеет собственную задачу: подробнее о нём — в статье о предупреждении в клиентской инструкции.

Проверьте карточку на сценарии и передайте в работу

Приёмку начинайте с фактов, а затем оценивайте ясность. Возьмите разрешённый тестовый сценарий с известным результатом и сопоставьте каждый тезис сообщения с наблюдением или согласованным описанием. Не запускайте рискованные операции с реальными заказами ради проверки текста. Если безопасной среды нет, это ограничение нужно зафиксировать и не объявлять сообщение испытанным на работающем продукте.

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

Сдавайте сообщение вместе с карточкой: действие, условие показа, подтверждённое состояние объектов, точный текст, доступное продолжение, источник факта и условие пересмотра. Разработчик должен понимать, когда показывать этот текст. Редактор — какие утверждения перестанут быть верными после изменения формы. При смене требований к файлам нужно проверять и сообщение, и пояснение в статье, и подписи возле поля.

Перед публикацией пройдите короткий контроль: ошибка названа конкретно; сохранность не обещана шире проверки; действие реально существует; повторение допустимо; ссылка помощи работает; сообщение доступно рядом с местом исправления. Незаполненное существенное поле карточки означает возврат на уточнение. Готовый результат здесь — согласованный текст для одного состояния, а не гарантия отсутствия ошибок в процессе.

Частые вопросы

Нужно ли начинать сообщение со слова «Ошибка»?

Не обязательно. Прямое описание незавершённого действия часто точнее. Если слово используется как заголовок блока, рядом всё равно нужно назвать конкретную проблему.

Можно ли добавить извинение?

Можно, когда оно уместно тону продукта. Оно не заменяет статус и следующий шаг. Повторять извинение у каждого неверно заполненного поля обычно избыточно.

Как поступить с неизвестным техническим кодом?

Уточните его назначение у ответственного специалиста. Не придумывайте расшифровку. Решите отдельно, нужен ли код клиенту и можно ли его показывать.

Допустима ли ссылка на общую справку?

Да, если она помогает продолжить и открывается. Когда исправление описано в отдельном разделе, прямой переход к нему обычно требует меньше поиска.

Можно ли переносить текст между приложением и статьёй?

Точную цитату сообщения можно сохранить, но пояснение адаптируйте к месту чтения. Указатели вроде «кнопка ниже» теряют смысл вне исходного экрана.

Когда пересматривать утверждённую карточку?

После изменения условия показа, требований к данным или доступного действия. Смена только цвета блока тоже требует проверки читаемости, но не подтверждает изменение смысла.