Vere bugie di interfacce utente ottimistiche

Tre interfacce utente (UI) vanno a un pub. Il primo ordina da bere, poi molti altri. Un paio d'ore dopo, chiede il conto e lascia il pub ubriaco. La seconda interfaccia utente ordina un drink, lo paga in anticipo, ordina un altro drink, lo paga e così via, e in un paio d'ore lascia il pub ubriaco. La terza interfaccia utente esce dal pub già ubriaca subito dopo essere entrata: sa come funzionano i pub ed è abbastanza efficiente da non perdere tempo. Hai sentito parlare di questo terzo? Si chiama "interfaccia utente ottimista".

Di recente, dopo aver discusso dell'ottimizzazione delle prestazioni psicologiche in una serie di conferenze dedicate sia allo sviluppo front-end che all'UX, sono rimasto sorpreso di vedere quanto poco l'argomento della progettazione ottimistica dell'interfaccia utente sia affrontato nella comunità. Francamente, il termine stesso non è nemmeno ben definito. In questo articolo scopriremo su quali concetti si basa, esamineremo alcuni esempi e ne esamineremo il background psicologico. Successivamente, esamineremo le preoccupazioni e i punti principali su come mantenere il controllo su questa tecnica UX.

Ulteriori letture su SmashingMag:

• L'utente è il web designer anonimo
• Progettazione di interfacce utente basate su schede
• Interfacce di conversazione: dove siamo oggi?
  

Ma prima di iniziare, a dire il vero, nessuna singola cosa può essere definita "interfaccia utente ottimista". Piuttosto, è il modello mentale dietro l'implementazione di un'interfaccia. Il design ottimista dell'interfaccia utente ha una sua storia e una sua logica.

C'era una volta

Molto tempo fa - quando la parola "tweet" si applicava principalmente agli uccelli, Apple era sull'orlo del fallimento e le persone mettevano ancora i numeri di fax sui loro biglietti da visita - le interfacce web erano piuttosto ascetiche. E la stragrande maggioranza di loro non aveva nemmeno un accenno di ottimismo. Un'interazione con un pulsante, ad esempio, potrebbe seguire uno scenario simile al seguente:

1. L'utente fa clic su un pulsante.
2. Il pulsante viene attivato in uno stato disabilitato.
3. Una chiamata viene inviata a un server.
4. Una risposta dal server viene rimandata alla pagina.
5. La pagina viene ricaricata per riflettere lo stato della risposta.

Questo potrebbe sembrare abbastanza inefficiente nel 2016; tuttavia, sorprendentemente, lo stesso scenario è ancora utilizzato in molte pagine Web e applicazioni e fa ancora parte del processo di interazione per molti prodotti. Il motivo è che è prevedibile e più o meno a prova di errore: l'utente sa che l'azione è stata richiesta dal server (lo stato disabilitato del pulsante suggerisce questo), e una volta che il server risponde, la pagina aggiornata indica chiaramente la fine di questa interazione client-server-client. I problemi con questo tipo di interazione sono abbastanza evidenti:

• L'utente deve attendere. Ormai sappiamo che anche il più breve ritardo nel tempo di risposta del server ha un effetto negativo sulla percezione dell'utente dell'intero brand, non solo su questa particolare pagina.
• Ogni volta che l'utente riceve una risposta alla sua azione, questa viene presentata in modo abbastanza distruttivo (viene caricata una nuova pagina, invece di quella esistente che viene aggiornata), il che interrompe il contesto del compito dell'utente e potrebbe influenzare il suo corso di pensiero. Anche se in questo caso non stiamo necessariamente parlando di multitasking, qualsiasi cambiamento di contesto mentale è spiacevole. Quindi, se un'azione non è intrinsecamente intesa a cambiare contesto (il pagamento online è un buon esempio di quando un cambiamento è naturale), il cambio creerebbe un tono di dialogo ostile tra utente e sistema.

Bei tempi non così vecchi

Poi è arrivato il cosiddetto Web 2.0 che ha fornito nuove modalità di interazione con le pagine web. Il nucleo di questi erano XMLHttpRequest e AJAX. Queste nuove modalità di interazione sono state integrate da "spinners": la forma più semplice di indicatore di avanzamento, il cui unico scopo era quello di comunicare all'utente che il sistema è impegnato nell'esecuzione di alcune operazioni. Ora, non avevamo bisogno di ricaricare la pagina dopo aver ricevuto una risposta dal server; potremmo invece semplicemente aggiornare una parte della pagina già renderizzata. Ciò ha reso il Web molto più dinamico, consentendo esperienze più fluide e coinvolgenti per gli utenti. La tipica interazione con un pulsante potrebbe ora assomigliare a questa:

1. L'utente fa clic su un pulsante.
2. Il pulsante viene attivato in uno stato disabilitato e sul pulsante viene visualizzata una rotazione di qualche tipo per indicare che il sistema sta funzionando.
3. Viene inviata una chiamata al server.
4. Una risposta dal server viene rimandata alla pagina.
5. Lo stato visivo del pulsante e della pagina vengono aggiornati in base allo stato della risposta.

Questo nuovo modello di interazione ha affrontato uno dei suddetti problemi del vecchio metodo di interazione: l'aggiornamento della pagina avviene senza un'azione distruttiva, mantenendo il contesto per l'utente e coinvolgendolo nell'interazione molto meglio di prima.

Questo tipo di modello di interazione è stato ampiamente utilizzato ovunque nei media digitali. Ma rimane un problema: gli utenti devono ancora attendere una risposta dal server. Sì, possiamo fare in modo che i nostri server rispondano più velocemente, ma non importa quanto ci sforziamo per velocizzare l'infrastruttura, gli utenti devono comunque aspettare. Ancora una volta, agli utenti non piace aspettare, per usare un eufemismo. Ad esempio, la ricerca mostra che il 78% dei consumatori prova emozioni negative a causa di siti Web lenti o inaffidabili. Inoltre, secondo un sondaggio condotto da Harris Interactive per Tealeaf, il 23% degli utenti confessa di imprecare contro i propri telefoni, l'11% ha urlato contro di loro e un intero 4% ha effettivamente gettato il telefono quando ha riscontrato un problema con una transazione online. I ritardi sono tra questi problemi.

Anche se mostri una sorta di indicatore di avanzamento mentre l'utente attende, a meno che tu non sia molto creativo con l'indicatore, al giorno d'oggi semplicemente non è abbastanza. Per la maggior parte, le persone si sono abituate agli spinner che indicano la lentezza di un sistema. Gli spinner sono ora più associati all'attesa puramente passiva, quando l'utente non ha altra scelta che attendere la risposta del server o chiudere del tutto la scheda o l'applicazione. Quindi, facciamo un passo per migliorare questo tipo di interazione; diamo un'occhiata a questo concetto di interfaccia utente ottimista.

Interfaccia utente ottimista

Come accennato, un'interfaccia utente ottimista non è altro che un modo per gestire l'interazione uomo-computer. Per comprendere le idee principali alla base, continueremo con il nostro scenario "l'utente fa clic su un pulsante". Ma il principio sarà lo stesso per praticamente qualsiasi tipo di interazione che potresti voler rendere ottimista. Secondo l'Oxford English Dictionary:

op-ti-mis-tic , agg. fiducioso e fiducioso per il futuro.

Cominciamo con la parte “fiduciosi nel futuro”.

