App poco chiara? Scopri dove si perde il filo dell'attività

Per diagnosticare un’app poco chiara, osserva le sue schermate, i controlli e le risposte mentre qualcuno prova a svolgere un’attività supportata dall’app. Individua il primo punto in cui l’azione successiva diventa poco chiara. Confronta ciò che la persona si aspetta con ciò che l’app fa e comunica. Un salvataggio non riuscito o una funzionalità mancante richiedono un intervento diverso da quello necessario per un’etichetta o un percorso poco chiari.

Immagina una persona che cerca di modificare una prenotazione già esistente. Apre diversi menu, torna alla schermata iniziale e chiede aiuto a un collega. Questa sequenza è un punto di partenza per un’osservazione. Da sola non può spiegare se in seguito la persona disinstallerà l’app né quale schermata debba essere riprogettata.

Perché le persone perdono il passaggio successivo?

Le persone possono comprendere l’obiettivo e tuttavia non cogliere un’azione o una risposta poco chiara. Cerchiamo la prima discrepanza visibile tra l’attività che intendono svolgere e la schermata che incontrano. Non giungere a una spiegazione definitiva finché non hai verificato l’operazione. Ciò che sembra un problema di navigazione può anche essere una richiesta non riuscita o un risultato non supportato dal prodotto.

Il testo suggerisce un’azione diversa. Dopo aver toccato Continua, una persona potrebbe aspettarsi un’altra schermata di riepilogo, mentre l’app invia immediatamente una richiesta. Le indicazioni di Apple sui pulsanti consigliano di renderne chiaro lo scopo. Confronta l’aspettativa con l’effetto reale prima di scegliere un’etichetta sostitutiva.

Il risultato rimane incerto. Una persona tocca di nuovo perché non riesce a capire se l’app abbia accettato la richiesta. Esamina ciò che è stato effettivamente salvato e ciò che la schermata ha comunicato. Una conferma mancante e un’operazione non riuscita richiedono interventi diversi.

Le indicazioni per l’inserimento arrivano dopo l’errore. Verifica se il campo spiega quale valore richiede.

Per i contenuti web, il criterio di W3C relativo a etichette o istruzioni richiede etichette o istruzioni quando il contenuto richiede l’inserimento di dati. Usa questo riferimento per le schermate web all’interno di un’app. Le app native richiedono una verifica separata secondo le indicazioni della piattaforma.

Il percorso perde il proprio contesto. Una persona torna da una schermata di dettaglio e non riesce a ritrovare l’elemento che stava modificando. Annota il punto di partenza, l’azione scelta e la schermata risultante. Descrivi la prima transizione poco chiara con una precisione sufficiente a riprodurla.

Come si diagnostica un’app poco chiara?

Parti da un risultato supportato e da uno stato iniziale confrontabile. Usa un account di prova e dati di prova sicuri per le azioni che inviano, addebitano, eliminano o producono effetti su altre persone. Scrivi l’obiettivo senza indicare il menu o il controllo che permette di raggiungerlo. Devi scoprire ciò che la persona riesce a trovare e comprendere prima che tu le fornisca una spiegazione.

1. Definisci il completamento. Per la modifica di una prenotazione, il risultato previsto è una richiesta inviata o una nuova prenotazione confermata? Verifica quale risultato può essere supportato da questa versione e da questo account.
2. Registra lo stato iniziale. Annota la versione dell’app, il dispositivo, la lingua, le autorizzazioni e se la prenotazione esiste già. L’account di un amministratore può mostrare un percorso diverso da quello dell’account di un cliente.
3. Osserva senza nominare il controllo. Chiedi alla persona di provare a raggiungere l’obiettivo. Annota la schermata che sceglie, l’etichetta che legge e ciò che si aspetta. Se la aiuti, annota l’aiuto; il completamento successivo non lo cancella.
4. Verifica separatamente il risultato. Confronta la risposta visibile con la prenotazione salvata. Riaprila nell’account di prova o controlla il record di prova del fornitore. Un tocco o una schermata che sembra indicare un esito positivo non dimostrano che l’aggiornamento previsto sia avvenuto.

Se esamini l’app da solo, annota ciò che riesci a riprodurre e rendi visibile questa limitazione. La tua conoscenza del prodotto modifica l’attività. Un’osservazione successiva con una persona che non lo conosce fornisce prove diverse.

Esamina questa attività di prenotazione fittizia

Considera un’app inventata per prenotare lezioni, che consente di richiedere un’altra sessione. Il fornitore deve accettare la richiesta prima che la prenotazione cambi. Le note seguenti illustrano come indagare su un malinteso. Per questo esempio non abbiamo usato un’app attiva, un account o un partecipante, né abbiamo testato il testo proposto.

