UX autorizzazioni

Matt Gaunt

Il passaggio naturale dopo aver ricevuto un PushSubscription e averlo salvato sul nostro server è l'attivazione di un messaggio push, ma c'è un aspetto che ho osservato palesemente. L'esperienza utente quando viene chiesto all'utente l'autorizzazione per inviare messaggi push.

Purtroppo, sono davvero pochi i siti che valutano come chiedono l'autorizzazione agli utenti, quindi diamo una rapida occhiata a come si crea un'esperienza utente positiva e negativa.

Sono emersi alcuni pattern comuni che dovrebbero guidarti e aiutarti a scegliere ciò che è meglio per i tuoi utenti e per il caso d'uso.

Proposta di valore

Chiedi agli utenti di abbonarsi per inviare push quando il vantaggio è evidente.

Ad esempio, un utente ha appena acquistato un articolo in un negozio online e ha completato il flusso di pagamento. Il sito può quindi offrire aggiornamenti sullo stato dell'importazione.

Questo approccio funziona in una serie di situazioni:

  • Un articolo specifico non è disponibile. Vuoi ricevere una notifica quando sarà il prossimo articolo?
  • Questa notizia dell'ultima ora verrà aggiornata regolarmente. Vuoi ricevere una notifica man mano che la storia si sviluppa?
  • Sei il miglior offerente. Vuoi ricevere una notifica se fai un'offerta superiore?

Questi sono tutti punti in cui l'utente ha investito nel servizio e c'è una chiara proposta di valore per l'attivazione delle notifiche push.

L'esempio di Owen Campbell-Moore di buona UX per le notifiche push.

creato un modello di sito web ipotetico di una compagnia aerea per dimostrare questo approccio.

Dopo che l'utente ha prenotato un volo, chiede se vuole ricevere notifiche sui ritardi dei voli.

Tieni presente che si tratta di un'interfaccia utente personalizzata del sito web.

Esempio di buona UX di Owen Campbell-Moore per il prompt di autorizzazione.

Un altro tocco di classe alla demo di Owen è che se l'utente fa clic per attivare le notifiche, il sito aggiunge un overlay semitrasparente all'intera pagina quando viene visualizzata la richiesta di autorizzazione. in modo da attirare l'attenzione degli utenti sulla richiesta di autorizzazione.

In alternativa a questo esempio, l'esperienza utente non corretta per richiedere l'autorizzazione, è possibile farlo non appena un utente arriva sul sito della compagnia aerea.

Esempio di UX errata di Owen Campbell-Moore per le notifiche push.

Questo approccio non fornisce alcun contesto sul motivo per cui le notifiche sono necessarie o utili per l'utente. L'utente non può inoltre eseguire l'attività originale (ad es. prenotare un volo) tramite questa richiesta di autorizzazione.

Autorizzazione doppia

Potresti ritenere che il tuo sito presenti un caso d'uso chiaro per i messaggi push e, di conseguenza, vuoi chiedere l'autorizzazione all'utente il prima possibile.

ad esempio i client di posta elettronica e la messaggistica immediata. Mostrare un messaggio per un nuovo messaggio o una nuova email è un'esperienza utente consolidata su una vasta gamma di piattaforme.

Per queste categorie di app, vale la pena considerare il modello di autorizzazione doppia.

Per prima cosa, mostra una falsa richiesta di autorizzazione controllata dal tuo sito web, composta da pulsanti per consentire o ignorare la richiesta di autorizzazione. Se l'utente fa clic su Consenti, richiedi l'autorizzazione, attivando la richiesta di autorizzazione del browser reale.

Con questo approccio, nell'app web viene visualizzata una richiesta di autorizzazione personalizzata che chiede all'utente di abilitare le notifiche. In questo modo, l'utente può scegliere l'attivazione o la disattivazione senza che il sito web corri il rischio di essere bloccato definitivamente. Se l'utente seleziona Abilita nell'interfaccia utente personalizzata, mostra la richiesta di autorizzazione effettiva, altrimenti nascondi il popup personalizzato e chiedi l'autorizzazione in un secondo momento.

Un buon esempio è Una volta effettuato l'accesso, nella parte superiore della pagina viene visualizzato un messaggio che ti chiede se vuoi attivare le notifiche.