Cosa ne pensi: quanto spesso il tuo server restituisce un errore su alcune azioni dell'utente? Ad esempio, la tua API si guasta spesso quando gli utenti fanno clic su un pulsante? O forse fallisce molto quando gli utenti fanno clic su un collegamento? Francamente, non credo. Ovviamente, questo potrebbe variare in base all'API, al carico del server, al livello di gestione degli errori e ad altri fattori in cui tu, come sviluppatore front-end o specialista UX, potresti non essere disposto a essere coinvolto. Ma fintanto che l'API è stabile e prevedibile e il front-end comunica correttamente le azioni legittime nell'interfaccia utente, quindi il numero di errori in risposta alle azioni avviate dall'utente sarà piuttosto basso. Direi che non dovrebbero mai superare l'1-3%. Ciò significa che nel 97-99% dei casi, quando l'utente fa clic su un pulsante su un sito Web, la risposta del server dovrebbe essere positiva, senza errori. Questo merita di essere messo in una prospettiva migliore:

Pensaci per un momento: se fossimo certi dal 97 al 99% di una risposta di successo, potremmo essere fiduciosi sul futuro di quelle risposte - beh, almeno molto più fiduciosi nel futuro di quanto non lo fosse il gatto di Schrodinger. Potremmo scrivere una storia completamente nuova sull'interazione dei pulsanti:

1. L'utente fa clic su un pulsante.
2. Lo stato visivo del pulsante viene attivato istantaneamente in modalità di successo.

Questo è tutto! Almeno dal punto di vista dell'utente, non c'è nient'altro: nessuna attesa, niente fissare un pulsante disabilitato e nemmeno un altro fastidioso spinner. L'interazione è perfetta, senza che il sistema intervenga grossolanamente per ricordare all'utente se stesso.

Dal punto di vista dello sviluppatore, il ciclo completo si presenta così:

1. L'utente fa clic su un pulsante.
2. Lo stato visivo del pulsante viene attivato istantaneamente in modalità di successo.
3. La chiamata viene inviata al server.
4. La risposta dal server viene rimandata alla pagina.
5. Nel 97-99% dei casi, sappiamo che la risposta avrà successo e quindi non dobbiamo disturbare l'utente.
6. Solo in caso di richiesta fallita il sistema parlerà. Non preoccuparti di questo per ora: arriveremo a questo punto più avanti nell'articolo.

Diamo un'occhiata ad alcuni esempi di interazioni ottimistiche. Probabilmente hai familiarità con i pulsanti "Mi piace", come si trovano su Facebook e Twitter. Diamo un'occhiata a quest'ultimo.

Si parte, ovviamente, basta, con il clic del pulsante. Ma nota lo stato visivo del pulsante quando l'utente non sta più premendo o passando il mouse sopra il pulsante. Passa istantaneamente allo stato di successo!

Vediamo cosa sta succedendo nella scheda "Rete" degli strumenti per sviluppatori del nostro browser in questo preciso momento.

La scheda "Rete" mostra che la richiesta del server è stata inviata ma è ancora in corso. Il numero del contatore dei “mi piace” non è stato ancora incrementato, ma con il cambio di colore l'interfaccia comunica chiaramente il successo all'utente, ancor prima di aver ricevuto una risposta dal server.

Dopo aver ricevuto una risposta positiva dal server, il contatore viene aggiornato, ma la transizione è molto più sottile rispetto al cambio colore istantaneo. Ciò fornisce all'utente un'esperienza fluida e ininterrotta, senza alcuna attesa percepita.

Un altro esempio di interazione ottimista si vede su Facebook, con il proprio pulsante Mi piace. Lo scenario è abbastanza simile, tranne per il fatto che Facebook aggiorna istantaneamente il contatore, insieme al colore di successo del pulsante, senza attendere la risposta del server.

Una cosa da notare qui, però. Se osserviamo il tempo di risposta del server, vedremo che è poco più di 1 secondo . Considerando che il modello RAIL consiglia 100 millisecondi come tempo di risposta ottimale per una semplice interazione, questo sarebbe normalmente troppo lungo. Tuttavia, l'utente non percepisce alcun tempo di attesa in questo caso a causa della natura ottimistica di questa interazione. Carino! Questo è un altro esempio di ottimizzazione delle prestazioni psicologiche .

