Сообщения, о которых нужно помнить UX-дизайнеру


26.08.2021 Время чтения - 4 минуты 886

Рассмотрим такой сценарий: UX-дизайнер заканчивает дизайн и приходит с ним к разработчиками. На вид все прекрасно и, очевидно, ничего не упущено, поэтому дизайн начинают реализовывать. В процессе разработки возникают вопросы – что будет, если пользователь сойдет с продуманного пути? Какие сообщения отображать, чтобы сообщить ему об успешном действии? Как рассказать пользователям о состоянии системы, если что-то пошло не так? Как мы можем помочь им восстановиться после ошибки? 


Читайте нас в Telegram.


Будем надеяться, что разработчики обратятся к дизайнеру (или UX-райтеру) и поработают над созданием этих сообщений. В худшем случае они напишут их сами, сделав их сложными и запутанными.

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

5 типов сообщений, которые нужно помнить при разработке

  1. Подтверждающие сообщения
  2. Сообщения об успехе
  3. Предупреждающие сообщения
  4. Сообщения об ошибках
  5. Системные сообщения

Подтверждающие сообщения

Это сообщения, требующие от пользователей подтверждения действия, которое они пытаются выполнить. Когда пользователь выполняет действие обновления, обычно нет необходимости отображать подтверждающее сообщение (если это не критическое изменение), но вы должны отображать их, когда они:

  • Удаляют элемент (например: «Вы уверены, что хотите удалить?»)
  • Пытаются выйти из экрана с несохраненными изменениями (например: «Вы хотите сохранить изменения?»)
Подтверждающее сообщение – Microsoft Word

Используйте этот тип сообщения только для передачи информации, которую пользователи должны подтвердить до завершения действия. Делайте это осторожно, чтобы не тормозить действие ненужным подтверждением.

Сообщения об успехе

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

  • Успешно удалено
  • Товар обновлен
  • Изменения сохранены

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

Сообщение об успешном завершении Gmail – беседа заархивирована. 
Отменить

Предупреждающие сообщения

Иногда пользователь пытается выполнить действие, которое вызовет обновления в других частях системы или другие критические изменения. В таких ситуациях можете использовать предупреждающее сообщение. Они информируют человека о последствиях его действий, которые в противном случае можно не сразу понять. 

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

Предупреждающее сообщение Microsoft Excel

Сообщения об ошибках

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

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

Сообщение об ошибке

Системные сообщения

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

Убедитесь, что ошибки HTTP перехватываются и для пользователя отображается что-то удобное. Объясняющее, что на самом деле означает 403 (запрещено), 404 (не найдено), 503 (сервис недоступен) и т. д. 

Эти сообщения должны подсказывать пользователю, как выполнить восстановление (например, попробуйте еще раз позже, или проверьте правильность написания, или используйте поиск, чтобы найти страницу в случае 404).

404 в браузере
Дружественное сообщение 404, объясняющее пользователю, как восстановиться

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

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

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

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

Оригинал.

Читайте также: Ваш UI-дизайн неаккуратный? 7 частых ошибок, которых можно избежать


Читайте нас в Telegram.