Porre l’attenzione a ciò su cui l’utente non dovrebbe focalizzarsi

login

Jared M. Spool

User Interface Engineering

articolo orginale:

Focusing On What Our Users Shouldn’t Focus On

23 marzo 2016

“In che modo posso aiutarla?”

“Sono rimasta bloccata fuori dal mio account e quindi non riesco visualizzare la carta d’imbarco con la vostra applicazione“.

Nelle immediate vicinanze del Gate B6, tutti poterono sentire la chiamata all’assistenza clienti, perché la donna aveva messo il suo telefono in vivavoce. Era l’unico modo in cui poteva seguire le indicazioni dell’addetto al servizio di assistenza.

La passeggera stava cercando di mantenere la calma, ma era evidente che la situazione stava diventando difficile; l’aereo iniziava a imbarcare e l’applicazione non visualizzava la sua carta d’imbarco, anche se aveva funzionato regolarmente quando era passata dai controlli della sicurezza aeroportuale. A un certo punto, l’applicazione della compagnia aerea aveva deciso che lei doveva inserire la sua user e password ancora una volta, ed è stato lì che era rimasta chiusa fuori dal suo account.

Ora parlava al telefono con il quarto addetto della compagnia aerea. La prima volta quello che aveva risposto non poteva aiutarla e l’aveva inoltrata allo sportello del supporto tecnico per i servizi web, dove era rimasta in attesa. Poi aveva cominciato a parlare con una persona cordiale, ma era caduta la linea. Un’altra chiamata alle prenotazioni, con un’attesa ancora più lunga e un altro trasferimento al supporto tecnico.

Tutto questo perché non riusciva a digitare o a ricordare la sua password. La compagnia aerea aveva recentemente aggiornato la sua politica di sicurezza e richiedeva regole più severe per le password. Quelle regole avevano reso difficile usare la tastiera virtuale sul display di un piccolo telefono cellulare. Sapete, una cosa come ‘22mFYvjzF4A(}7’; provate a digitarlo in un iPhone, senza commettere errori.

La donna non riusciva a digitare la password, o forse leggeva male quello che aveva scritto nella sua rubrica, comunque sia, non riusciva a dargli la password giusta. Oppure nel campo utente magari aveva inserito l’indirizzo email sbagliato, o forse, se la user non fosse stata il suo indirizzo e-mail, non sapeva qual era la sua user. Dopo alcuni tentativi, la funzione di sicurezza della compagnia aerea decise che l’utente non era chi invece sapeva di essere e così le aveva bloccato l’account.

L’autenticazione, per scelta di design, ha una usabilità selettiva

Quella donna non si era svegliata la mattina pensando a quanto spiacevole sarebbe stato rimanere bloccata fuori dal suo account. Probabilmente non pensava affatto a doversi autenticare nel sistema della compagnia aerea. Invece, pensava a suo viaggio e a quello che avrebbe dovuto portare a termine là. Non avrebbe voluto pensare se era capace di digitare la password nel suo telefono.

Ora, seduta al gate B6, mentre ascoltava gli annunci della zona di imbarco, non era concentrata sul suo volo, era invece concentrata sulle acrobazie che avrebbe dovuto affrontare perché l’applicazione della compagnia aerea visualizzasse la sua carta d’imbarco. Era ovviamente frustrata e nessuno potrebbe biasimarla.

Nel mondo di oggigiorno basato sulla fiducia, la privacy e la sicurezza, l’autenticazione è un male necessario; è stata progettata per avere un’usabilità selettiva: un buon sistema di autenticazione deve essere inusabile per gli intrusi, tuttavia, deve essere anche estremamente usabile per gli utenti legittimi. I sistemi di autenticazione mal progettati falliscono in due modi: o fanno entrare le persone sbagliate, o la fanno troppo difficile per le persone autorizzate.

In ogni caso, nei nostri design, l’autenticazione non dovrebbe essere il punto focale dell’esperienza utente. Infatti, se la persona è quella legittima, non dovrebbe comparire proprio sul suo radar.

Autenticazione come Microinterazione

Il più delle volte, quando chiediamo ai nostri utenti di fare “Log In”, si tratta solo di un rapido inserimento di usatissime user e password. Non danno molto da pensare e si passa oltre in fretta.

Tuttavia, raramente teniamo conto di tutte le cose che possono andare storte. Cosa succede quando va male? Improvvisamente, ciò che doveva essere una piccola interazione diventa un grosso problema.

L’autenticazione è un pezzo del design, è quello che Dan Saffer chiamerebbe una microinterazione. (Dan ha coniato il termine e ha scritto un libro sull’argomento, che incidentalmente ha il titolo “Microinteractions”). Le microinterazioni sono brevi episodi in cui l’utente e il design interagiscono. Se ben progettate, migliorano l’esperienza dell’utente con il design, quando invece sono mal progettate, danneggiano l’esperienza.

Quando la gente parla di microinterazioni, raramente parla delle schermate di autenticazione. Spesso si riferiscono a sofisticate animazioni per indicare un esito positivo, o un modo intelligente per segnalare all’utente una nuova importante informazione. Tuttavia, l’autenticazione è una delle microinterazioni più diffuse che vediamo oggi. E raramente è ben fatta.

Microinterazioni che rubano l’attenzione dell’utente

L’autenticazione ruba l’attenzione degli utenti. Gli utenti non sono più concentrati a conseguire l’obiettivo previsto, ma sono invece concentrati esclusivamente nel convincere l’applicazione a farli entrare.

