Отображение ошибок в интерфейсе, часть 1 – Как возникают ошибки

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

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

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

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

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

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

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

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

Как возникают ошибки

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

• Пользователь (человек)
• Клиент (интерфейс, «фронтенд»)
• Сервер («бэкенд»)

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

Пользователь взаимодействует с Клиентом (интерфейсом): переходит по ссылкам, заполняет и отправляет формы. Эту информацию получает Сервер, обрабатывает и отправляет ответ. Ответ «говорит» Клиенту, что отобразить на экране для Пользователя.

Веб-сервисы работают по протоколу HTTP. Ответ от Сервера всегда приходит в виде трёхзначного кода состояния (status code) и краткого пояснения. Например: 404 Not Found, 500 Internal Server Error. Вместе с кодом состояния Сервер может передать какие-то данные и дальнейшие команды.

Всего есть 5 групп кодов состояния. Они начинаются на 1, 2, 3, 4 и 5 соответственно. Нас интересуют коды 4__ и 5__ – это ответы Сервера, которые указывают на ошибку. Коды 1__, 2__ и 3__ – условно «положительные». Они двигают процесс дальше.

У каждой ошибки есть смысл и обстоятельства появления. Если рассмотреть все комбинации этих характеристик, можно для каждой зафиксировать:

• в каком элементе интерфейса отображаем ошибку;
• как и в каком месте экрана он появляется;
• какой контент в нём отображается.

Что мы и сделаем дальше.

Виды ошибок

С точки зрения взаимодействия между субъектами Пользователь – Клиент – Сервер можно выделить такие виды ошибок:

• сбой Клиента;
• результат валидации данных на Клиенте и Сервере;
• результат обработки данных и команд;
• потеря связи с Сервером.

Разберём подробнее, что к чему.

Сбой Клиента

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

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

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

Допустим, Пользователь заполнил и отправил форму. Прежде чем передать введённые данные Серверу, нужно проверить, правильно ли они заполнены. Иначе Сервер не сможет их корректно обработать.

Такая проверка происходит на стороне Клиента: допустимые символы, количество символов, наличие обязательных данных.

Если всё в порядке, данные передаются Серверу.

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

Пример
Пользователь регистрируется в системе и создаёт логин. Можно использовать только латинские буквы и цифры, а Пользователь вводит leonid!!!. После валидации на Клиенте отобразится ошибка «Используйте только латинские буквы и цифры».

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

Ошибки валидации обычно приходят в виде кода состояния 400 BadRequest или 409 Conflict и описания, в чём заключается ошибка.

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

Может случиться так, что Сервер принял данные, но не смог их обработать. Или есть конфликт между поступающими командами. Или возник сбой при передаче результата от Сервера Клиенту. Какая бы ни была проблема, Сервер отправляет код состояния, который на неё указывает. Даже если он сам «упал» – обязательно об этом сообщит.

Таких ситуаций много – это все коды состояния 4__ и 5__.

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

Это ситуация, когда от Сервера не пришёл ответ (код состояния) на действия Пользователя. Обычно это значит, что пропал интернет или есть проблемы с VPN. Но может быть и так, что Сервер просто не отвечает.

Хочу ещё раз обратить внимание: «Сервер упал» и «Нет связи с Сервером» – это разные ситуации. В первом случае у Сервера проблемы, но он сообщает об этом кодом состояния. Во втором случае от него вообще нет ответа.

Контексты появления ошибок

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

Эти обстоятельства – суть процесса, во время которого обнаружилась ошибка:

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

Итого

Мы выделили 4 вида ошибок и 4 контекста их появления. Выходит, что всего есть 16 ситуаций, которые нужно «закрыть» дизайн-решениями. Сделаем это в следующей части:

Отображение ошибок в интерфейсе, часть 2 – Выбор способа отображения ошибки в интерфейсе

P.S. Почему мы сделали гайд по ошибкам

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

• маленькая постоянная команда (< 20 человек), один дизайнер;
• продукт создан командой с нуля;
• группы схожих пользовательских сценариев;
• дизайн-процесс включал сборку всех возможных состояний экранов (в т.ч. с ошибками);
• некритично, но ощутимо мало дизайн-ресурса.

Изначально я хранила правила отображения ошибок в Фигме. Это не создавало проблем. Я хорошо ориентировалась в проекте, а в новых сценариях использовала паттерны из реализованных. Бывало, пропускала пару экранов с ошибкой – тогда разработчики писали в личку, и я собирала нужный макет. Думаю, благодаря тому, что постоянная маленькая команда делала продукт с самого начала, мы как бы «и так всё знали об ошибках».

Однажды проект быстро наполнился более сложными сценариями. Команда разработки увеличилась в два раза, появился ещё один дизайнер. Моё внимание начало рассеиваться. Разработчики и тестировщики стали задавать больше вопросов, особенно новоприбывшие. Я обнаружила проблемы, которые не видела раньше, и выделила новые:

• Команда по-разному говорит
  «Сервер упал», «не получили контент», «связь прервалась» – неясно, об одном ли техническом процессе мы говорим. И корректно ли объясняем его пользователю – тоже неясно. Также мы, дизайнеры, не уверены, что обработали все возможные случаи ошибок. Нужно подобие чеклиста.
• Всё больше багов в отображении ошибок
  Либо на эти макеты нет времени, либо дизайнеры не успевают проверить, чтобы в соседних сценариях одна ошибка отображалась одинаково. В общем, ресурсная западня. Нужен способ быстро, однозначно, не отвлекая друг друга определиться, как отображается ошибка.
• Тяжело погружать новичков
  Пытаясь объяснить, как в продукте отображаются ошибки, я путаюсь и сомневаюсь, что знаю, о чём говорю. Нужно подтянуть технические знания и опереться на них.

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

• аналитики, чтобы учесть все ситуации ошибок в спецификации и проверить тексты;
• дизайнеры, чтобы собрать корректный макет без лишней коммуникации;
• разработчики и тестировщики, чтобы реализовать и проверить отображение ошибки. А иногда обойтись без дизайнера, если недостаёт макетов.