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

Пользователю приходили триггерные уведомления на события, которые инициирует сам пользователь, точнее его действия, например когда создаёт новый Заказ покупателя или не оплачивает счёт в указанный срок, или на складе заканчивается какой-нибудь товар (оформляется Отгрузка с товаром → товар списывается с остатков → товара меньше, чем указано в настройках неснижаемого остатка).
Уведомления могли приходить на мобильный телефон, на почту и браузерными пушами. Почту и телефон как канал поставки как правило не использовали, их нужно было подключать через настройки. Браузерные пуши как канал поставки вообще не присутствовали в настройках — их нельзя было ни отключить, ни подключить. По умолчанию они были подключены. Но так как у многих пользователей браузерные пуши часто выключены в настройках браузера, пользователи уведомления не получали, и могли узнавать о том, что что-то произошло, только из ленты уведомлений.
При этом могли возникнуть ситуации, когда пользователя критически важно предупредить, например, что отключилась связь с маркетплейсами, и он больше не может работать, соответственно зарабатывать деньги.

Поэтому определили, что

1. Будем делать короткие всплывающие уведомления внутри сервиса, которые не зависят от настроек браузера. Уведомления на события можно отключить и подключить в настройках, критически важные уведомления отключить нельзя.
2. Уведомления должны быть визуально разными, чтобы по внешнему виду пользователь сразу понимал, в уведомлении содержится важная информация или тривиальная — нужно бросать все дела и читать уведомление или это подождёт. Также решили делать разное поведение у уведомлений в зависимости от типа — неважные уведомления всплывали и исчезали через 2 секунды, важные (мы их назвали "закреплённые") висели, пока пользователь сам их не скроет.
3. Дадим возможность продуктовым командам создавать уведомления через CMS, чтобы предупредить своего пользователя о важных изменениях в работе сервиса, например, что какой-то функционал временно не работает, или становится платным.
4. Чтобы пользователям не начали приходить уведомления по поводу и без — сделать таргетинг на уведомления, которые рассылаются через CMS, т.е. на которые пользователь "не подписан", которые не может отключить через настройки уведомлений.