Что должно сообщать ваше приложение, когда что-то ломается: как писать понятные сообщения об ошибках
Хорошее сообщение об ошибке объясняет, что произошло, чья это вина, что делать дальше — и не стирает то, что уже успел ввести пользователь. Именно оно превращает сбой в повторную попытку, а не в потерянного навсегда пользователя.
Любое приложение иногда ломается. Пропадает интернет, сервер на секунду зависает, кто-то вводит номер телефона с буквами. Это вы контролировать полностью не можете. А вот что вы можете контролировать — так это сообщение об ошибке: текст, который приложение показывает, когда что-то пошло не так. И именно это сообщение чаще всего решает, пожмёт ли пользователь плечами и попробует снова — или тихо решит, что приложение сломано, и больше не вернётся.
Именно этот момент большинство приложений, созданных с помощью ИИ, упускают. Не потому что билдер сделал что-то небрежно, а потому что про сообщения об ошибках никто не думает — пока что-то не сломается на глазах у живого человека. По умолчанию приложения обычно показывают одно из двух худших вариантов: вообще ничего или пугающий блок технического текста. Давайте исправим оба.
Почему приложения молча падают или показывают пугающие ошибки?
Приложения ломаются плохо одним из двух способов: либо молчат, когда что-то не удалось, либо показывают техническую ошибку, которую обычный человек прочитать не может. В обоих случаях пользователь остаётся гадать — а именно догадки заставляют людей сдаваться.
Тихий сбой. Фрилансер, назовём её Майя, сделала форму записи для своего фотобизнеса. Клиентка нажала «Подтвердить запись», кнопка мигнула — и ничего. Ни подтверждения, ни ошибки, ни индикатора загрузки. Сработало? Клиентка не была уверена и записалась ещё раз. В итоге у Майи оказалось две записи на один и тот же слот и растерянная клиентка. Приложение не упало — просто не сохранилось, а поскольку оно ничего не сказало, человек перед экраном понятия не имел, что происходит на самом деле.
Пугающая техническая ошибка. Второй тип сбоя громче — и почему-то ещё хуже. Волонтёр, организующий сбор средств для сообщества, попытался загрузить таблицу и увидел красный блок с надписью Error 500: Internal Server Error. Она прочитала это как «я что-то сломала». Она не стала пробовать снова, не написала за помощью — просто закрыла вкладку, потому что сообщение звучало так, будто это её вина и трогать это снова, возможно, небезопасно.
Оба пользователя столкнулись с обычной, легко устранимой проблемой. Оба ушли — потому что сообщения об ошибках либо молчали, либо пугали.
Что делает сообщение об ошибке хорошим?
Хорошее сообщение об ошибке делает четыре простые вещи простыми словами: говорит, что произошло, говорит, чья это проблема, говорит, что делать дальше, и не теряет то, что уже успел сделать пользователь.
- Говорит, что произошло — «Не удалось сохранить вашу запись», а не тишина и не
500. - Говорит, чья это проблема — обычно честный ответ: «наша», и признание этого успокаивает людей.
- Говорит, что делать дальше — «Попробуйте ещё раз через минуту» или «Проверьте подключение к интернету и повторите попытку».
- Не теряет их работу — всё, что человек ввёл, всё ещё на месте в форме, когда появляется сообщение.
Вот и всё. Никаких извинительных эссе, никакого кода ошибки в заголовке, никакого обвинения. Вот те же три сбоя, переписанные заново:
- ❌ (ничего не происходит) → ✅ «Не удалось сохранить это только что. Ваши данные всё ещё здесь — нажмите «Подтвердить», чтобы попробовать снова».
- ❌
Error 500: Internal Server Error→ ✅ «Что-то пошло не так на нашей стороне при загрузке файла. Это не вы. Попробуйте ещё раз через минуту». - ❌
Invalid input→ ✅ «Этот номер телефона выглядит неправильно — он должен содержать 10 цифр, например 555-123-4567».
Обратите внимание на последний пример: он указывает на конкретное поле и показывает, как должно выглядеть правильное значение. «Invalid input» заставляет человека гадать; «этот номер должен содержать 10 цифр» — прямо говорит, что исправить.
Какие ошибки в приложении стоит исправить в первую очередь?
Не нужно писать своё сообщение для каждой возможной поломки — три случая покрывают почти всё, что обычно идёт не так в типичном приложении: неудавшееся сохранение или отправка, ввод, который приложение не может обработать, и сбой на вашей стороне.
Неудавшееся сохранение или отправка. Самый разрушительный для доверия случай, потому что пользователь всё сделал правильно и не уверен, сработало ли это. Всегда подтверждайте успех и объясняйте неудачу. Никогда не оставляйте человека гадать и никогда не стирайте то, что он ввёл.
«Мы не можем использовать то, что вы ввели» (валидация). По сути, это даже не ошибка — это недопонимание. Ловите его сразу, как только пользователь покидает поле, указывайте на конкретное поле и показывайте пример правильного формата. Не ждите, пока человек нажмёт «Отправить», чтобы обрушить на него стену красного текста.
«Что-то сломалось на нашей стороне». Настоящие проблемы с сервером или сетью. Скажите, что это на вашей стороне, сохраняйте спокойный тон и дайте возможность повторить попытку. Пользователь не может починить ваш сервер — не заставляйте его чувствовать, что должен.
Три привычки, которые незаметно помогают
Есть несколько вещей, которые отличают приложения, изящно справляющиеся со сбоями, от тех, что справляются плохо:
- Никогда не показывайте необработанный код ошибки как всё сообщение целиком. Код может мелким текстом сохраняться внизу для поддержки, но заголовок, который читает человек, должен быть предложением, а не
ERR_CONN_RESET. - Никогда не обвиняйте пользователя. «Вы ввели что-то неправильно» ранит; «эта дата выглядит так, будто она уже в прошлом — вы имели в виду следующий месяц?» помогает. Информация та же, ощущение — совершенно другое.
- Всегда сохраняйте введённые данные. Если приложение перезагружается или сохранение не удаётся, а форма при этом очищается, вы превратили небольшую заминку в десять минут повторного ввода. Люди прощают неудавшееся сохранение. Они не прощают, когда работу приходится делать дважды.
Как заставить ваш ИИ-билдер писать лучшие сообщения об ошибках?
Большую часть этого можно получить одним запросом — вставьте что-то вроде промпта ниже, и ваш ИИ-билдер применит описанные выше правила понятного языка по всему приложению.
«Когда сохранение или загрузка не удаётся, не падай молча и не показывай технический код ошибки. Покажи короткое, дружелюбное сообщение простым языком, которое объясняет, что произошло, говорит, что можно попробовать снова, и сохраняет всё, что пользователь уже ввёл. Для полей формы проверяй ввод сразу после того, как пользователь покидает поле, и показывай конкретное сообщение с примером правильного формата».
Затем попросите его показать, что происходит в трёх случаях: интернет отключён, обязательное поле пустое, сервер работает медленно. Если ответ хотя бы на один из них — «ничего не показывается» или «показывается необработанная ошибка» — вот с этого и нужно начинать исправления.
Как протестировать сообщения об ошибках в вашем приложении?
Отключите wifi, откройте приложение и попробуйте выполнить основное действие — это весь тест целиком, и он займёт две минуты.
Забронируйте слот, сохраните заметку, загрузите файл. Посмотрите, что покажет приложение. Сказало ли оно что-то, что поймёт обычный человек? Потеряло ли оно введённые данные? Теперь снова включите wifi и намеренно введите в поле какую-нибудь бессмыслицу. Те же вопросы.
Большинство приложений проваливают этот тест с первого раза — и это нормально, он просто показывает, с чего начать. Не нужно делать идеальным каждое сообщение об ошибке. Найдите в своём приложении то, что ломается чаще всего, и сделайте именно это сообщение добрым, ясным и честным в первую очередь. В следующий раз, когда реальный человек на него наткнётся, он попробует снова, а не уйдёт — а попробовать снова — это и есть вся суть.