Отображение ошибок в интерфейсе, часть 3 – Выбор контента для описания ошибки Пользователю

Привет! Говорит Настя Овсянникова, старший дизайнер Липтсофт. Завершаю серию статей для дизайнеров про ошибки и их отображение в интерфейсе.

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

Все статьи серии

Копаем вглубь:
1. Как возникают ошибки

Систематизируем:
2. Выбор способа отображения ошибки в интерфейсе
3. Выбор контента для описания ошибки Пользователю (вы здесь)

Микросовет
Если ваш продукт миновал стадию концепции и давно «живёт», я бы посоветовала сначала пробежаться по экранам и собрать в одном месте существующие тексты ошибок. Скорее всего найдутся грамматические конструкции, которые можно привести к единству.

Для многих ситуаций стоит написать конкретный текст. Я приведу в пример решения в нашем продукте. Для вашего можно применить тот же подход. Но на детализацию, tone of voice и «очеловеченность» текстов повлияют специфика продукта и роли пользователей.

Сбой Клиента

В предыдущей части мы пришли к выводу, что сбой Клиента в любом контексте можно закрыть одним дизайн-решением. У нас это страница-config-item, которая по визуальной и грамматической структуре похожа на полноэкранную ошибку.

У полноэкранной ошибки в свою очередь есть:

• тематическая иконка;
• заголовок – суть ошибки;
• пояснительный текст – что Пользователь может сделать;
• первостепенное и второстепенное действие.

В config-item-е мы можем использовать иконку, заголовок и пояснительный текст. Не размещаем на странице кнопки и ссылки – разработчики не рекомендуют. Не советуем перезагрузить страницу – это ни к чему не приведёт.

Также у нас в продукте есть боковое меню, которое отображается у полноэкранной ошибки. Но это динамический контент (зависит от роли Пользователя), поэтому при сбое Клиента его отображать не следует.

Пользователи нашего продукта – банковские сотрудники. Они тесно общаются с техподдержкой, которая может отследить любые действия и сбои в процессах. Большинство пользователей не знает техническую суть бизнес-процесса – им это для работы не нужно. Важнее подсказать, куда обратиться и что сообщить, чтобы сотрудник техподдержки быстрее нашёл и решил проблему.

Результат валидации данных

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

Текст таких «глобальных» ошибок валидации мы занесли в библиотеку. Это просто таблица из двух колонок: ситуация / текст ошибки.

Кусочек таблицы с текстами для глобальных ошибок

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

Кусочек таблицы с грамматическими конструкциями для ошибок

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

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

Конструкция
Загрузите до [кол-во] файл(-ов) до [число] МВ в формате [формат], [формат] или [формат]

Итог
Загрузите 1 файл до 100МВ в формате .docx, .pdf или .xlsx

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

Бывают редкие ошибки (особенно у групп полей), которые не описать конкретной грамматической конструкцией. Обычно они встречаются в двух-трёх сценариях, не больше. Мы условились формулировать их просто, в настоящем времени. Если упоминаем какие-то сущности, то указываем конкретно. Например:

В библиотеку такие тексты мы не заносили. Пользуемся общими рекомендациями к формулировке.

Потеря связи с Сервером

В прошлый раз мы определили для всех контекстов этой ошибки конкретный элемент отображения на экране. В него помещается разный текст в зависимости от ситуации:

• пропал интернет,
• интернет есть, но Сервер не отвечает.

Например, если связь с Сервером потерялась, когда Пользователь хотел отправить форму, мы покажем вверху страницы компонент banner.

Текст в первом случае: «Нет подключения к Интернету». Во втором – «Связь с сервером прервана. Проверьте подключение к Интернету и VPN или обратитесь к администратору.»

Тот же самый текст отображается в модальном окне.

Результат обработки данных и команд

Коды состояния и их смысл

Ещё раз вспомним: ответ от Сервера всегда приходит в виде трёхзначного кода состояния и краткого текстового пояснения. Коды, указывающие на ошибку, начинаются на 4 и 5. У каждого есть смысл.

Чтобы не наделать лишнего, я бы посоветовала сначала пройтись с разработчиками по всему списку кодов состояния и оставить те, которые могут появиться в вашем продукте. Например, ошибка 402 Payment required появится только там, где есть онлайн-оплата.

Попросите разработчиков простыми словами объяснить:

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

Например:

Ошибка 403 Forbidden
У пользователя нет прав для просмотра этой страницы/контента. Или нет прав для совершения этого действия. Техническая суть ошибки может быть разной:
– пользователю забыли назначить право на просмотр веб-ресурса;
– у пользователя отобрали право выполнять какое-то действие;
– неправильно указаны DNS-серверы сайта и т.д.
Но для большинства пользователей важна лишь суть: «Ага, у меня нет доступа к этой странице. Что мне сделать, чтобы его получить?»

