В этом посте рассказываю о проектировании уведомлений в сложных ERP-системах

В этом посте рассказываю о проектировании уведомлений в сложных ERP-системах.

Когда в продукте появляется лента уведомлений, её часто строят на привычной модели: «прочитано» или «не прочитано». Для простых приложений этого достаточно, но в сложных системах (например, в стоматологической ERP, над которой я сейчас работаю) такой подход быстро перестает работать: все эти уведомления становятся своеобразной «цифровой сыпью».

Проблема в том, что в ERP один и тот же статус пытается означать слишком много вещей сразу. Метка «не прочитано» одновременно сообщает, что событие новое, что его не открывали и что оно требует внимания или действия. В какой-то момент эти смыслы перестают совпадать.

Например, врач получает уведомление о том, что заказ перешел в производство. Он видит пуш или заголовок в списке — суть изменения ему уже ясна. Но само уведомление он не открывал, и в системе оно висит как «непрочитанное», хотя ценность сигнала уже потеряна.

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

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

В ERP-системе пользователь работает с заказами, их статусами и всей последовательностью изменений. Поэтому задача системы состоит в том, чтобы вовремя показывать значимое изменение в процессе, а не сводить взаимодействие к формальному клику по уведомлению. #уведомления #медицина #проект

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