Le richieste di autorizzazione nel percorso del prodotto

Una richiesta di autorizzazione mobile è più di un passaggio tecnico di controllo. Chiede a una persona di prendere una decisione sull’accesso, spesso mentre sta cercando di completare un’altra attività. Il team di prodotto controlla gran parte dell’esperienza circostante: quando appare la richiesta, quale contesto la precede e che cosa fa l’applicazione dopo la decisione.

Trattare le autorizzazioni come parte del percorso del prodotto rende più chiaro il problema di progettazione. Invece di chiedersi come aumentare l’accettazione, occorre chiedersi quale accesso sia necessario, quando il suo scopo diventi concreto e se l’applicazione resti utile senza tale accesso. Questo approccio collega la fiducia a scelte comprensibili anziché a formulazioni persuasive.

Tratta ogni richiesta come una decisione di prodotto

Ogni richiesta dovrebbe partire da una funzionalità specifica e da una motivazione definita. Una funzionalità è l’azione rivolta all’utente che dipende dall’accesso, come allegare una foto vicina o registrare audio all’interno di una nota. Se il team non riesce a collegare l’accesso a un’azione immediata, la richiesta potrebbe essere prematura, superflua o troppo ampia.

• Identifica l’azione che richiede l’accesso.
• Verifica quale ambito dell’autorizzazione supporta tale azione.
• Decidi che cosa rimane disponibile senza accesso.
• Documenta come l’applicazione gestisce un cambiamento della decisione.

Questo esercizio separa la comodità dell’implementazione dalla necessità del prodotto. Richiedere l’accesso al primo avvio può semplificare un ramo dello sviluppo, ma può eliminare il contesto necessario per valutare la richiesta. Posticipare l’accesso può creare ulteriori stati dell’interfaccia, ma tali stati possono rendere più facile comprendere la relazione tra azione e autorizzazione. L’equilibrio appropriato dipende dalla funzionalità e dalle condizioni verificate per ogni piattaforma supportata.

Usa la divulgazione progressiva per preservare il contesto

La divulgazione progressiva consiste nel presentare informazioni e scelte quando diventano pertinenti, anziché mostrare tutte le decisioni contemporaneamente. Per le autorizzazioni, ciò suggerisce in genere di attendere finché una persona non avvia un’azione correlata. Una richiesta di accesso alla fotocamera collegata a un’azione esplicita di acquisizione offre un contesto più chiaro rispetto alla stessa richiesta presentata prima che l’applicazione abbia chiarito che cosa consentirebbe di fare la fotocamera.

Il percorso dovrebbe comunque essere progettato come una sequenza, non come una richiesta isolata. Occorre considerare lo stato precedente alla richiesta, qualsiasi spiegazione fornita dall’applicazione, il passaggio controllato dal sistema che potrebbe seguire e la destinazione dopo una decisione. Il team dovrebbe verificare quali parti della sequenza possono essere controllate su ogni piattaforma. La divulgazione progressiva è utile solo quando il passaggio successivo appare collegato all’azione che lo ha attivato.

Progetta insieme la spiegazione e il passaggio

Una spiegazione a livello di applicazione può preparare la decisione senza imitare o prevedere un’interfaccia di sistema. Questa spiegazione, talvolta chiamata schermata di pre-autorizzazione, è una vista controllata dal prodotto e mostrata prima di una richiesta controllata dalla piattaforma. Dovrebbe chiarire lo scopo immediato dell’accesso e descrivere qualsiasi alternativa rilevante. L’opportunità di una schermata simile dipende dalla complessità della richiesta e dalle condizioni di implementazione della piattaforma.

1. Indica l’azione che la persona ha appena selezionato.
2. Spiega perché tale azione necessita dell’accesso richiesto.
3. Descrivi un percorso pratico che non richieda l’accesso, se ne esiste uno.
4. Prosegui nel flusso verificato della piattaforma senza aggiungere pressioni.

