Иерархия ошибок и подсветка приоритетов

1) Зачем нужна иерархия ошибок

• объяснить, что пошло не так,
• показать, почему это важно,
• подсказать, что делать дальше,
• расставить приоритеты, если ошибок несколько.
• Иерархия ошибок снижает когнитивную нагрузку, ускоряет исправление и повышает конверсию шагов (регистрация, платежи, KYC).

2) Модель уровней критичности (Severity)

1. Info (информирование) — «Профиль неполный, можно заполнить позже». Не блокирует.

2. Notice (внимание) — «Лимит почти исчерпан». Рекомендуем действовать.

3. Warning (предупреждение) — «Несовпадение формата, данные сохранены частично». Может мешать.

4. Error (ошибка) — «Неверный формат/обязательное поле пустое». Блокирует конкретное действие.

5. Critical (критическая) — «Платеж отклонен/риск безопасности». Блокирует сценарий, требует немедленного шага.

• Один экран — один главный статус.
• При множественных ошибках: показываем критичную сверху и стабильно прокручиваем к первой ошибке.

3) Принципы подсветки приоритетов

1. Визуальная иерархия: цвет/иконка/толщина/контраст возрастают с критичностью.
2. Пространственная близость: ошибка рядом с полем/зоной, к которой относится.
3. Фокус и прокрутка: авто-скролл к первой ошибке + фокус в проблемное поле.
4. Один главный callout: общий баннер/алерт о критической проблеме + локальные подсказки.
5. Последовательность токенов: цвета/иконки/шрифты для Info/Warning/Error неизменны во всем продукте.
6. Время жизни: локальные ошибки — пока не исправлены; баннеры — до закрытия/исправления.
7. Не путаем состояния: «пусто» ≠ «ошибка», «в ожидании» ≠ «ошибка».

4) Визуальный язык (UI-токены)

• Info — нейтральный синий/серый,
• Notice — янтарный/желтый,
• Warning — оранжевый,
• Error — красный,
• Critical — насыщенный красный + контрастный фон.
• Иконки: info ⓘ, notice, error/, success.

• Inline-сообщение под полем (минимальная рамка).
• Row-callout на строку/карточку.
• Page-alert (баннер) — для общих/критичных.
• Микроанимации: мягкое появление, без «дерганья» макета.

5) Тексты ошибок: формула и примеры

Формула: Что не так + Как исправить + (Почему/ограничение).

«Неверный формат даты. Введите в формате ДД.ММ.ГГГГ.»

«Файл слишком большой (макс. 10 МБ). Загрузите файл меньшего размера.»

«Недостаточный уровень верификации. Пройдите KYC — это займет ~2 минуты.»

«Платеж отклонен банком. Попробуйте другой метод или свяжитесь с банком.»

Анти-паттерны: «Ошибка 400», «Что-то пошло не так», юмор в стрессовых шагах.

6) Иерархия в сложных формах (регистрация/KYC/платежи)

1. Inline-валидация на blur: ловим локальные ошибки сразу.
2. Глобальная проверка на submit: показываем баннер «Исправьте отмеченные поля» и список/якоря.
3. Навигация по ошибкам: клавиатурой/табацией, «Перейти к ошибке #1/#N».
4. Порядок исправления: сначала блокирующие (Error/Critical), затем Warning/Notice.
5. Сохранение контекста: введенные данные не теряются при ошибке.

7) Специфика сценариев

7.1 Платежи/выводы

Critical: отклонение провайдером/банком, подозрительная активность.
Error: поле карты/IBAN, лимиты по сумме/частоте.
Warning: медленная сеть/превышение времени ожидания.

Текст: «Платеж отклонен банком. Попробуйте другой метод или свяжитесь с банком. Комиссия не списана.»

7.2 KYC/безопасность

Critical: документ подделан/заблокированная страна/мульти-аккаунт.
Error: нечитабельный документ/несовпадение даты.

Текст: «Фото документа размыто. Загрузите более четкое изображение при хорошем освещении.»

