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

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

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

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

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

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

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

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

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

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

1. Действие. Например, кто-то из друзей опубликовал пост, и пользователь получил оповещение об этом.

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

3. Завершающее событие. Этот вид триггера можно разделить на два подвида: когда уведомление приходит либо определённое количество раз, либо до тех пор, пока не произойдёт событие, о котором оно напоминает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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