Ma ammettiamolo: c'è ancora dall'1 al 3% di possibilità che il server restituisca un errore. O forse l'utente è semplicemente offline. O, più probabilmente, forse il server restituisce quella che tecnicamente è una risposta di successo, ma la risposta contiene informazioni che devono essere ulteriormente elaborate dal client. Di conseguenza, l'utente non riceverà un indicatore di errore, ma non possiamo nemmeno considerare la risposta un successo. Per capire come affrontare questi casi, dovremmo capire perché e come le UI ottimistiche funzionano psicologicamente in primo luogo.

La psicologia dietro le UI ottimistiche

Finora non ho sentito nessuno lamentarsi delle suddette interazioni ottimistiche sui principali social network. Quindi, diciamo che questi esempi ci hanno convinto che le UI ottimistiche funzionano. Ma perché funzionano per gli utenti? Funzionano semplicemente perché la gente odia aspettare. Questo è tutto, gente! Puoi saltare alla parte successiva dell'articolo.

Ma se stai ancora leggendo, probabilmente sei interessato a sapere perché è così. Quindi, scaviamo un po' più a fondo il terreno psicologico di questo approccio.

Un'interfaccia utente ottimista ha due ingredienti di base che meritano un'analisi psicologica:

• la risposta rapida all'azione dell'utente;
• la gestione di potenziali guasti sul server, sulla rete e altrove.

Risposta rapida all'azione dell'utente

Quando parliamo di progettazione dell'interfaccia utente ottimista, stiamo parlando di un tempo di risposta ottimale nell'interazione uomo-computer. E le raccomandazioni per questo tipo di comunicazione esistono fin dal 1968. All'epoca, Robert B. Miller pubblicò il suo pezzo fondamentale "Response Time in Man-Computer Conversational Transactions" (PDF), in cui definisce ben 17 diversi tipi di risposte che un utente può ottenere da un computer. Uno di questi tipi, Miller chiama "risposta all'attivazione del controllo": il ritardo tra la pressione di un tasto e il feedback visivo. Anche nel 1968, non avrebbe dovuto superare 0,1-0,2 secondi. Sì, il modello RAIL non è il primo a raccomandarlo: il consiglio è in circolazione da circa 50 anni. Miller osserva, tuttavia, che anche questo breve ritardo nel feedback potrebbe essere troppo lento per utenti esperti. Ciò significa che, idealmente, l'utente dovrebbe ricevere un riconoscimento della propria azione entro 100 millisecondi . Questo sta entrando nel raggio di una delle azioni inconsce più veloci che il corpo umano può eseguire: un battito di ciglia. Per questo motivo, l'intervallo di 100 millisecondi è generalmente percepito come istantaneo. "La maggior parte delle persone sbatte le palpebre circa 15 volte al minuto e un battito di palpebre dura in media da 100 a 150 millisecondi", afferma Davina Bristow, dell'Institute of Neurology dell'University College London, aggiungendo che questo "significa che nel complesso trascorriamo almeno 9 giorni all'anno a sbattere le palpebre. "

A causa della sua risposta visiva istantanea (anche prima che la richiesta effettiva sia terminata), un'interfaccia utente ottimista è uno degli esempi delle tecniche di completamento anticipato utilizzate nell'ottimizzazione delle prestazioni psicologiche. Ma il fatto che alle persone piacciano le interfacce che rispondono in un batter d'occhio non dovrebbe sorprendere la maggior parte di noi, davvero. E non è nemmeno difficile da raggiungere. Anche ai vecchi tempi, disabilitavamo i pulsanti immediatamente dopo averli cliccati, e questo di solito era sufficiente per riconoscere l'input dell'utente. Ma uno stato disabilitato in un elemento dell'interfaccia significa attesa passiva: l'utente non può fare nulla al riguardo e non ha alcun controllo sul processo. E questo è molto frustrante per l'utente. Ecco perché saltiamo del tutto lo stato disabilitato in un'interfaccia utente ottimista: comunichiamo un risultato positivo invece di far aspettare l'utente.