L’autenticazione non è l’unica microinterazione che ruba attenzione degli utenti, i messaggi di errore incomprensibili possono avere lo stesso effetto, trascinando l’utente lontano dal suo obiettivo, mentre tenta di interpretare ciò che il sistema cerca di dirgli. Oppure quando l’utente cerca di scorrere fino in fondo un elenco “a scorrimento senza fine”, e non sa se il sistema sta ancora recuperando altri dati o se ha già finito. O ancora, quando l’utente riceve un importante comunicazione dal sistema e apre l’app per saperne di più, ma lo schermo non mostra traccia della comunicazione, perché l’app non è stata ancora aggiornata.

Per un momento, la microinterazione ha monopolizzato l’attenzione degli utenti. Ma se il sistema si rimette in carreggiata e il problema si risolve in fretta? Anche quando accade, è sempre una distrazione momentanea e le distrazioni … beh … distraggono.

Ma che succede invece quando non si risolve in fretta, come per la nostra povera passeggera della compagnia aerea che è rimasta chiusa fuori dal suo account? In questo caso il problema è addirittura bloccante e le impedisce di procedere.

Qui è successo che abbiamo rivelato l’architettura del nostro sistema agli utenti. Gli utenti non hanno bisogno di sapere come l’applicazione client sincronizza i dati con il server. Non hanno bisogno di sapere come il sistema previene l’intrusione dei malintenzionati.

Far nascere nei designer l’amore per i ladri di attenzione

Quando progettiamo le nostre applicazioni e i nostri servizi, raramente pensiamo alle microinterazioni e quando lo facciamo, di solito è per delle microinterazioni appariscenti con delle accattivanti animazioni.

Quando si visionano i prototipi del design per una nuova funzionalità, è raro vedere una schermata di autenticazione. Anche quando un team è abbastanza intelligente da includerle, raramente mostra le schermate che vengono fuori quando l’utente non riesce a ricordare la password, prova diverse varianti, clicca sul link per resettare la password, ed è costretto all’esercizio acrobatico di reimpostare la propria password, per poi (forse) riprendere il cammino interrotto. Se lo facessero, queste schermate supererebbero rapidamente in numero, le schermate della nuova funzione.

L’autenticazione è un’esperienza così infelice perché non è mai stata amata dai designer. Di solito è il sottoprodotto di un processo di progettazione che si è evoluto nel corso del tempo, senza alcuna riflessione o revisione critica.

Quand’è che nel processo di progettazione guardiamo tutti i posti in cui il design può andare storto per gli utenti? Dov’è che dobbiamo andare a progettare l’interazione che vorremmo, per la donna che deve imbarcarsi sul suo aereo?

Ripensare le microinterazioni di autenticazione

Per migliorare l’autenticazione ci sono alcune cose semplici che possiamo fare. Innanzitutto, chiudere fuori un utente è una reazione un po’ troppo severa, soprattutto dopo un numero esiguo di tentativi falliti. Se un intruso tenta un attacco di forza bruta, probabilmente farà dozzine di tentativi falliti. Perché non aumentare il numero di tentativi consentiti a 12 o a 20, prima di bloccare l’account?

Avvisare l’utente del blocco imminente dell’account sarebbe una cortesia gradita. Ancora meglio sarebbe fornire dei modi migliori per parlare con una persona dell’assistenza, come per esempio, un link a un consulente esperto. (la nostra povera passeggera della compagnia aerea ha dovuto copiare il numero di telefono da un messaggio di errore, e poi comporlo manualmente. I telefoni cellulari fra i loro super poteri annoverano la capacità di individuare e comporre i numeri di telefono. Un buon design dovrebbe trarne vantaggio).

Questi sono solo un paio di rimedi semplici, ma ce ne sono di ancora più sofisticati per progettare l’esperienza di autenticazione. Ad esempio, si può creare un modello di rischio più dettagliato, che delinea quali informazioni o azioni nell’applicazione sono sensibili (come il numero di carta di credito, o la possibilità di acquistare un biglietto), e quelle invece che costituiscono un basso rischio (come mostrare la carta d’imbarco). Poi, fintanto che l’applicazione conosce l’identità dell’utente, può concedere l’accesso agli elementi a basso rischio, pur proteggendo l’utente dagli atti fraudolenti.

Dan Saffer ha concepito un framework che suddivide la progettazione delle microinteraziioni in quattro componenti:

  • feedback,
  • modalità e cicli,
  • trigger,
  • regole.

Quando dovrebbe essere attivata la l’autenticazione? Il sistema, quale feedback dovrebbe fornire? Quali regole deve usare per decidere se attivare la richiesta di autenticazione, o lasciar invece passare l’utente? A quali condizioni (modalità), o con che frequenza (cicli) il sistema deve insistere nel tentativo di autenticare l’utente?

Porre l’attenzione a ciò su cui l’utente non dovrebbe focalizzarsi

Queste sono le domande su cui il team di design dovrebbe concentrarsi. Oserei dire che le microinterazioni più importanti su cui focalizzarsi sono quelle su cui i nostri utenti, invece, non dovrebbero mai (o raramente) focalizzarsi.

Dobbiamo garantire che il nostro lavoro di design includa le situazioni in cui l’architettura del nostro sistema cerca di affiorare. Dobbiamo respingerlo e rivestirlo con una piacevole esperienza intenzionalmente approntata per i nostri utenti. Quello è il progetto di una buona esperienza.

Jared M. SpoolJared M. Spool

Traduzione di

L’autore

Jared M. Spool è il fondatore di User Interface Engineering. Trascorre il suo tempo lavorando con i gruppi di ricerca presso la sua società e aiuta i clienti a capire come risolvere i loro problemi di design. Potete seguire Jared su Twitter: @jmspool

Questo articolo è stato ripubblicato con l’autorizzazione di User Interface Engineering. Per altri articoli e informazioni, visitate il sito www.uie.com/

Stampa articolo Scarica il file in formato PDF

Elenco Articoli di Jared M. Spool

Post A Comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *