Тексты сообщений об ошибке: готовые формулировки и кнопки (повторить, сохранить черновик, поддержка), чтобы пользователь быстро понял, что делать.
Ошибка почти всегда появляется внезапно. Человек только что что-то делал: заполнял форму, оплачивал заказ, отправлял файл. И вдруг вместо результата получает преграду. Раздражает не сам сбой, а ощущение, что процесс сорвался без предупреждения.
В этот момент пользователь теряет контроль. Он не понимает, что произошло: это он сделал что-то не так или проблема на вашей стороне. Если в тексте есть только «Что-то пошло не так», мозг дорисовывает худший вариант, и напряжение растет.
Отдельная боль - страх потерять данные. Люди злятся сильнее всего, когда кажется, что пропал результат: длинный текст, заполненная анкета, настройки, корзина. Даже если данные на самом деле сохранились, без явного подтверждения ошибка ощущается тяжелее.
Разница между плохими и хорошими сообщениями - на уровне ощущений. Плохое звучит как отказ и равнодушие: сухо, без причин и подсказок, иногда еще и с кодами ошибок. Хорошее звучит по-человечески: спокойно объясняет, что случилось, и сразу показывает выход.
Пользователю в момент сбоя нужны простые вещи:
И важный момент: ошибка - это не только текст. Если рядом нет действий, не спасет даже идеальная формулировка. Пользователю нужны варианты прямо здесь: повторить попытку, сохранить черновик, вернуться назад без потерь, написать в поддержку с уже подставленными деталями. Например, при сбое отправки формы лучше сразу показать: «Мы не отправили, но данные сохранены. Попробовать еще раз или сохранить как черновик».
Чем меньше догадок вы оставляете человеку, тем меньше злости вызывает ошибка. Хорошее сообщение возвращает контроль: говорит, что происходит, и дает понятные шаги без поисков и лишних экранов.
Хорошее сообщение об ошибке делает две вещи: снижает тревогу и помогает продолжить. Пользователю важнее не «причина в терминах разработчика», а простое объяснение и понятный следующий шаг.
Начинайте с человеческого описания: что именно не получилось (отправить форму, сохранить изменения, загрузить файл). Затем сразу скажите, что можно сделать прямо сейчас. Тогда сообщение перестает быть «стеной отказа» и становится подсказкой.
Не звучите как обвинение. Формулировки вроде «Вы ввели неверно» или «Ошибка пользователя» вызывают сопротивление. Лучше: «Не получилось проверить данные» или «Не удалось отправить, соединение нестабильно». И без сарказма, даже если ситуация типовая.
Тон тоже работает на доверие. Капслок, три восклицательных знака и «СРОЧНО» выглядят как паника системы. Спокойный текст в одно-два коротких предложения воспринимается как контроль над ситуацией.
Пользователь не должен выбирать из пяти кнопок, когда он и так раздражен. Дайте один основной выход (например, «Повторить») и один запасной (например, «Сохранить черновик» или «Написать в поддержку»). Если вариантов больше, прячьте их в «Подробнее» или оставляйте на следующем экране.
Быстрая проверка формулировки:
Если вы пишете «Мы уже все исправили», а проблема повторится, доверие падает сильнее, чем от самой ошибки. Лучше честно: «Мы видим проблему и разбираемся» или «Попробуйте еще раз через минуту».
В продуктах с чат-интерфейсом это особенно заметно. Вместо «Сервис недоступен» полезнее: «Не удалось обработать запрос. Попробуйте повторить. Если не получится, мы сохраним ваш текст и вы сможете отправить его позже». Такой текст дает выход и сохраняет ощущение контроля.
Понятное сообщение похоже на дорожный знак: коротко объясняет, что случилось, и показывает, куда идти дальше. Если в тексте есть только «Ошибка 504» или «Что-то пошло не так», пользователю не за что зацепиться, и раздражение растет.
Обычно сообщение складывается из нескольких простых частей, и каждая отвечает на свой вопрос.
Короткий заголовок, чтобы человек сразу понял контекст. 3-6 слов, без кодов и без «фатальности». Например: «Не удалось отправить форму» или «Платеж не прошел».
Одна спокойная фраза про причину, но только если вы действительно уверены. Лучше «Похоже, нет соединения с интернетом», чем выдуманное «Сервер перегружен». Если причина неясна, честнее написать: «Не смогли завершить действие. Попробуйте еще раз».
Следующий шаг прямо сейчас. Он должен быть конкретным: «Проверьте соединение и повторите», «Обновите страницу», «Попробуйте через минуту».
Кнопки, которые подтверждают текст, а не спорят с ним. Обычно достаточно двух:
Сделайте так, чтобы основной вариант не был рискованным. Если повтор может привести к дублю (например, повторная оплата), лучше сначала показать безопасную кнопку («Проверить статус»), а повтор оставить вторичным действием.
Пользователю не нужны «NullReferenceException» и «traceId» в основном тексте, но поддержке и разработчикам это важно. Дайте технические детали в блоке «Подробности»: код ошибки, ID запроса, время, шаг, где сломалось. Так интерфейс остается спокойным, а разбираться можно быстрее.
Мини-правило: на эмоциях человеку нужны смысл и следующий шаг. Все остальное прячьте в «Подробности» или отправляйте в логи.
Хорошие сообщения начинаются не с формулировки, а с понимания ситуации: что делал человек и какой результат ожидал. Если сначала назвать сценарий, а потом дать безопасный следующий шаг, раздражение заметно падает.
Вот простой процесс, который помогает писать тексты быстро и одинаково по всему продукту:
Назовите момент сбоя человеческими словами. Не «500» и не «таймаут», а «Не удалось отправить форму» или «Не получилось сохранить изменения». Это отвечает на вопрос «где я сейчас?».
Определите цель сообщения. Чаще всего она одна: продолжить действие (повторить), сохранить прогресс (черновик), обратиться за помощью (поддержка) или отменить и вернуться назад. Если целей две, выберите главную, вторую оставьте как запасной выход.
Напишите черновик в 1-2 предложениях без терминов. Хороший ритм: сначала факт, затем мягкая причина, если она понятна. Например: «Не удалось загрузить файл. Похоже, пропало соединение». Если причина не ясна, не придумывайте: «Мы не смогли завершить действие. Попробуйте еще раз».
Добавьте действия и назовите кнопки глаголами. Кнопка должна звучать как следующий шаг: «Повторить», «Сохранить черновик», «Написать в поддержку», «Отмена». Избегайте «ОК» и «Закрыть», если человек еще не понял, что будет дальше.
Сделайте финальную правку под спокойный тон. Уберите обвинения («вы сделали неправильно»), усилители («срочно», «немедленно») и лишние детали. Текст должен быть коротким, но не сухим.
Затем прогоните сообщение через три контрольных вопроса:
Мини-сценарий для проверки: пользователь в чате TakProsto отправляет запрос на генерацию экрана, и сеть обрывается. Сообщение должно сказать «Не удалось отправить запрос», предложить «Повторить» и дать безопасную опцию «Сохранить черновик», чтобы человек не перепечатывал текст.
Хороший текст ошибки отвечает на три вопроса: что случилось, что можно сделать сейчас и что будет с данными. Ниже - заготовки, которые можно адаптировать под ваш продукт.
В таких сообщениях избегайте формулировок вроде «ошибка сети» без подсказки. Лучше назвать действие: проверить подключение, повторить, подождать.
Здесь пользователь чаще всего может исправить все сам. Текст должен указывать на конкретное поле и правило.
Если возможно, давайте подсказку прямо рядом с полем, а в общем сообщении оставляйте короткое резюме: «Есть ошибки в форме».
Главное - не обвинять пользователя и дать понятный путь: войти заново, запросить доступ, сменить аккаунт.
Если данные могли не сохраниться, говорите об этом честно. Если сохранены - скажите прямо.
Тон должен быть спокойным: платежи часто вызывают стресс. Уточняйте статус и следующие шаги.
Если у вас есть понятные статусы (ожидается подтверждение, обработка, отменено), показывайте их, а не общий текст «ошибка оплаты».
Когда причина не ясна, пользователю все равно нужен план. Дайте безопасное действие и способ сообщить о проблеме.
Хорошая практика - добавлять короткий идентификатор (например, «Код ошибки: A17») в интерфейсе или в деталях, чтобы поддержке было проще найти запись.
Сообщение об ошибке почти всегда должно давать выход: что можно сделать прямо сейчас. Кнопка «ОК» без выбора оставляет человека один на один с проблемой.
Предлагайте «Повторить», когда повторный запрос безопасен: не создаст дубль оплаты, не отправит форму дважды, не запустит операцию повторно без контроля. Если есть риск дубля, лучше писать «Проверить статус».
Чтобы снять страх потери данных, добавляйте короткую подсказку рядом с кнопкой: «данные сохранены», «ничего не потеряется», «если отправка уже прошла, мы покажем результат». Обещайте только то, что вы действительно делаете.
«Сохранить черновик» предлагайте, когда человек уже ввел заметный объем данных: длинная форма, комментарий, заявка, настройки. Это особенно важно, если ошибка связана с сетью, таймаутом или перегрузкой.
Формулировки:
Если сохранение может занять время, добавьте честное ожидание («Сохраняем...») и затем явное «Готово». Не оставляйте человека гадать, случилось ли действие.
Кнопка «Написать в поддержку» нужна, когда проблема не решается повтором или ошибка повторяется. Важно помочь человеку описать ситуацию без лишних усилий.
Что полезно собрать автоматически (и показать в черновике обращения): идентификатор ошибки, время, экран или действие (например, «Отправка формы»), тип устройства, версия приложения, состояние сети.
Шаблон, который пользователь может отправить:
"Не получается [действие]. Ошибка появляется после [шаг]. Пробовал(а) повторить - не помогло. Примерное время: [время]. Если нужно, могу прислать скриншот. Код ошибки: [код]."
Иногда лучше дать еще 1-2 простых кнопки, чем ограничиться «ОК»:
Главное правило: каждая кнопка должна быть безопасной, понятной и обещать только то, что вы действительно делаете.
Пользователь заполнял длинную форму: контакты, адрес, комментарий, прикрепил файл. Нажал «Отправить» и ждет подтверждение. В этот момент соединение пропало или сервер не ответил вовремя.
«Ошибка». Без объяснений, что случилось, что делать дальше и самое главное - без сохранения введенных данных. Пользователь видит пустую форму (или не понимает, сохранилось ли что-то) и злится: потратил время, и все пропало.
Хороший текст быстро объясняет ситуацию и дает безопасный выход.
Не удалось отправить форму.
Похоже, связь прервалась или сервис ответил слишком долго.
Ваши данные не потеряны.
[Сохранить черновик] [Повторить отправку]
Если пользователь нажимает «Сохранить черновик», покажите короткое подтверждение и понятный маршрут назад. Например:
Черновик сохранен.
Мы сохранили данные на этом устройстве и в вашем аккаунте.
Вернуться к черновику можно в разделе «Черновики».
После любого действия важно показать, что именно произошло:
Если повтор не помог 2-3 раза, предложите поддержку спокойно и без обвинений: «Не получается отправить? Напишите в поддержку, и мы поможем. Укажите, что вы делали, и время ошибки». Лучше сразу добавить кнопку «Написать в поддержку» и подставить в сообщение технический код или время события, чтобы человеку не пришлось переписывать детали вручную.
Проблема часто не в тоне, а в удобстве. Пользователь не должен угадывать, что случилось и что делать дальше.
Фразы вроде «500», «NullReference», «stack trace» помогают разработчику, но раздражают человека. Покажите пользователю понятный смысл, а техническую деталь спрячьте в «Подробнее» или прикрепите к обращению в поддержку.
Хорошее правило: одно предложение про проблему, одно про действие. Например: «Не удалось сохранить изменения. Попробуйте еще раз через минуту».
«ОК» закрывает окно, но не решает задачу. Если действие важное (оплата, отправка формы, сохранение настроек), дайте 1-2 понятных шага: повторить попытку, сохранить черновик, написать в поддержку, вернуться назад без потери данных.
Если действие возможно, но кнопки нет, пользователь чувствует тупик даже при мелкой ошибке.
«Мы уже все исправили» - опасная фраза, если вы не уверены. Лучше говорить о том, что вы точно знаете: «Похоже, возникла проблема на нашей стороне. Мы уже получили сигнал и проверяем».
Если у вас есть надежный механизм (например, автосохранение или очередь отправки), обещание можно делать конкретным: «Данные сохранены в черновике, вы можете вернуться позже».
Длинный текст с перечислением причин читают плохо, особенно на телефоне. Не пытайтесь объяснить все. Дайте главный смысл и короткий следующий шаг. Остальное уберите в «Подробнее».
Сегодня «Повторить», завтра «Перезапустить», послезавтра «Отправить снова» - это ломает привычку и заставляет думать. Выберите одно название и используйте его везде. То же касается поддержки: «Написать в поддержку» не должно превращаться в «Связаться с нами» на соседнем экране.
Если вы делаете продукт в TakProsto, удобно завести небольшой словарь действий (для кнопок и коротких подсказок) и использовать его во всех экранах, чтобы формулировки были одинаковыми.
Сообщение должно читаться за пару секунд. Если вы не можете произнести его вслух одним дыханием, оно, скорее всего, слишком длинное.
После этого посмотрите на кнопки. Их текст должен быть действием, а не абстрактным «ОК». Человек должен понимать, что случится после нажатия.
Одного шага часто достаточно, но запасной вариант снимает напряжение. Пример: «Повторить» как основной путь и «Сохранить черновик» как безопасный.
Мини-тест: отключите интернет, попробуйте отправить форму, сверните приложение и вернитесь. Если в этом сценарии пользователь не теряет данные и всегда видит понятный следующий шаг, вы на правильном пути.
Когда тексты и действия при ошибках готовы, превратите их в библиотеку. Тогда сообщения будут звучать одинаково спокойно, а команда перестанет каждый раз изобретать формулировки заново.
Выберите 10-20 самых частых ситуаций и закрепите для них шаблоны: короткий заголовок, простое объяснение, что можно сделать сейчас. Отдельно зафиксируйте тон: без обвинений пользователя, без технических слов, без паники. Полезно сразу добавить примеры: как звучит правильно и как не надо.
Заранее подготовьте тексты для пустых состояний и офлайн-режима. Это экраны, которые всплывают неожиданно часто: нет сети, нет данных, доступ ограничен.
Чтобы поддержка не задавала пять уточняющих вопросов, добавьте в сообщение минимальные данные, которые пользователь может скопировать (или которые подставятся автоматически): ID ошибки или короткий код, время (и часовой пояс), шаг пользователя, контекст (экран или операция), ID сессии или заявки (если есть).
После этого прогоните тексты на реальных сценариях: регистрация, оплата, отправка формы, смена пароля. В каждом сценарии проверьте, что пользователь не теряет данные, видит понятный выход (повторить, сохранить, написать в поддержку) и не попадает в бесконечный круг одинаковых ошибок.
Если вы делаете приложение через TakProsto, такие сценарии удобно проверять прямо на собранных экранах: продумать состояния ошибки, добавить действия и короткие подтверждения, а затем быстро прогнать тестовые потоки. Саму платформу можно найти как takprosto.ai.
Потому что ошибка прерывает действие внезапно и забирает у человека ощущение контроля. Если текст не объясняет, что именно не получилось и что делать дальше, пользователь начинает нервничать и злиться сильнее, чем от самого сбоя.
Начните с простого описания действия: что именно не удалось сделать прямо сейчас (отправить форму, сохранить изменения, загрузить файл). Затем сразу дайте понятный следующий шаг, чтобы человек мог продолжить без поисков и догадок.
Скажите это явно в самом тексте, если вы действительно сохраняете введенное. Фраза уровня «Данные сохранены, можно повторить позже» часто снимает большую часть напряжения и уменьшает число повторных попыток «на всякий случай».
Не пишите «вы ошиблись» и не ставьте диагноз пользователю. Лучше формулировать через ситуацию: «Не удалось проверить данные» или «Соединение нестабильно», и сразу подсказать конкретное действие, которое поможет.
Обычно достаточно двух: основной безопасный путь и запасной выход. Чем больше вариантов на экране, тем выше шанс, что человек зависнет в выборе или нажмет не то, особенно в стрессовый момент.
Предлагайте «Повторить», когда повтор не приводит к опасным последствиям, например к дублю оплаты или повторной отправке заявки. Если есть риск дубля, безопаснее сначала предложить проверку статуса или другой нейтральный шаг.
Когда человек уже ввел заметный объем данных или действие занимает время, а сбой может повториться из-за сети или таймаута. Черновик снижает страх «все пропало» и убирает необходимость перепечатывать текст.
Показывайте понятный смысл пользователю, а технические детали прячьте в «Подробности» или готовьте для поддержки автоматически. Если нужен код, добавьте короткий идентификатор, который можно скопировать, но не перегружайте им основной текст.
Дайте понятную причину, если вы уверены, и предложите безопасный план: повторить через минуту и обратиться в поддержку, если ошибка повторяется. Важно не обещать «мы уже исправили», если вы не можете это гарантировать.
Сделайте так, чтобы человек мог отправить обращение без лишних усилий: подставьте время, действие и идентификатор ошибки, а текст запроса оставьте коротким и человеческим. В чат-продуктах вроде TakProsto особенно важно сохранить введенный запрос, чтобы пользователь не переписывал его заново.