Уведомления

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

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

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

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

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

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

Хорошее уведомление сочетает три базовых принципа:

  • Релевантность — сообщать только то, что важно пользователю.
  • Своевременность — приходить в нужный момент.
  • Ясность — говорить однозначно и лаконично.

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

Релевантность

Релевантное уведомление не вызывает вопроса «почему я получил это сообщение?». Пользователь сразу понимает, зачем ему эта информация.

Чтобы сделать уведомление релевантным:

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

Неправильно

Не связано с контекстом пользователя и не объясняет, почему сообщение адресовано именно ему

Правильно

Понятно, кто инициировал событие и почему уведомление получил именно этот пользователь

Неправильно

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

Правильно

Уведомление явно связано с пользователем и его работой в сервисе

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

Своевременность

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

Чтобы коммуникация была своевременной:

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

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

Неправильно

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

Правильно

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

Допустимо, но можно лучше

Несколько сообщений подряд об одной категории событий

Лучше

Несрочные события объединены

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

Ясность

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

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

Чтобы сделать уведомление понятным:

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

Неправильно

Главная мысль теряется среди деталей. Чтобы понять, что произошло, пользователю приходится дочитывать уведомление до конца

Правильно

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

Неправильно

Неясно, насколько это срочно и чем грозит

Правильно

Понятно событие, срок и действие

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

Неправильно

Реклама замаскирована под значимое для пользователя событие

Вместо уведомлений

Прежде чем отправить уведомление, проверьте, есть ли возможность донести информацию через интерфейс.

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

Примеры возможных паттернов:

  • статус — если нужно показать текущее состояние объекта;
  • бейдж — если нужно обратить внимание на новую возможность или изменение в интерфейсе;
  • тост — если нужно кратко сообщить результат действия пользователя;
  • обучающий тур — если нужно познакомить пользователя с новой функцией или сценарием;
  • изменение состояния элемента — если информация относится непосредственно к объекту или действию.

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

Если интерфейсный паттерн позволяет решить задачу, предпочтительнее использовать его, а не уведомление.

Неправильно

Пользователь уже работает с отчётами в ФНС, но отвлекается на тост о промежуточном этапе обработки документа

Правильно

Этап обработки отображается в статусе документа и становится заметен во время работы с сервисом

Допустимо, но можно лучше

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

Лучше

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

Настройка уведомлений

Не рассчитывайте, что пользователь будет настраивать уведомления. Думать об их релевантности и полезности — это задача сервиса, а не пользователя.

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

Группируйте настройки по смыслу и сценариям. Длинный список отдельных переключателей усложняет настройку.

Неправильно

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

Правильно

Уведомления сгруппированы по смыслу и сценариям. Можно управлять уведомлениями целиком, а не отдельными переключателями