7.3 Поиск/фильтры

Это не ошибка, а нулевой результат.

Текст: «Нет результатов по “{query}”. Уберите фильтр “Провайдер: X” или попробуйте “{alt}”. [Сбросить фильтры]»

8) Доступность (A11y) и технические требования

Ошибки объявляются скринридеру: aria-live="assertive" для критичных, "polite" для прочих.
Поля с ошибкой: aria-invalid="true", aria-describedby на сообщение.
Фокус переносится к первой ошибке; порядок табуляции сохраняет логику.
Контраст по WCAG AA; иконка не заменяет текст.
Текст должен читаться вслух без потери смысла.

9) Локализация и юридическая точность

Избегать жаргона и культурных метафор.
Согласовать термины (глоссарий): «платеж отклонен», «лимит превышен», «верификация».
Указывать сроки и ограничения в локальном формате: «до 15 минут», валюты/даты.

10) Метрики качества

Error rate по полю/шагу (доля пользователей, столкнувшихся с ошибкой).
Time-to-Fix (среднее время до исправления первой ошибки).
Drop-off после ошибки (сколько уходят, не исправив).
Повторяемость ошибок (recurrence) по пользователям/сессиям.
Обращения в поддержку по типу ошибки.
Конверсия шага до/после изменений в иерархии.

• Авто-скролл и фокус vs только цвет/текст.
• Точная формулировка причины vs общая.
• Порядок подсветки (сначала баннер → inline) vs (только inline).
• Добавление ссылки «Показать требования» рядом с ошибкой.

11) Чек-лист перед релизом

• Каждая ошибка имеет уровень (Info/Notice/Warning/Error/Critical).
• Цвет/иконка/контейнер соответствуют уровню.
• Есть прокрутка к первой ошибке и перенос фокуса.
• Сообщение объясняет что/как/почему.
• Термины совпадают с глоссарием; локализация проверена.
• Доступность: aria-атрибуты, контраст, читаемость вслух.
• Данные не теряются при ошибке.
• Статусы «нулевой результат» и «ожидание» не оформлены как ошибки.

12) Примеры «до/после»

Форма даты

До: «Ошибка 400»

После: «Неверный формат даты. Используйте ДД.ММ.ГГГГ.»

Платеж

До: «Оплата не прошла»

После: «Платеж отклонен банком. Попробуйте другой метод или свяжитесь с банком. Комиссия не списана.»

KYC

До: «Документ не принят»

После: «Не удалось распознать документ. Загрузите фото без бликов, видны углы и текст.»

Нулевой поиск (не ошибка!)

До: «Ошибка: ничего не найдено»

После: «Результатов по “live roulette” нет. Уберите фильтр “High-limit” или попробуйте “roulette”. [Сбросить фильтры]»

13) Компоненты дизайн-системы

``

Пропсы: `message`, `severity`, `ariaDescribedBy`, `compact`.
Рендер: текст + иконка, цвет по `severity`.

``

Пропсы: `title`, `description`, `severity`, `actions[]`.
Варианты: `info | notice | warning | error | critical`.

``

Список ошибок с якорями к полям, клавиатурная навигация, «Перейти к #1».

`` (логика)

Правила на поле/форму/шаг, приоритеты, схемы (например, JSON-Schema), локализация сообщений.

14) Быстрые шаблоны фраз

15) Встраивание в процесс

Проектируйте тексты одновременно с логикой валидации.
Храните строки в i18n рядом с компонентами, версионируйте.
В чек-листе PR: соответствие уровню, наличие aria-атрибутов, корректная локализация.
Регулярно ревью ошибок по метрикам и обратной связи поддержки.

Итоговая шпаргалка

Оцифруйте уровни: Info → Critical.
Покажите приоритет визуально и в фокусе.
Объясните исправление коротко и конкретно.
Не называйте пустоту ошибкой.
Мерьте и улучшайте: error rate, Time-to-Fix, drop-off.