Ошибка 503 Service Temporarily Unavailable
Сервер работает, но очень медленно и с перебоями. Он в состоянии обработать пару лёгких запросов, но с подавляющим большинством задач не справится. Технически причиной может быть:
– слишком большое количество одновременных запросов;
– зависание скриптов;
– сбои при передаче данных и т.д.
В зависимости от роли пользователя эта информация может ему и пригодиться, и нет. Например, если это «обычный» пользователь системы (у нас это банковский менеджер), то ему важнее понять, куда нажать или кому писать, чтобы всё починилось. А если это сотрудник дирекции безопасности, то ему нужны технические подробности.

Так у вас сложится понимание, какие коды состояния стоит пояснить конкретно. С остальными можно поступить по-разному:

• отображать у всех один и тот же общий текст с рекомендациями;
• отображать общий текст и код ошибки;
• отображать только факт ошибки и рекомендации и т.д.

Кстати, валидационные ошибки тоже приходят с кодом состояния (обычно 400 или 409). Но я их выделила в отдельную группу, потому что подход к выбору элемента и текстам другой.

Текстовые токены для ошибок

Каждая ошибка обработки данных отображается в разных элементах в зависимости от контекста. Допустим, у вас в продукте это полноэкранная ошибка, алерт и нотификация – 3 способа. Вы решили подробно описывать ошибки 403, 404, 500 и 503, а остальные отображать одинаково. Это 5 ситуаций. Итого 15 вариантов контента.

Можно расписать все 15 вариантов. Так я и думала сделать вначале. Потом предположила: что если появится ещё один способ отображения ошибки? Или мы решим описать подробно больше ошибок? Как объяснить другим дизайнерам подход к формулировке текстов? Захотелось систематизировать. Мы решили использовать текстовые токены – кусочки фраз, из которых можно собрать любой элемент отображения ошибки.

Разберём на примере ошибки 500 Internal Server Error

Сервер на действия Пользователя ответил кодом состояния 500. К этому событию мы можем «привязать» какие угодно другие события, действия и параметры.

К событию «ошибка 500» у нас привязаны следующие действия:

• назначить параметру error-title значение Произошла техническая ошибка ;
• назначить параметру error-message-full значение Попробуйте перезагрузить страницу. Если ошибка остаётся, обратитесь к администратору. Сообщите, когда возникла ошибка и что вы делали до этого. ;
• назначить параметру error-message-short значение Произошла техническая ошибка. Попробуйте ещё раз. ;
• назначить параметру error-action-primary значение Перезагрузить ;
• назначить параметру error-action-secondary значение Вернуться назад ;

Эти параметры – не общепринятые. Мы создали их у себя в системе. Таким образом, вместе с событием «ошибка 500» мы получаем конкретные значения некоторых параметров. Эти значения подставляются в элемент отображения ошибки.

Например, шаблон полноэкранной ошибки выглядит так:

• В заголовок подставляем значение параметра error-title .
• В пояснительную инструкцию подставляем значение параметра error-message-full .
• В primary-кнопку подставляем значение параметра error-action-primary .
• В secondary-кнопку подставляем значение параметра error-action-secondary .

Получилось такое полноэкранное отображение ошибки 500:

А если ошибка 500 возникла при открытии модального окна, мы решили не отображать действия. Только заголовок со значением error-title и alert со значением error-message-full.

При попытке, скажем, скачать файлы мы отображаем короткую текстовую строку под элементом. Используем значение параметра error-message-short.

Мы расписали значения параметров для каждой ошибки и просто комбинируем/подставляем в соответствующий элемент.

Кусочек таблицы с текстовыми токенами для кодов состояния

Как это всё вместе работает

Когда у нас в системе возникает ошибка мы определяем её вид и контекст. Выбираем по схеме элемент отображения ошибки. Дальше:

• Если это сбой Клиента – берём зафиксированный текст и подставляем в шаблон полноэкранной страницы без меню;
• Если это ошибка валидации данных – берём текст или грамматическую конструкцию из библиотеки и подставляем в компонент;
• Если нет связи с Сервером – берём зафиксированный текст и подставляем в компонент;
• Если это ошибка обработки данных – подставляем в элемент/шаблон отображения текстовые токены в зависимости от кода состояния.

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

• Дизайнер собирает макет. Пробегается по схеме, вставляет в макет нужный элемент. Подставляет текст из библиотеки или заполняет грамматическую конструкцию.
• Разработчик пишет код, а макета нет. Не беда – смотрит в схему и библиотеку текстов. Можно скинуть дизайнеру скриншот, что получилось (чаще всего всё правильно).
• Тестировщики и аналитики нашли несоответствие в спецификации/в макетах/в коде/на проде. Тоже не беда – есть источник правды в Ноушене.

Вот и всё. Мне как дизайнеру понравилось копаться в технических процессах. А вам? Поделитесь мыслями и замечаниями, чем помогло, как вы дизайните ошибки в своём продукте – буду рада!