В этом посте о проектировании уведомлений в мобильном приложении StarSmile

В этом посте о проектировании уведомлений в мобильном приложении StarSmile

Когда в продукте появляется раздел уведомлений, его легко собрать как одну общую ленту.

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

В проекте StarSmile у нас в уведомлениях оказалось сразу несколько разных типов уведомлений.

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

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

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

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

Я стараюсь определить:

— это временное информирование или рабочее событие;

— должно ли уведомление исчезать само;

— ведёт ли оно в другой модуль;

— нужно ли хранить его как часть истории;

— сохраняет ли оно ценность после появления следующего события.

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

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

— что делать с уведомлением, которое уже потеряло актуальность, но пользователь его не открывал?

— нужны ли фильтры, группировка или другие механики работы с лентой?

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

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

Дизайнер на всю голову