Как проектировать системы уведомлений в приложениях: дизайн, этапы и нюансы архитектуры

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

С проектированием системы уведомлений мы впервые столкнулись на одном из проектов, где потребовалось не просто нарисовать визуальные элементы, но и продумать, как устроена вся структура. С чем работали и какие выводы сделали — рассказываем в материале. Дисклеймер: многие термины мы придумали сами, чтобы понятнее объяснить суть.

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

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

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

Одновременно с этим не каждый пуш, приходящий извне, вызывает уведомление. Например, в Android есть беззвучные пуши (silent push): они нужны для внутренних системных оповещений приложения о том, что что-то произошло, но пользователь об этом не знает.

Есть обязательные, или постоянные, составляющие уведомлений:

А есть опциональные:

А теперь подробнее.

Уведомление не может образоваться в вакууме — что-то его вызывает. Можно выделить три основных триггера.

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

Проектируя систему уведомлений, важно фокусироваться на общей картине — целом сценарии, а не отдельных оповещениях.

Понять, в каких случаях нужна коммуникация с пользователем, поможет карта экранов. Чтобы впоследствии правильно передать дизайн в разработку, важно понимать, куда пользователь переходит по ссылке, то есть по пушу или кнопке в UI-элементах. Для внутренней работы на одном из проектов мы использовали табличку со взаимосвязями, но для согласования с клиентом лучше делать большие схемы и показывать наглядно.

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

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

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

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

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

Часто уведомление — это артефакт, который быстро масштабируется, и им становится сложно управлять. Поэтому, в зависимости от приоритета задачи, он может проходить через несколько этапов согласований. Это тоже нужно учитывать на старте проектирования.

Разберём, что нужно сделать, чтобы в приложении появились уведомления.

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

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

Важно помнить, что для каждого продукта или проекта список необходимых атрибутов адаптируется.

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

В проекте было две важных особенности.

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

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

Напоследок — немного о тонкостях архитектуры.

Backend в Android и iOS устроен таким образом, что не посылает ничего напрямую: он взаимодействует с отдельным сервисом, который разработан специально для работы с уведомлениями. У iOS это сервис APNs (Apple Push Notification Service), у Android их два: официальный сервис Google Firebase и пуш-сервис от Huawei.

Как это устроено? На уровне системы девайс (в нашем случае — смартфон на Android или iOS) оснащён специальным сервисом, который умеет работать с уведомлениями — получать и взаимодействовать с ними через одну из сторонних программ.

Этот внутренний сервис «живёт» дольше, чем приложение, которое через какое-то время уходит в бэкграунд и перестает функционировать, и может держать контакт с сервисом уведомлений — именно через него Backend их отправляет.

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

Ещё один важный нюанс: любое уведомление в Android можно сделать локально (у iOS также есть дефолтные уведомления, которые могут появляться без участия приложений, но сейчас не о них). Например, таймеру не нужен Backend — само приложение может создать уведомление без пуша и сообщить, сколько времени прошло. Стоит подробно проговаривать с разработчиками, если есть потребность в таких уведомлениях.

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

А ещё мы не можем узнать, получил ли пользователь пуш, — система спроектирована однонаправленно.

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

Над материалом работали:

Чтобы ничего не пропустить, следи за развитием цифры вместе с нами:

Да пребудет с тобой сила роботов! 🤖