Продуктовый дизайн · состояния ошибок

Экраны ошибок: гайд от простого к сложному

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

Инструмент

Проверь свой экран

Выбери тип ошибки и получи рекомендованный паттерн и чек-лист того, что стоит продумать в макете.

Тип экрана

Карта гайда

10 пунктов, разложенные по группам

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

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

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

Когда об этом думать: сразу при проектировании сценария, а не в конце. Как только рисуешь экран, где что-то грузится, отправляется или зависит от внешнего сервиса, у этого действия есть минимум два состояния, кроме успеха: ошибка и, иногда, пустой результат.

Прежде чем придумывать текст или иллюстрацию для ошибки, спроси: блокирует ли эта ошибка сценарий полностью, или пользователь может продолжить работу с приложением, просто зная, что что-то не получилось?

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

От ответа зависит буквально всё остальное. Если ошибка не блокирует, нужен баннер или тост. Если блокирует, нужен полноценный экран со своей структурой, микрокопией, кнопкой действия.

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

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

Мелкие сбои действия, не добавилось в избранное, не отправился лайк, это снекбар или тост с текстом ошибки и кнопкой «Повторить», без увода пользователя с экрана.

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

Иллюстрация или иконка, нейтральная, не паникующая.
Заголовок, что произошло, простыми словами.
Описание, короткое пояснение и что делать.
Основной CTA, одна понятная кнопка.
Код ошибки мелким текстом внизу, для саппорта, не для пользователя.

Если у экрана нет хотя бы кнопки-действия, это уже ошибка дизайна сама по себе. Тупиковых экранов быть не должно.

Если сбой временный, акцент на кнопке «Повторить» с понятным обещанием, «Мы уже знаем о проблеме», если есть мониторинг статуса. Если ошибка совсем неизвестная, важно не врать конкретикой, которой нет, но и не писать голый technical jargon вроде Error 500: Internal Server Error.

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

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

Отказ банка или карты, конкретная причина, если доступна через платёжный шлюз, недостаточно средств, карта заблокирована, 3D-Secure не пройден, плюс CTA «Попробовать другую карту».

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

Важно: не списывать деньги повторно при retry, и явно показывать, спишутся ли средства, если платёж завис в неопределённом статусе.

Это не ошибка «что-то пошло не так», а конкретное событие: «Пока вы оформляли заказ, товар закончился».

Хорошая практика, сразу предложить альтернативу: похожие товары, подписку на уведомление о поступлении, возврат в корзину с уже сохранёнными остальными позициями. Не заставлять пользователя оформлять всё заново с нуля.

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

Нет прав в принципе, кнопка «Запросить доступ» или контакт с администратором.
Функция за платной подпиской, CTA на апгрейд, с объяснением что именно открывает.
Сессия истекла, прямой путь на логин, с сохранением того, что пользователь пытался сделать.

Общее правило для всех трёх: объясняй причину отказа, не просто блокируй.

Человеческий язык вместо технического: не «Error 0x8007045D», а «Не получилось загрузить страницу».

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

Всегда давать выход: retry, назад, альтернативное действие или поддержка.

Не терять пользовательский прогресс при показе ошибки.

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

Понятно ли пользователю, может ли он исправить ситуацию сам?

Есть ли хотя бы одно действие, нет тупика?

Причина названа конкретно, но без лишних технических деталей?

Тон не обвиняющий?

Экран не толще, чем нужно?

Прогресс и данные пользователя не теряются?

Из практики

12 экранов из реальных приложений

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

Тренажёр

А что, если...?

Универсальный вопрос для поиска слабых мест в собственном макете. Нажимай и примеряй вопрос к своему экрану.

А что если...
нажми, чтобы начать