Considerazioni sulle performance ed il tempo percepito nel web
Le performance sono un parametro fondamentale da tenere in considerazione quando si lavora sul web: possono far la differenza tra una nuova vendita per un e-commerce e la perdita di un utente per un social network.
Come web designers e web developers è fondamentale vedere le performance come un elemento imprescindibile del nostro workflow, e come tale devono essere prese in considerazione sin dalle prime fasi di progetto. Siamo infatti abituati ad ottimizzare per layout (lo facciamo ogni volta che usiamo il responsive design), ma difficilmente consideriamo le performance come uno dei tasselli fondamentali che compongono il processo di design di un sito.
In una certa misura possiamo dire che le performance sono la user experience.
TIME TO INTERACT
Un modo efficace di misurare le performance web è quello di considerare il Time to Interact (TTI).
Il TTI equivale al tempo trascorso tra l’inizio del rendering di una pagina web, e la possibilità dell’utente di interagire con essa.
TTI SUPERIORI AI 3 SECONDI PORTANO IL 57% DEGLI UTENTI AD ABBANDONARE LA PAGINA.
TECNOLOGIA & DESIGN
Quando si parla di ottimizzare le performance di un sito web si pensa ad un’attività esclusivamente di carattere tecnologico, fatta di ottimizzazione del codice di sviluppo e di fine-tuning del server per ridurre i tempi di risposta. Sicuramente la tecnologia gioca un ruolo fondamentale nelle performance di un sito web. Nel caso specifico parliamo di performance reali, ovvero statisticamente misurabili.
Vi è però un’area di attività dell’ottimizzazione delle performance che chiama in causa anche il design e che lavora sulle cosiddette performance percepite, che si basano su una misura più qualitativa dell’esperienza utente.
INTERVENENDO SUL DESIGN, POSSIAMO LAVORARE SULLA PERCEZIONE DEL TEMPO DELL’UTENTE, LIMITANDO IN PARTE IL PROBLEMA DEI TTI ALTI.
TEMPO PERCEPITO: CASI STUDIO
Vediamo adesso qualche caso interessante in cui, intervenendo sulla percezione dell’utente del tempo di attesa, si sono ottenuti risultati importanti in termini di experience generale di navigazione.
POLAR
Nel 2013 lo staff di Polar (un ‘app simile a Quora) decide, per ridurre i tempi di caricamento, di introdurre all’interno della propria app un browser embed per la visualizzazione di alcuni contenuti.
Per informare l’utente del download del contenuto viene visualizzato un loader al centro di uno spazio completamente vuoto.
Al rilascio molti utenti si lamentano di quanto l’app sia diventata lenta
Non avendo nulla su cui concentrarsi, l’utente percepisce maggiormente il passare del tempo.
Il loader viene allora rimosso, e sostituito con skeleton della pagina.
Il tempo effettivo del download è immutato ma gli utenti apprezzano la velocità raggiunta (che non è cambiata)
Un altro esempio interessante, e per certi versi opposto al caso Polar, è quello relativo alle prime versioni dell’app mobile di Facebook.
Eseguendo un A/B test sulla schermata di caricamento si scopre che l’utente attribuiva la colpa dell’attesa del caricamento all’app stessa, essendoci un loader custom che veniva associato al brand).
Semplicemente adottando il loader di sistema, l’utente attribuiva l’attesa al telefono o la rete lenta, e non direttamente all’app (e quindi al brand).
SOLUZIONI DI DESIGN: IL FEEDBACK
Abbiamo visto fin ora come, per migliorare in una maniera che possiamo definire indiretta le performance di un prodotto digitale (sito/app/…), è possibile lavorare sulla percezione del tempo rispetto all’utente finale. Occorre assicurare che l’applicazione stia lavorando, e che ci sia un effettivo progresso nel caricamento della pagina e quindi, in altre parole, occorre lavorare sul (design del) feedback.
Un feedback deve tendenzialmente rispondere a due domande:
- STATUS ATTUALE — cosa sta succedendo?
- STATUS FUTURO — cosa succederà?
Un feedback è utile quando:
RIDUCE L’INCERTEZZA — rassicurando l’utente del funzionamento corretto dell’applicazione.
OFFRE UN MOTIVO DELL’ ATTESA — influenzando la percezione del tempo.
Un feedback deve esplicitare la maggior parte delle interazioni dell’utente con l’interfaccia.
L’interazione con un bottone ad esempio risulterà più naturale e chiara se ogni stato dell’azione è rappresentato:
- Hover / Focus da Tastiera
- Click / Touch
- Caricamento / Termine azione
NB: In termini di accessibilità vanno prese in considerazione anche le interazioni da tastiera (TAB navigation) e la lettura da screen reader.
IL DESIGN DEL FEEDBACK
Lavorare sul feedback significa andare ad intervenire su una delle seguenti macro categorie:
- Indicatori di progresso
- Feedback testuale
- Animazioni composte
INDICATORI DI PROGRESSO
Gli indicatori di progresso andrebbero usati per tempi di attesa superiore al secondo. Per caricamenti inferiori, infatti, le animazioni possono risultare fastidiose, non dando un reale valore all’utente.
Gli indicatori di progresso si dividono in due tipologie:
INDETERMINATO — per loader o animazioni generiche
Non forniscono all’utente informazioni sui tempi di caricamento. Hanno solitamente animazioni particolari per catturare l’attenzione dell’utente.
DETERMINATO — per loader o progress bar
Possono rappresentare lo svolgimento di una o più azioni. Non si devono mai fermare ne decrescere, altrimenti darebbero la percezione di un malfunzionamento.
Integrate con l’indicazione della percentuale di caricamento o divise in step, possono aiutare l’utente a capire meglio quanto velocemente viene processata l’azione.
FEEDBACK TESTUALE
Per azioni che richiedo più di 10s è consigliabile l’uso di feedback testuali, che possono indicare:
- percentuale di caricamento
- stima del tempo restante
- quanti step mancano
Lo scopo principale di un feedback di questo tipo è dare l’idea che l’operazione svolta sia complessa e che valga la pena attendere.
ANIMAZIONI COMPOSTE
Il feedback basato su animazioni può essere di due tipologie:
- SKELETON SCREEN — Viene subito suggerita la futura struttura della pagina caricandone lo scheletro, dando l’illusione di immediatezza di risposta. Usato da siti come Facebook o Medium.
Come si può vedere qui sotto, il tempo di attesa percepito con un caricamento “a skeleton” è minore rispetto ad un semplice loader, a parità di tempo effettivo di caricamento:
- TRANSIZIONI — Attraverso una serie di transizioni si può mantenere lo schermo “attivo” durante il caricamento. In questo modo l’attenzione dell’utente viene catturata dall’animazione che porta l’applicazione da uno stato ad un altro, diminuendo così la percezione del tempo che passa nel caricare i nuovi contenuti. Questo metodo viene usato per esempio dall’app di Google Search.
Se confrontiamo questo tipo di caricamento dinamico con il semplice loader, è facile vedere come il tempo di attesa percepito sia minore.
