Как позволить пользователям выбирать, когда и как часто ИИ связывается с ними
Люди должны иметь возможность решать, может ли ИИ связываться с ними, какие типы сообщений он может отправлять и когда эти сообщения могут приходить. Продуманный интерфейс начинается с явного согласия на получение сообщений (opt-in), позволяет настраивать расписание и частоту, разделяет действительно разные типы сообщений и обеспечивает быстрый доступ к элементам управления паузой и отключением. Он также поясняет выбранный часовой пояс и факторы, способные повлиять на доставку. Эти настройки дают четкое обещание, и системы планирования и доставки продукта обязаны его выполнять.
Начните с четкого и необязательного согласия (opt-in)
Запрашивайте разрешение тогда, когда человек понимает, на что именно он соглашается. Опишите виды взаимодействия простым языком: например, напоминание, запрошенное пользователем, или периодическое обновление. Укажите, куда оно придет и как часто может отправляться. Не ограничивайтесь стандартным системным запросом разрешений операционной системы без пояснений: людям необходимо знать, что именно приложение хочет отправлять, прежде чем принять решение.
Дизайн-система веб-сайтов США (U.S. Web Design System) рекомендует собирать предпочтения по контактам только для тех каналов, которые сервис действительно может поддерживать, и по возможности разъяснять условия и ожидаемые сроки связи. В контексте ИИ-продукта это означает показ только реальных вариантов доставки с указанием назначения каждого из них. Не делайте согласие на получение уведомлений условием использования не связанных с ними функций. USWDS: Contact preferences
Относитесь к согласию как к выбору, который пользователь может пересмотреть в любой момент. Руководство Apple по уведомлениям рекомендует предусматривать понятный механизм включения и отключения для разных типов уведомлений, а также управление этими параметрами внутри самого приложения. Продукт может следовать этому принципу с помощью страницы настроек, которая наглядно суммирует текущий выбор, избавляя человека от необходимости блуждать по системным настройкам устройства, чтобы разобраться в расписании самого приложения. Apple: Managing notifications
Сделайте расписание конкретным
Позвольте людям выбирать временной интервал, соответствующий их распорядку дня: например, по будням с 18:00 до 20:00 или повторяющееся время в определенные дни недели. Отображайте дни вместе со временем начала и окончания. Если элемент управления задает «окно связи», поясните, может ли сообщение прийти в любой момент внутри этого интервала или в строго определенное время. Если в заданный день подходящих сообщений нет, уточните, пропускает ли система этот день или переносит отправку на потом.
Практичный дизайн может предложить несколько понятных готовых шаблонов, таких как «раз в неделю» или «по будням», параллельно предоставляя возможность настроить индивидуальный график, если продукт это поддерживает. Шаблон должен разворачиваться в наглядное расписание, а не оставаться двусмысленной надписью. Например, вариант «еженедельно» должен показывать выбранный день и время, а «до трех раз в неделю» — уточнять, является ли число три строгим лимитом или ориентиром. Это рекомендация по проектированию интерфейса: документация платформы поддерживает доставку по расписанию, но правила отправки определяет и описывает сама команда продукта.
Будьте предельно точны с часовыми поясами. Обозначайте расписание с привязкой к конкретному географическому названию или текущему местному часовому поясу устройства и сообщайте пользователям, меняется ли расписание при поездках или остается привязанным к исходному поясу. Простое указание смещения относительно UTC может ввести в заблуждение при переходе на летнее время или изменении законодательства о часовых поясах. База данных часовых поясов IANA фиксирует правила для различных локаций и обновляется с учетом решений государственных органов, включая корректировки смещений и правил сезонного перевода часов. IANA: Time Zone Database
Пример удачного подтверждения: «По вторникам в 19:00 по вашему текущему местному времени. Расписание адаптируется к часовому поясу вашего устройства». Такая формулировка корректна только в том случае, если реализация действительно отслеживает текущий пояс пользователя. Если же расписание жестко зафиксировано за выбранным поясом, укажите название этого региона. Когда человек путешествует или пояс устройства меняется, отобразите действующее расписание и предоставьте возможность проверить его.
Разделяйте типы сообщений и каналы
Людям могут быть интересны одни типы контактов и совсем не нужны другие. Сделайте необязательные напоминания, новости продукта и другие отдельные категории независимо настраиваемыми, вместо того чтобы объединять их под единым переключателем «Уведомления ИИ». Не создавайте фиктивные категории, за которыми не стоит реального поведения продукта, и не используйте их как предлог для отправки сообщений, на которые пользователь не подписывался.
Такое разделение согласуется и со стандартными элементами управления платформ. Современные версии Android требуют привязки уведомлений к каналам, и пользователи могут менять их поведение; руководство Android рекомендует использовать каналы, позволяющие гибко настраивать входящие уведомления. Приложение может называть каналы понятными терминами, например «Запланированные напоминания», и описывать, что относится к каждому из них. Android Developers: Create and manage notification channels
Список каналов должен оставаться достаточно коротким и понятным. Каждый канал должен представлять собой значимый выбор, который человеку может понадобиться сделать отдельно. При этом собственные настройки продукта все равно должны объяснять содержание и график: системные параметры каналов ОС могут определять факт или форму появления уведомления, но они не объясняют общую политику отправки и не заменяют встроенное расписание внутри продукта.
Размещайте функции паузы, возобновления и отключения под рукой
Предложите варианты временной паузы и полного отключения. Для паузы следует явно указывать длительность — например, до определенной даты или до возобновления пользователем — и пояснять, отменяются ли запланированные сообщения или откладываются. Элемент выключения должен сообщать, на какие категории или каналы он влияет, и мгновенно подтверждать изменение статуса. Возобновление работы не должно незаметно возвращать прежний график без уведомления о том, что произойдет дальше.
Сделайте эти настройки доступными на экране параметров уведомлений, а по возможности — прямо из действия в уведомлении или по прямой ссылке. Android поддерживает интерактивные действия в уведомлениях и дает системные инструменты управления будущими оповещениями, набор которых зависит от устройства и версии ОС. Поэтому встроенный раздел настроек в самом приложении по-прежнему необходим, чтобы отображать полное расписание и изменять предпочтения на уровне продукта. Android Developers: Notifications
Контроль на уровне самого устройства сохраняет решающее значение. Пользователь может отключить уведомления приложения или изменить поведение каналов на уровне операционной системы, независимо от расписания внутри приложения. Интерфейс не должен создавать впечатление, будто внутрипрограммная настройка отменяет эти системные ограничения. Если уведомления отключены в ОС, отобразите четкий статус при переходе пользователя в настройки и избегайте навязчивых повторных просьб включить их обратно.
Установите лимит частоты, который система способна соблюдать
Предоставьте пользователям прямой выбор частоты: например, не более одного сообщения в день, недельный максимум или выбранное пользователем количество дней. Четко определите расчетный период и то, что именно считается отдельным сообщением. Если отправка идет по нескольким категориям, уточните, действует ли лимит на каждую категорию отдельно или на весь продукт в целом. Лимит для отдельных категорий может приводить к высокой суммарной нагрузке, поэтому продуманный интерфейс часто предусматривает общее ограничение.
Лимит работает только в том случае, если его учитывают абсолютно все каналы отправки. Сверяйте с заданными настройками пользователя запланированные напоминания, повторные попытки, отложенные сообщения и отправления, инициированные различными функциями. Если доставка задерживается, решите, истекает ли срок действия сообщения, отправляется ли оно позже в пределах разрешенного интервала или отменяется вовсе; объясните пользователю значимые для него детали поведения. Избегайте одновременной отправки нескольких накопившихся сообщений сразу после восстановления связи на устройстве, если пользователь явно не выбрал такой вариант.
Доставка на уровне платформы отличается от решения продукта об отправке. Согласно документации Firebase Cloud Messaging, сообщения обычно доставляются мгновенно, однако устройство может быть недоступно, а доставка — отложена; сервис может сохранять сообщение и пытаться доставить его позже в течение заданного срока жизни. Это означает, что продукт не должен обещать появление каждого уведомления с точностью до минуты. Он может гарантировать запуск отправки в рамках оговоренного окна, предупреждая, что состояние устройства и платформы может повлиять на фактическое время появления. Firebase: Set the lifespan of a message
Это различие сказывается и на частоте. Если уведомление стояло в очереди и приходит с опозданием, система должна проверить, не поставил ли пользователь эту категорию на паузу, не отключил ли ее и не превысит ли отправка текущий лимит. Добросовестный интерфейс отменяет или блокирует устаревшие сообщения в очереди, если последний выбор пользователя делает их неактуальными.
Простая последовательность решений при проектировании
Используйте эту последовательность, чтобы превратить настройки в понятные обязательства перед пользователем:
Назовите типы сообщений, которые продукт действительно может отправлять, и четко сформулируйте назначение каждой дополнительной категории.
Запросите явное согласие пользователя на каждую желаемую категорию и канал доставки. Не включайте необязательные контакты по умолчанию.
Позвольте пользователю выбрать дни, конкретное время или временной интервал, а также максимальную частоту. Уточните, действует ли ограничение на весь продукт или на каждую категорию в отдельности.
Отобразите часовой пояс и укажите, адаптируется ли расписание при изменении пояса на устройстве пользователя.
Обеспечьте легкий доступ к элементам паузы, возобновления и отключения, отображая текущее состояние и ближайшее разрешенное время контакта.
Перед отправкой повторно проверяйте расписание, лимит, статус паузы и настройки категорий. Учитывайте вероятность задержки на уровне устройства и формулируйте обещания продукта в рамках того, чем он реально может управлять.
Лаконичная сводка параметров поможет легко сверить договоренности: «Запланированные напоминания: включены. Вторник и четверг, 19:00–20:00 по местному времени. Максимум: два в неделю по всем категориям. Приостановить или отключить можно в любой момент». Предлагаемые опции должны отражать реальные технические возможности; если продукт не в состоянии надежно выдерживать отображаемый лимит или следовать местному времени, следует изменить техническую реализацию или сузить обещания до вывода таких настроек на экран.