«Что-то пошло не так» — и что теперь? Как писать тексты ошибок по-человечески

Вы оформляете заказ в приложении любимой кофейни, нажимаете «Перейти к оплате» и видите:

«Ошибка 500. Internal Server Error».

И что теперь?

Заказ создался? Деньги списали? Нажимать ещё раз или лучше ничего не трогать?

Обычно никто специально не пытается запутать пользователя. Просто во время разработки в ошибки и пустые экраны ставят первое, что есть под рукой: код сервера, «Что-то пошло не так», «Нет данных». А потом временный текст незаметно доезжает до продакшена.

Меня зовут Анастасия, я дизайнер интерфейсов и делаю DesignStack — каталог ресурсов и бесплатные уроки для UX/UI-дизайнеров.

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

Сообщение об ошибке обычно читают два человека.

Разработчику важно знать, что вернул сервер: 500, timeout или network request failed.

Пользователю важно совсем другое: оформился ли заказ, списались ли деньги и что делать дальше.

Поэтому сообщение вроде «Ошибка 500» технически точное, но почти бесполезное.

Одна и та же ошибка: сервер магазина не ответил, заказ не создан, до оплаты дело не дошло

Даже вариант «Что-то пошло не так. Попробуйте позже» не сильно помогает. Что именно пошло не так? Заказ? Оплата? Интернет? А «позже» — это через минуту или завтра?

Хороший текст ошибки переводит проблему с языка системы на язык задачи пользователя.

Например:

«Ошибка 500» → «Заказ не оформлен: сервер магазина не ответил»
«Network request failed» → «Нет связи с интернетом. Корзина сохранена»
«Session expired» → «Войдите снова — корзина останется на месте»
«Request timeout» → «Заказы не загрузились: сервер долго не отвечает»
«404 Not Found» → «Такой страницы нет. Если вводили адрес вручную, проверьте его»
«promo_code: expired» → «Промокод OSEN10 действовал до 30 сентября»

Это совпадает с одной из эвристик Якоба Нильсена: сообщение об ошибке должно быть написано простым языком, точно объяснять проблему и подсказывать решение.

У Контур.Гайдов мысль ещё проще: рассказывайте о проблеме с точки зрения пользователя, а не системы.

Выбрасывать его необязательно.

Код может пригодиться поддержке или разработчику, если пользователь сообщит о проблеме. Но ставить его на первое место тоже не стоит.

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

Есть простая проверка.

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

После ошибки человек обычно не хочет читать объяснение устройства системы. Он хочет закончить то, что начал.

Поэтому хорошее сообщение не только объясняет проблему, но и отвечает на вопрос: «Что мне делать теперь?»

Обычно вариантов четыре.

Повторить действие, если сбой случайный и повтор ничего не испортит:

«Список заказов не загрузился. Попробуйте ещё раз».

Кнопка: «Повторить».

Подождать, если сервис временно недоступен:

«Оплата картой не работает до 14:00 — банк обновляет систему».

Если есть другой способ оплаты, его стоит предложить рядом.

Выбрать другой путь, если текущий недоступен:

«Курьер на Лесную улицу сегодня не едет. Заберите заказ в пункте выдачи — он в 600 метрах от дома».

Кнопка: «Выбрать пункт выдачи».

Написать в поддержку, если самостоятельно решить проблему нельзя:

«Напишите в поддержку и назовите код CX-4821».

У этой фразы есть проблема: непонятно, когда именно наступит это «позже».

Максим Ильяхов в «Советах» Бюро Горбунова показывает это на примере. Сравните:

«Платёжный шлюз перегружен. Попробуйте позже».

И:

«Платёж не прошёл: система перегружена. Повторите платёж через полчаса».

Во втором случае человек понимает, что произошло и когда стоит вернуться.

Если точное время известно — лучше его написать. Если неизвестно, придумывать его, конечно, не нужно.

Если сообщение предлагает повторить действие, кнопка должна называться «Повторить» или «Оформить ещё раз».

Кнопка «ОК» обычно просто закрывает сообщение и оставляет человека один на один с той же проблемой.

Получается немного абсурдно: произошла ошибка, а интерфейс предлагает согласиться, что всё «ОК».

Представим другой случай: банк отклонил оплату заказа на 2 180 ₽.

Хорошее сообщение должно ответить хотя бы на три вопроса:

что произошло;
что стало с деньгами;
что можно сделать дальше.

Слева покупателя просят проверить карту, хотя отказал банк, а „ОК“ оставляет его с той же ошибкой

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

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

Кстати, в полном уроке DesignStack такое сообщение можно собрать самостоятельно: у каждой части есть несколько вариантов и объяснение, почему один работает лучше другого.

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

«Вы ввели неверно».

«Вы не указали».

«Вы забыли».

«Недопустимо».

«Некорректно».

У человека уже что-то не получилось. Необязательно ещё и объяснять ему, кто виноват.

Сравните:

«Вы ввели неверные данные» → «Не получилось сохранить адрес»
«Ваша карта отклонена» → «Банк не подтвердил оплату. Деньги не списаны»
«Недопустимый промокод» → «Промокод OSEN10 действовал до 30 сентября»
«Вы указали адрес вне зоны доставки» → «Курьер на Лесную улицу пока не ездит. Ближайший пункт выдачи — в 600 метрах»
«Вы не выбрали время доставки» → «Выберите время доставки»