Gestione del potenziale fallimento

Veniamo al secondo aspetto psicologico interessante della progettazione ottimistica dell'interfaccia utente: la gestione del potenziale fallimento. In generale, sono disponibili molte informazioni e articoli su come gestire gli errori dell'interfaccia utente nel miglior modo possibile. Tuttavia, mentre vedremo come gestire gli errori più avanti in questo articolo, ciò che conta di più in un'interfaccia utente ottimista non è come gestiamo gli errori, ma quando lo facciamo.

Gli esseri umani organizzano naturalmente la loro attività in gruppi, terminati dal completamento di uno scopo o sottoscopo soggettivamente definito. A volte ci riferiamo a questi gruppi come a un "treno di pensieri", un "flusso di pensiero" (PDF) o semplicemente un "flusso". Lo stato di flusso è caratterizzato da massimo godimento, concentrazione energetica e concentrazione creativa. Durante un flusso, l'utente è completamente assorbito dall'attività. Un tweet di Tammy Everts lo illustra bene:

Sul web, le durate di tali gruppi di attività sono molto più brevi. Rivisitiamo per un momento il lavoro di Robert B. Miller. I tipi di risposta che cita includono:

• una risposta a una semplice richiesta di informazioni elencate;
• una risposta in forma grafica a un'indagine complessa;
• una risposta a "Sistema, mi capisci?"

Lega tutti questi elementi allo stesso intervallo di 2 secondi entro il quale l'utente dovrebbe ottenere il tipo di risposta pertinente. Senza scavare più a fondo, dobbiamo notare che questo intervallo dipende anche dalla memoria di lavoro di una persona (riferendosi all'intervallo di tempo entro il quale una persona può mantenere una certa quantità di informazioni nella propria testa e, soprattutto, essere in grado di manipolarla). Per noi, come sviluppatori e specialisti UX, ciò significa che entro 2 secondi dall'interazione con un elemento, l'utente sarà in un flusso e si concentrerà sulla risposta che si aspetta. Se il server restituisce un errore durante questo intervallo, l'utente sarà ancora in "dialogo" con l'interfaccia, per così dire. È simile a un dialogo tra due persone, in cui dici qualcosa e l'altra persona è leggermente in disaccordo con te. Immagina se l'altra persona passasse molto tempo ad annuire in accordo (l'equivalente della nostra indicazione di uno stato di successo nell'interfaccia utente) ma poi alla fine ti dicesse "no". Imbarazzante, non è vero? Pertanto, un'interfaccia utente ottimista deve comunicare l'errore all'utente entro i 2 secondi del flusso.

Armati della psicologia di come gestire gli errori in un'interfaccia utente ottimista, arriviamo finalmente a quell'1-3% di richieste non riuscite.

Il lato pessimista del design ottimista dell'interfaccia utente

Di gran lunga, l'osservazione più comune che sento è che il design ottimista dell'interfaccia utente è una specie di schema nero: barare, se vuoi. Cioè, utilizzandolo, mentiamo ai nostri utenti sul risultato della loro interazione. Legalmente, qualsiasi tribunale probabilmente sosterrebbe questo punto. Tuttavia, considero la tecnica una previsione o una speranza. (Ricordi la definizione di "ottimista"? Qui è dove diamo spazio alla parte "fiduciosa".) La differenza tra "mentire" e "prevedere" sta nel modo in cui tratti dall'1 al 3% delle richieste fallite. Diamo un'occhiata a come si comporta offline il pulsante "mi piace" ottimista di Twitter.

Innanzitutto, in linea con il modello ottimistico dell'interfaccia utente, il pulsante passa allo stato di successo subito dopo essere stato cliccato, di nuovo, senza che l'utente prema o passi più il mouse sopra il pulsante, esattamente come si comporta il pulsante quando l'utente è online.

