Come consentire agli utenti di scegliere quando e con quale frequenza un'IA può contattarli
Le persone dovrebbero poter decidere se un'IA può contattarle, quali tipi di messaggi può inviare e quando questi messaggi possono arrivare. Un design efficace parte da un consenso esplicito (opt-in), consente di impostare orari e frequenza, separa tipologie di messaggi realmente differenti e rende i comandi di pausa e disattivazione facili da trovare. Spiega inoltre il fuso orario selezionato e cosa potrebbe influire sulla consegna. Questi controlli costituiscono una promessa chiara; i sistemi di pianificazione e consegna del prodotto devono essere in grado di mantenerla.
Inizia con un consenso esplicito, chiaro e facoltativo
Chiedi l'autorizzazione nel momento in cui l'utente può comprendere chiaramente a cosa sta acconsentendo. Descrivi le modalità di contatto con un linguaggio semplice: ad esempio, un promemoria richiesto dall'utente o un aggiornamento periodico. Specifica dove verrà recapitato e con quale frequenza potrà essere inviato. Evita che una richiesta di autorizzazione del sistema operativo non contestualizzata sia l'unica spiegazione; le persone devono sapere cosa l'app intende inviare prima di prendere una decisione.
Il Design System del governo degli Stati Uniti (U.S. Web Design System) consiglia di raccogliere le preferenze di contatto solo per i canali effettivamente supportati dal servizio e suggerisce di spiegare, ove possibile, le condizioni e le tempistiche previste per le comunicazioni. Applicato a un prodotto di IA, ciò significa mostrare solo opzioni di recapito reali e dichiarare a cosa serve ciascuna di esse. Non rendere una preferenza di notifica un requisito vincolante per l'utilizzo di funzionalità non correlate. USWDS: Contact preferences
Considera il consenso come una scelta che l'utente può riconsiderare in qualsiasi momento. Le linee guida sulle notifiche di Apple raccomandano una chiara opzione di attivazione o disattivazione per tipologia di notifica e una sezione interna all'app per gestire tali impostazioni. Un prodotto può seguire questo principio offrendo una pagina delle impostazioni che riepiloghi le scelte attuali, evitando che l'utente debba cercare tra le impostazioni di sistema del dispositivo per capire la programmazione dell'app stessa. Apple: Managing notifications
Rendi la programmazione concreta
Consenti alle persone di scegliere una fascia oraria adatta alla loro routine, come i giorni feriali tra le 18:00 e le 20:00, oppure un orario ricorrente in giorni selezionati. Mostra i giorni insieme agli orari di inizio e fine. Se l'impostazione definisce una "finestra di contatto", spiega chiaramente se un messaggio può arrivare in qualsiasi momento all'interno di essa o a un orario specifico. Se in un determinato giorno non ci sono messaggi idonei, specifica se il sistema salterà quel giorno o rimanderà il messaggio al successivo.
Un design pratico può offrire alcune opzioni predefinite e intuitive, come "una volta alla settimana" o "giorni feriali", consentendo al contempo una pianificazione personalizzata laddove il prodotto lo supporti. Un'opzione predefinita dovrebbe tradursi in una programmazione visibile, non in un'etichetta ambigua. Ad esempio, "settimanale" dovrebbe mostrare il giorno e l'ora scelti, e "fino a tre volte a settimana" dovrebbe chiarire se il tre rappresenta un limite massimo o un obiettivo. Si tratta di una raccomandazione di design: la documentazione della piattaforma supporta l'invio programmato, ma spetta al team di prodotto definire e descrivere le proprie regole di invio.
Sii preciso riguardo ai fusi orari. Identifica la pianificazione indicando una località specifica o il fuso orario locale corrente del dispositivo, e informa gli utenti se la programmazione si adatta ai loro spostamenti durante i viaggi o se rimane vincolata alla zona originaria. La sola indicazione dell'offset UTC può risultare fuorviante in caso di modifiche all'ora legale o alle normative locali sui fusi orari. Il database dei fusi orari IANA registra le regole per le diverse località e viene costantemente aggiornato per riflettere i cambiamenti stabiliti dagli enti politici, comprese le variazioni agli offset e all'ora legale. IANA: Time Zone Database
Una notifica di conferma chiara potrebbe recitare: "Il martedì alle 19:00, secondo l'ora locale attuale. Questa pianificazione segue il fuso orario del tuo dispositivo." Tale formulazione è accurata solo se l'implementazione tecnica rileva effettivamente la posizione corrente dell'utente. Se la pianificazione rimane invece fissa su un fuso orario prestabilito, indica chiaramente la località corrispondente. Quando una persona viaggia o il fuso orario del dispositivo cambia, mostra la programmazione effettiva e offri un modo per verificarla e modificarla.
Separa canali e tipologie di messaggi
Le persone potrebbero desiderare un tipo di contatto ma non un altro. Mantieni i promemoria facoltativi, gli aggiornamenti di prodotto e le altre categorie distinte selezionabili separatamente, invece di raggrupparli sotto un unico interruttore generico come "Notifiche IA". Non inventare categorie che non corrispondono a un comportamento reale del prodotto, né creare una categoria come pretesto per inviare messaggi che l'utente non ha richiesto.
Questa separazione si allinea inoltre con i controlli delle piattaforme. Nelle versioni moderne, Android richiede che le notifiche siano assegnate a specifici canali, consentendo agli utenti di modificarne il comportamento; le linee guida di Android raccomandano l'uso di canali che permettano di personalizzare le notifiche ricevute. L'app può nominare i canali con termini familiari agli utenti, come "Promemoria programmati", descrivendo con precisione cosa appartiene a ciascuno. Android Developers: Create and manage notification channels
Mantieni l'elenco dei canali sufficientemente breve da risultare comprensibile. Un canale dovrebbe rappresentare una scelta significativa che una persona potrebbe voler gestire in modo indipendente. Le impostazioni interne del prodotto devono comunque spiegare i contenuti e la pianificazione: i controlli a livello di sistema operativo possono modificare la visualizzazione o la ricezione di una notifica, ma non spiegano la logica di invio dell'app né sostituiscono la gestione oraria interna.
Rendi facilmente accessibili i comandi di pausa, ripresa e disattivazione
Offri la possibilità di una pausa temporanea e un'opzione di disattivazione permanente. La sospensione dovrebbe indicare esplicitamente la propria durata (ad esempio fino a una data specifica o fino alla riattivazione manuale da parte dell'utente) e chiarire se i messaggi programmati verranno saltati o archiviati per dopo. Un comando di disattivazione deve specificare quali categorie o canali coinvolge e confermare immediatamente lo stato aggiornato. La riattivazione non dovrebbe ripristinare silenziosamente la programmazione precedente senza mostrare cosa accadrà in seguito.
Rendi disponibili questi controlli all'interno della schermata delle impostazioni delle notifiche e, ove opportuno, tramite un'azione direttamente dalla notifica o un link rapido alle impostazioni. Android supporta le azioni rapide nelle notifiche e offre agli utenti strumenti a livello di sistema per gestire le notifiche future; tali controlli variano a seconda del dispositivo e della versione di Android. Di conseguenza, un percorso interno all'applicazione resta essenziale per visualizzare la pianificazione completa e modificare le preferenze del prodotto. Android Developers: Notifications
I controlli a livello di dispositivo rimangono prioritari. Un utente può disattivare le notifiche di un'app o modificare il comportamento dei canali direttamente dalle impostazioni del sistema operativo, indipendentemente dalla pianificazione dell'app stessa. L'interfaccia non deve dare l'impressione che un'impostazione in-app prevalga su tali scelte. Se le notifiche di sistema sono disattivate, mostra uno stato chiaro quando l'utente accede alle impostazioni ed evita di richiedere ripetutamente la riattivazione delle notifiche.
Imposta un limite di frequenza che il sistema possa effettivamente rispettare
Offri agli utenti una scelta diretta sulla frequenza: ad esempio, al massimo un messaggio al giorno, un limite settimanale o un numero di giorni personalizzato. Definisci l'intervallo di conteggio e cosa viene conteggiato come singolo messaggio. Se più categorie possono inviare comunicazioni, chiarisci se il limite si applica alla singola categoria o all'intero prodotto. Un limite per categoria può comunque generare un volume complessivo elevato, motivo per cui un design efficace prevede spesso anche un tetto massimo globale.
Un limite funziona solo se viene rispettato da ogni canale di invio. Verifica i promemoria pianificati, i tentativi di reinvio, i messaggi posticipati e quelli generati da diverse funzionalità rispetto allo stesso stato delle preferenze. Se un messaggio subisce un ritardo, stabilisci se scade, se viene recapitato più tardi all'interno della finestra consentita o se viene annullato; spiega all'utente il comportamento previsto. Evita di inviare contemporaneamente più messaggi arretrati non appena il dispositivo torna online, a meno che l'utente non abbia richiesto espressamente questa modalità.
La consegna da parte della piattaforma non coincide con la decisione di invio del prodotto. La documentazione di Firebase Cloud Messaging evidenzia come i messaggi vengano in genere recapitati immediatamente, ma un dispositivo potrebbe non essere raggiungibile o la consegna potrebbe subire ritardi; il servizio può memorizzare il messaggio e tentare la consegna in un secondo momento entro il periodo di validità configurato. Ciò significa che un prodotto non dovrebbe promettere che ogni notifica comparirà a un minuto esatto. Può invece impegnarsi a programmare l'invio entro una fascia oraria definita, specificando chiaramente che le condizioni del dispositivo e della piattaforma possono influire sull'orario effettivo di ricezione. Firebase: Set the lifespan of a message
Questa distinzione incide anche sulla frequenza. Se una notifica è stata accodata e arriva in ritardo, il sistema deve verificare se nel frattempo l'utente ha messo in pausa o disattivato quella categoria e se l'invio comporterebbe il superamento del limite stabilito. Un design trasparente provvede ad annullare o bloccare i messaggi accodati obsoleti qualora le ultime preferenze espresse dall'utente li rendano non più idonei.
Una sequenza decisionale semplice per la progettazione
Segui questa sequenza per trasformare le impostazioni in un impegno chiaro e comprensibile per l'utente:
Identifica i tipi di messaggi che il prodotto è effettivamente in grado di inviare e rendi comprensibile ciascuna categoria opzionale.
Richiedi all'utente un consenso esplicito per ciascuna categoria e canale di consegna desiderati. Non preselezionare opzioni di contatto facoltative.
Permetti all'utente di scegliere i giorni, un orario o una finestra temporale e una frequenza massima. Specifica se il tetto si applica a livello globale o per singola categoria.
Mostra il fuso orario e indica chiaramente se la pianificazione si adatta automaticamente quando cambia il fuso orario del dispositivo.
Rendi ben visibili i controlli di pausa, ripresa e disattivazione, mostrando lo stato corrente e il momento del successivo contatto previsto.
Prima dell'invio, verifica nuovamente la pianificazione, il limite di frequenza, lo stato di sospensione e le preferenze di categoria. Considera la consegna sul dispositivo come potenzialmente soggetta a ritardi e formula le promesse del prodotto solo in base ai parametri che può effettivamente controllare.
Un riepilogo compatto delle impostazioni facilita la verifica delle scelte da parte dell'utente: "Promemoria programmati: attivi. Martedì e giovedì, 19:00–20:00 ora locale. Massimo: due a settimana per tutte le categorie. Metti in pausa o disattiva in qualsiasi momento." Le opzioni mostrate devono riflettere le capacità reali del sistema; se un prodotto non è in grado di garantire il rispetto del limite visualizzato o di seguire l'ora locale in modo affidabile, è necessario modificare l'implementazione o ridimensionare la promessa prima di presentare quel comando all'utente.