Уведомления в личном кабинете: что сообщать клиенту и как не перегрузить его

Как клиент отличит важное сообщение от очередной новости?

Неразобранный поток уведомлений скрывает сообщение, ради которого клиенту действительно нужно вернуться в заказ. Центр уведомлений стоит строить вокруг событий и действий, а не вокруг заметного значка с растущим счётчиком. Рассмотрим кабинет магазина с повторными покупками: здесь появляются документы, вопросы по заказу и служебные сообщения. Список внутри сайта помогает вернуться к заказу, тогда как электронные рассылки требуют отдельного решения.

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

Не каждое изменение превращается в отдельную строку

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

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

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

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

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

Рабочий состав записи

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

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

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

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

Когда сообщение считать прочитанным и когда решённым

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

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

Разные устройства и повторный вход

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

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

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

Новые сообщения заметны без захвата внимания

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

Для спокойного подтверждения W3C приводит приём role="status". У него подразумевается aria-live="polite": сообщение не стремится немедленно прервать текущую речь программы чтения. Названия полезно передать исполнителю, чтобы просьба сделать уведомление заметным не закончилась переносом фокуса на каждую новую строку списка. Покупатель не теряет место в форме из-за подготовленного в фоне документа.

Озвучивание и визуальная срочность

В той же технике ARIA22 упоминается aria-atomic="true", позволяющее представить сообщение целиком. Число без пояснения плохо объясняет, что изменилось. Вместо одного нового значения счётчика человеку полезно услышать смысл: появились непрочитанные сообщения. Окончательный текст выбирают коротким и проверяют в используемой программе чтения, чтобы список не превращался в бесконечный речевой поток после каждого технического обновления страницы. Если список обновляется целиком, отдельно принимают повторное озвучивание, чтобы программа не читала все прежние строки при каждом новом событии и человек мог пользоваться кабинетом без постоянного прерывания работы из-за обычного фонового обновления данных магазина.

Срочное оповещение не равно диалогу. В шаблоне Alert W3C сообщение не забирает клавиатурный фокус. Там же отмечен риск слишком частых прерываний. Поэтому предупреждение оставляют действительно значимому событию, а обычный документ попадает в спокойный список, где клиент сам решает, когда открыть подробности.

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

Проведите одно событие через весь кабинет

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

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

Короткий лист результата

• Клиент понимает тему до открытия подробностей.
• Повтор события не создаёт бессмысленных дублей.
• Прочтение сохраняется после входа с другого устройства.
• Нерешённый вопрос остаётся доступным после ознакомления.
• Файл и текст недоступны чужому кабинету.
• Новое сообщение не уводит ввод из текущего поля.
• Закрытие всплывающей подсказки не уничтожает историю события.

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

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