Ma poiché l'utente è offline, la richiesta non riesce.

Pertanto, il prima possibile all'interno del flusso dell'utente, l'errore dovrebbe essere comunicato. Anche in questo caso, 2 secondi è solitamente la durata di un tale flusso. Twitter lo comunica nel modo più sottile possibile, semplicemente ripristinando lo stato del pulsante.

Il lettore coscienzioso qui potrebbe dire che questa gestione degli errori potrebbe essere fatta un ulteriore passo avanti, notificando effettivamente all'utente che la richiesta non può essere inviata o che si è verificato un errore. Ciò renderebbe il sistema il più trasparente possibile. Ma c'è un problema, o meglio, una serie di problemi:

• Qualsiasi tipo di notifica che appare all'improvviso sullo schermo cambierebbe il contesto dell'utente, spingendolo ad analizzare il motivo dell'errore, un motivo che verrebbe probabilmente presentato nel messaggio di errore.
• Come con qualsiasi messaggio di errore o notifica, questo dovrebbe guidare l'utente in questo nuovo contesto fornendo informazioni utilizzabili.
• Quelle informazioni utilizzabili creerebbero un altro contesto.

OK, ormai siamo tutti d'accordo sul fatto che questo sta diventando un po' complicato. Sebbene questa gestione degli errori sarebbe ragionevole, ad esempio, per un modulo di grandi dimensioni su un sito Web, per un'azione semplice come fare clic su un pulsante Mi piace, è eccessiva, sia in termini di sviluppo tecnico richiesto che di memoria di lavoro degli utenti.

Quindi, sì, dovremmo essere aperti sul fallimento in un'interfaccia utente ottimista e dovremmo comunicarlo il prima possibile in modo che il nostro ottimismo non diventi una bugia. Ma dovrebbe essere proporzionale al contesto. Per un like fallito, riportare sottilmente il pulsante al suo stato originale dovrebbe essere sufficiente, cioè, a meno che all'utente non piaccia lo stato del proprio altro significativo, nel qual caso la cosa funziona sempre meglio.

Pessimismo estremo

Potrebbe sorgere un'altra domanda: cosa succede se l'utente chiude la scheda del browser subito dopo aver ricevuto un indicatore di successo ma prima che la risposta venga restituita dal server? Il caso più spiacevole sarebbe se l'utente chiude la scheda prima ancora che una richiesta sia stata inviata al server. Ma a meno che l'utente non sia estremamente agile o abbia la capacità di rallentare il tempo, questo è quasi impossibile.

Se un'interfaccia utente ottimistica viene implementata correttamente e le interazioni vengono applicate solo a quegli elementi che non aspettano mai più di 2 secondi per la risposta del server, l'utente dovrebbe chiudere la scheda del browser all'interno di quella finestra di 2 secondi. Non è particolarmente difficile con una sequenza di tasti; tuttavia, come abbiamo visto, nel 97-99% dei casi, la richiesta andrà a buon fine, indipendentemente dal fatto che la scheda sia attiva o meno (è solo che una risposta non verrà restituita al client).

Quindi, questo problema potrebbe sorgere solo per quell'1-3% che riceve un errore del server. Poi di nuovo, quanti di quelli si affrettano a chiudere la scheda entro 2 secondi? A meno che non siano in una competizione di velocità di chiusura delle schede, non credo che il numero sarà significativo. Ma se ritieni che ciò sia rilevante per il tuo particolare progetto e potrebbe avere conseguenze negative, utilizza alcuni strumenti per analizzare il comportamento degli utenti; se la probabilità di un tale scenario è sufficientemente alta, limitare l'interazione ottimistica agli elementi non critici.