Есть простой способ заметить упрёк: ищите конструкцию «вы + глагол в прошедшем времени».

«Вы ввели», «вы забыли», «вы не указали» часто можно переписать спокойнее.

При этом выгораживать сервис тоже не нужно. Если проблема возникла на его стороне, лучше сказать об этом прямо.

Здесь слишком точное сообщение может навредить безопасности.

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

Поэтому OWASP рекомендует не уточнять, что именно не совпало.

Вместо обвиняющего текста можно написать:

«Почта или пароль не подходят».

А рядом дать ссылку «Восстановить пароль».

WCAG 2.2 тоже делает оговорку: подсказку об ошибке стоит показывать только тогда, когда она не создаёт угрозу безопасности.

Иногда эта фраза вполне честная.

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

Но чаще причина известна. Просто в продукте есть один общий обработчик, который показывает одинаковый текст во всех случаях.

Что с этим делать дизайнеру?

Попросить разработчика рассказать, какие ошибки вообще могут возникнуть на этом экране и что приложение знает о каждой из них.

Например:

1. Телефон потерял связь

«Нет связи с интернетом. Корзина сохранена — оформить заказ можно, когда связь появится».

2. Закончилась сессия

«Войдите снова — корзина останется на месте».

Кнопка: «Войти».

3. Товар закончился во время оформления

«Кения АА закончилась, пока вы оформляли заказ. Остальное можно заказать без неё».

4. Причина неизвестна

«Не получилось оформить заказ. Корзина на месте — попробуйте через пару минут. Если не выйдет, напишите в поддержку и назовите код CX-4821».

Даже если точная причина неизвестна, почти всегда известно хотя бы три вещи:

что не получилось;
что стало с данными;
что человек может попробовать дальше.

Этого уже достаточно, чтобы написать сообщение лучше, чем просто «Что-то пошло не так».

Но важно не обещать того, чего система не знает.

Если ответ от банка не пришёл, нельзя уверенно написать «Деньги не списаны». Возможно, платёж всё-таки прошёл.

Лучше честная неопределённость, чем успокаивающее, но неверное сообщение.

Пустота в интерфейсе бывает разной.

Иногда человек ещё ничего не сделал.

Иногда сделал, но ничего не нашёл.

И это два разных сценария.

Представим, что человек впервые открыл раздел «Избранное». Он может вообще не знать, что здесь должно появляться. Поэтому «Нет данных» ему ничего не объясняет.

Лучше рассказать, зачем нужен раздел и как здесь что-то появится.

Например:

«Здесь будут сорта, которые хочется попробовать. Нажмите ♡ на карточке сорта — он появится здесь».

И рядом — действие, с которого можно начать: кнопка «Открыть каталог».

„Нет данных“ — слова базы, а не магазина

Apple для таких экранов тоже рекомендует давать понятный следующий шаг, желательно кнопкой или ссылкой.

Теперь другой случай.

Пользователь ищет «кения без кофеина», но результатов нет.

Здесь он уже знает, чего хочет. Поэтому интерфейсу лучше не просто сказать «Ничего не найдено», а помочь продолжить поиск.

Например:

«Кении без кофеина нет. Без кофеина в каталоге два сорта: Эфиопия и Колумбия».

Запрос повторён словами, сказано, чего именно нет, и показано, что есть

Хорошо, если запрос остаётся в строке поиска, а рядом появляются похожие варианты или исправление опечатки.

Nielsen Norman Group рекомендует повторять запрос, предлагать похожие варианты и помогать исправлять написание.

А исследования Baymard показывают, что даже многие интернет-магазины до сих пор оставляют пользователя с пустым поиском без нормального выхода.

Пустой экран новичок может увидеть один раз.

Пустой поиск — хоть каждый день.

Оба состояния стоит продумать ещё до запуска продукта.

Перед тем как отдавать макет разработчику, проверьте сообщение.

Оно готово, если:

заголовок говорит, что не получилось у человека, а не что сломалось внутри системы;
технического кода нет или он стоит после объяснения и нужен только для поддержки;
сказано, что стало с данными или деньгами, если система знает это наверняка;
есть следующий шаг: повторить, подождать, выбрать другой путь или обратиться в поддержку;
кнопка действительно выполняет действие, которое предлагает текст;
нет обвиняющих формулировок вроде «вы ввели», «вы забыли», «некорректно» и «недопустимо»;
«Что-то пошло не так» используется только тогда, когда причина действительно неизвестна, и не остаётся единственной фразой;
пустой экран объясняет, что здесь появится и как это сделать;
пустой поиск напоминает, что искали, и предлагает альтернативу.

И ещё один совет: ошибки полезно проверять не только в макете, но и в самом продукте.

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

В обычном сценарии эти тексты почти незаметны. Они появляются именно тогда, когда всё идёт не по плану.

А значит, в этот момент особенно важно написать понятно.

Если хочется потренироваться, полный урок есть на DesignStack. Там можно самостоятельно собрать сообщение об ошибке, пройти тренажёр «упрекает или по делу» и поискать проблемы в учебном приложении «Лесная обжарка».