La discrepanza osservata riguarda il significato dell’azione. Un’etichetta diversa è un’ipotesi da verificare rispetto all’operazione effettiva. Se la richiesta non raggiunge mai il fornitore, indaga anche sull’operazione non riuscita. Se la conferma immediata è essenziale per il prodotto, si tratta di una decisione di prodotto distinta, non di qualcosa che possa essere fornito dall’etichetta di un pulsante.

Scrivi un’osservazione prima della relativa interpretazione. “Ha aperto la prenotazione, ha toccato Modifica prenotazione e si aspettava una conferma” descrive il comportamento in questo esercizio fittizio. “L’interfaccia è pessima” elude la domanda a cui devi ancora rispondere.

Apporta la modifica minima che risponde all’osservazione

Scegli un intervento che affronti la discrepanza annotata e preservi l’operazione prevista. Comincia dal testo, dalle istruzioni o dal feedback quando sono questi gli aspetti incerti. Una modifica alla struttura di navigazione o una riprogettazione più ampia richiede una motivazione fondata sull’attività. Mantieni visibili i problemi funzionali, affinché una spiegazione più chiara non nasconda un’operazione che continua a non riuscire.

1. Prova una bozza mirata. Per la prenotazione fittizia, mostra in una bozza cliccabile l’etichetta proposta per l’azione e lo stato risultante. I nostri audit e prototipi per la UX delle app seguono questa sequenza dall’attività al prototipo. Confronta ciò che la persona si aspetta prima di toccare con lo stato che riconosce dopo; non descrivere l’etichetta proposta come un miglioramento dimostrato.

2. Verifica un percorso di errore. Il criterio di W3C relativo all’identificazione degli errori nei contenuti web richiede che un errore di inserimento rilevato automaticamente identifichi l’elemento interessato e descriva l’errore in forma testuale. Un contorno colorato da solo non fornisce questa spiegazione. I controlli nativi e una verifica completa dell’accessibilità richiedono controlli specifici per la rispettiva piattaforma.

3. Verifica la risposta sullo schermo e con le tecnologie assistive. Per i contenuti web, il criterio di W3C relativo ai messaggi di stato riguarda la possibilità di rendere determinate variazioni di stato disponibili alle tecnologie assistive senza spostare il focus dal controllo corrente. Verifica ciò che appare sullo schermo e ciò che gli strumenti assistivi possono rilevare. Uno screen reader, per esempio, è un software in grado di leggere ad alta voce i contenuti dell’interfaccia. Questo singolo criterio non certifica l’app, non stabilisce un obiettivo per il tempo di risposta e non corregge un’operazione lenta.

4. Segui la transizione verso il web. Quando il percorso dello stesso account o della stessa prenotazione passa a una pagina web, includi la transizione nella verifica. Lo sviluppo di siti e applicazioni web deve preservare il testo dell’attività e lo stato effettivo oltre quel confine.

Che cosa dovresti verificare dopo la modifica?

Ripeti la stessa attività prevista da uno stato confrontabile e annota ciò che accade. Mantieni visibili accanto al risultato la versione dell’app, il dispositivo, la lingua e l’aiuto fornito. Un confronto utile riguarda l’attività osservata: se la persona ha trovato l’azione, ne ha compreso l’effetto e ha riconosciuto il risultato effettivo. Non trarre conclusioni aziendali più ampie finché non disponi delle relative prove.

Registra insieme il completamento e l’aiuto, la prima deviazione errata, gli errori di inserimento che la persona non è riuscita a interpretare e l’eventuale confusione tra una richiesta e una conferma. Ripeti le verifiche pertinenti con la lingua e la configurazione di accessibilità che stai esaminando. Controlla le etichette più lunghe e le informazioni disponibili tramite tale configurazione, senza presumere che la schermata inglese rappresenti ogni versione.

Se registri già le azioni dell’app, come l’avvio di una richiesta di modifica della prenotazione o il suo arrivo al fornitore, verifica che i record corrispondano a tali stati effettivi. Tieni le variazioni nelle domande all’assistenza accanto allo stesso percorso. La mancanza di download dell’app è un problema distinto di acquisizione; la nostra guida a un’app che non ottiene download parte da prima che una persona apra il prodotto.

La ripetizione riuscita può descrivere tale osservazione. Non può stabilire perché le persone disinstallano l’app né attribuire all’intervento una variazione della fidelizzazione. Annota la successiva questione irrisolta insieme alla persona responsabile della sua verifica.

Dove interveniamo noi

Partiamo dall’attività supportata, dalla prima transizione poco chiara e dalle prove necessarie per scegliere un intervento. Possiamo trasformare tutto questo in un prototipo, verificare il percorso implementato e includere il suo equivalente web. Porta una descrizione dell’attività e del punto in cui si è interrotta a un confronto sul progetto. Rimuovi i nomi dei clienti e le altre informazioni personali da qualsiasi esempio che condividi.

← Tutti gli articoli