Non ho intenzionalmente menzionato casi in cui una richiesta è ritardata artificialmente; questi generalmente non rientrano nell'ambito della progettazione ottimistica dell'interfaccia utente. Inoltre, abbiamo dedicato più che sufficiente tempo al lato pessimistico delle cose, quindi riassumiamo alcuni punti principali sull'implementazione di una buona interfaccia utente ottimista.

Regole pratiche

Spero sinceramente che questo articolo ti abbia aiutato a comprendere alcuni dei concetti principali alla base della progettazione ottimistica dell'interfaccia utente. Forse sei interessato a provare questo approccio nel tuo prossimo progetto. In tal caso, ecco alcune cose da tenere a mente prima di iniziare:

• Un prerequisito per tutto ciò di cui abbiamo parlato finora: assicurati che l'API su cui fai affidamento sia stabile e restituisca risultati prevedibili. È stato detto abbastanza.
• L'interfaccia dovrebbe rilevare potenziali errori e problemi prima che una richiesta venga inviata al server. Meglio ancora, elimina completamente tutto ciò che potrebbe causare un errore dall'API. Più semplice è un elemento dell'interfaccia utente, più semplice sarà renderlo ottimista.
• Applicare modelli ottimistici a semplici elementi di tipo binario per i quali non è prevista nient'altro che una risposta di successo o di fallimento. Ad esempio, se un clic su un pulsante presuppone una risposta del server come "sì", "no" o "forse" (tutti potrebbero rappresentare il successo a vari livelli), un tale pulsante sarebbe meglio senza uno schema ottimista.
• Conosci i tempi di risposta della tua API. Questo è fondamentale. Se sai che il tempo di risposta per una particolare richiesta non scende mai al di sotto dei 2 secondi, probabilmente è meglio spruzzare prima un po' di ottimismo sulla tua API. Come accennato, un'interfaccia utente ottimista funziona meglio per tempi di risposta del server inferiori a 2 secondi. Andare oltre potrebbe portare a risultati inaspettati e molti utenti frustrati. Considerati avvisato.
• Un'interfaccia utente ottimista non riguarda solo i clic sui pulsanti. L'approccio potrebbe essere applicato a diverse interazioni ed eventi durante il ciclo di vita di una pagina, incluso il caricamento della pagina. Ad esempio, le schermate dello scheletro seguono la stessa idea: prevedi che il server risponderà con successo per compilare i segnaposto da mostrare all'utente il prima possibile.

Il design ottimistico dell'interfaccia utente non è propriamente una novità sul web, né è una tecnica particolarmente avanzata, come abbiamo visto. È solo un altro approccio, un altro modello mentale, per aiutarti a gestire le prestazioni percepite del tuo prodotto. Essendo radicato negli aspetti psicologici dell'interazione uomo-computer, la progettazione ottimistica dell'interfaccia utente, se utilizzata in modo intelligente, può aiutarti a creare esperienze migliori e più fluide sul Web, pur richiedendo pochissimo da implementare. Ma, per rendere il modello veramente efficace e per evitare che i nostri prodotti mentiscano agli utenti, dobbiamo comprendere i meccanismi della progettazione ottimistica dell'interfaccia utente.

Risorse

• "Tempo di risposta nelle transazioni conversazionali uomo-computer" (PDF), Robert B. Miller, Fall Joint Computer Conference, 1968
• "Presentazione di RAIL: un modello incentrato sull'utente per le prestazioni", Paul Irish, Paul Lewis, Smashing Magazine, 2015
• "Lo stress sul Web mobile: l'impatto della velocità della rete sul coinvolgimento emotivo e sulla percezione del marchio", Tammy Everts, Blog Radware, 2013
• Applicazioni del flusso nello sviluppo umano e nell'istruzione , Mihaly Csikszentmihalyi, 2014
• "Dettagli di progettazione mobile: evita lo spinner", Luke Wroblewski, 2013
• "Perché le prestazioni contano, parte 2: gestione della percezione", Denys Mishunov, Smashing Magazine, 2015