Riquadro delle impostazioni

Puoi spostare le notifiche in un riquadro delle impostazioni per offrire agli utenti un modo semplice per attivare e disattivare i messaggi push, senza dover riempire l'interfaccia utente dell'app web.

Quando carichi la pagina per la prima volta, non viene visualizzata alcuna richiesta.

Un buon esempio è Quando carichi per la prima volta il sito di Google I/O, non ti viene chiesto di fare nulla, l'utente viene lasciato a esplorare il sito.

Riquadro delle impostazioni dell'app web di Google IO per i messaggi push.

Dopo alcune visite, se fai clic sulla voce di menu a destra viene visualizzato un riquadro delle impostazioni che consente all'utente di impostare e gestire le notifiche.

App web di Google IO che mostra la richiesta di autorizzazione.

Se fai clic sulla casella di controllo viene visualizzata la richiesta di autorizzazione. Niente sorprese nascoste.

Dopo aver concesso l'autorizzazione, la casella di controllo viene selezionata e l'utente è pronto. L'aspetto fantastico di questa UI è che gli utenti possono attivare e disattivare le notifiche da una posizione sul sito web.

Approccio passivo

Uno dei modi più semplici per offrire il push a un utente è avere un pulsante o un'opzione di attivazione/disattivazione che attivi/disattiva i messaggi push in una posizione sulla pagina che sia coerente in tutto il sito.

Questo non spinge gli utenti ad attivare le notifiche push, ma offre loro un modo semplice e affidabile di attivare e disattivare l'interazione con il tuo sito web. Per siti come i blog con una frequenza di rimbalzo elevata e con una frequenza di rimbalzo elevata, questa è un'opzione valida, in quanto si rivolge agli spettatori abituali, senza fastidiosi visitatori drive-by.

Sul mio sito personale è presente un'opzione di attivazione/disattivazione per i messaggi push nel piè di pagina.

Esempio di pulsante di attivazione/disattivazione delle notifiche push
di Gauntface.com nel piè di pagina

È piuttosto indisturbato, ma i visitatori abituali dovrebbero ricevere abbastanza attenzione da parte dei lettori che vogliono ricevere aggiornamenti. I visitatori occasionali non sono completamente interessati.

Se l'utente si abbona ai messaggi push, lo stato dell'opzione di attivazione/disattivazione cambia e mantiene lo stato in tutto il sito.

Esempio di Gauntface.com con notifiche abilitate

Esperienza utente scadente

Queste sono alcune delle pratiche comuni che ho notato sul web. Purtroppo, c'è una cattiva pratica molto comune.

La cosa peggiore che puoi fare è mostrare la finestra di dialogo di autorizzazione agli utenti non appena arrivano sul tuo sito.

Non conoscono il motivo per cui viene chiesta l'autorizzazione, ma potrebbero anche non sapere lo scopo del tuo sito web, cosa fa o cosa offre. A questo punto, bloccare le autorizzazioni per frustrazione non è raro, questo popup ostacola ciò che sta cercando di fare.

Tieni presente che se l'utente blocca la richiesta di autorizzazione, la tua app web non può più chiedere l'autorizzazione. Per ottenere l'autorizzazione dopo essere stato bloccato, l'utente deve modificare l'autorizzazione nell'interfaccia utente del browser e farlo non è facile, ovvio o divertente per l'utente.

In ogni caso, non chiedere l'autorizzazione appena l'utente apre il sito, prendi in considerazione un'altra UI o un altro approccio che incentivi l'utente a concedere l'autorizzazione.

Offri una via d'uscita

Oltre a considerare l'UX per richiedere un utente al push, prendi in considerazione come un utente dovrebbe annullare l'iscrizione o disattivare i messaggi push.

È stupefacente il numero di siti che chiedono l'autorizzazione non appena la pagina viene caricata e poi non offrono alcuna UI per la disattivazione delle notifiche push.

Il tuo sito deve spiegare agli utenti come possono disattivare il push. In caso contrario, è probabile che gli utenti scelgano l'opzione nucleare e blocchino definitivamente l'autorizzazione.

Passaggi successivi

Codelab