La formulazione dovrebbe rimanere coerente nella funzionalità, nella spiegazione a livello di applicazione e in qualsiasi testo controllato dalla piattaforma che il team possa configurare. Una mancata corrispondenza crea ambiguità, anche quando ogni frase sembra ragionevole se considerata da sola. Esamina queste superfici come un unico passaggio, riconoscendo al contempo che la parte della piattaforma può avere vincoli che il team di prodotto deve verificare durante l’implementazione.

Modella gli stati delle autorizzazioni, non solo le richieste

Un modello degli stati è una mappa delle condizioni che un’interfaccia può incontrare e della risposta assegnata a ciascuna condizione. Per una funzionalità che dipende da un’autorizzazione, il modello dovrebbe comprendere più della decisione iniziale. Potrebbe dover distinguere tra un accesso disponibile, non disponibile, limitato, sconosciuto o modificato al di fuori del flusso corrente, in base a ciò che l’ambiente di destinazione espone effettivamente.

Un modello degli stati completo impedisce che la logica delle autorizzazioni si disperda in schermate non correlate sotto forma di eccezioni sparse. Aiuta inoltre i team di progettazione, ingegneria e controllo qualità a discutere delle stesse condizioni. Ogni stato dovrebbe portare a una risposta utile dell’interfaccia, anziché a un vicolo cieco o a una richiesta ripetuta che non ha più senso.

• L’accesso disponibile conduce direttamente alla funzionalità richiesta.
• L’accesso non disponibile preserva le funzioni non correlate e spiega la limitazione.
• L’accesso limitato adatta la funzionalità quando lo stato verificato della piattaforma lo consente.
• L’accesso sconosciuto attiva il punto di decisione contestuale appropriato.
• L’accesso modificato aggiorna l’interfaccia prima che proceda un’altra azione dipendente.

Esamina necessità, tempistica e recupero

La verifica delle autorizzazioni può essere svolta funzionalità per funzionalità prima dell’implementazione e ripetuta quando la funzionalità cambia. Lo scopo non è produrre una regola universale. Lo scopo è rendere visibili le ipotesi, in particolare quelle relative a ciò che la piattaforma supporta, alla quantità di accesso necessaria alla funzionalità e all’effettiva utilità di un’alternativa.

1. Necessità: l’azione può funzionare senza questo accesso o con un ambito più ristretto?
2. Tempistica: quale evento avviato dall’utente fornisce una ragione chiara per la richiesta?
3. Spiegazione: quale dettaglio è necessario prima della decisione e quale può attendere?
4. Alternativa: quale percorso utile rimane se l’accesso non è disponibile?
5. Recupero: come dovrebbe rispondere l’interfaccia se lo stato cambia in seguito?

La verifica dovrebbe includere il percorso di ritorno oltre a quello della richiesta. Se l’ambiente supportato offre un modo per riconsiderare l’accesso, l’applicazione può spiegare la situazione della funzionalità dipendente senza presumere la decisione successiva. Se la possibilità di riconsiderare l’accesso non è disponibile o non è appropriata, l’interfaccia dovrebbe evitare di presentare controlli che non possono completare l’azione prevista.

Crea fiducia con una sequenza di autorizzazioni coerente

Una strategia misurata per le autorizzazioni deriva da alcune decisioni collegate: richiedere solo ciò di cui una funzionalità definita ha bisogno, attendere un contesto pertinente, spiegare lo scopo immediato e progettare ogni stato verificato. La fiducia non è un messaggio separato aggiunto alla richiesta. Si riflette nel fatto che la sequenza rimanga comprensibile prima, durante e dopo la decisione.

Il passo pratico successivo consiste nello scegliere una funzionalità che dipende da un’autorizzazione e mapparne l’intero percorso. Indica l’azione di attivazione, la spiegazione controllata dal prodotto, il passaggio controllato dalla piattaforma, i possibili stati, l’alternativa e il percorso di recupero. Questa mappa offre al team una base concreta per eliminare gli accessi non necessari, correggere tempistiche inadeguate e rendere più facili da comprendere le scelte rimanenti.