Il tempo soggettivo nella web user experience
Scritto da Andrea | 6.05.2007
La domenica mattina serve anche a dedicarsi a letture e approfondimenti che, durante la settimana, spesso non si ha il tempo di inseguire. In questo caso il pretesto è giunto dalla newsletter di Bruce Tognazzini (uno dei miei esperti di usabilità preferiti, per il suo approccio solido e pragmatico alla materia), dalla quale sono stato invitato alla lettura del suo ultimo articolo, intitolato “Slashing Subjective Time”. Ovviamente non vi nego il rispettivo link:
http://www.asktog.com/columns/071SubjectiveTime.html
L’articolo è un’ottima fonte di spunti per affrontare un problema molto sentito da tutti i webdesigner di questo mondo: la lentezza della fruizione del web. L’aspetto curioso è che da almeno 15 anni il web è medium lento. Nonostante si stia facendo molto per aumentare le capacità trasmissive delle infrastrutture necessarie all’accesso a Internet e per alcuni la banda larga sia ormai naturale, la questione del tempo di latenza tra la richiesta di un contenuto e la sua effettiva disponibilità è ancora percepita come critica da moltissimi utenti.
Tognazzini invita prima di tutto a effettuare una distinzione tra tempo oggettivo e tempo soggettivo: è nell’esperienza di tutti che un’azione che richiede un tempo oggettivamente lungo per essere portato a termine può in realtà essere percepito come relativamente breve. Pensate solo a come siano differenti un’ora passata ad aspettare un tram e un’ora trascorsa a vedere un film appassionante. Non c’è paragone. Eppure entrambi misurano la stessa quantità di tempo. La differenza, chiaramente, è percettiva.
Nella fruizione di un sito web le due “dimensioni” del tempo sono entrambe presenti. Esiste un tempo oggettivo necessario per passare da uno stato A a uno stato B, e un tempo soggettivo determinato dalla percezione che l’utente ha delle azioni eseguite per portare a termine il suo obiettivo. Per migliorare la user experience dobbiamo lavorare su entrambi i fronti.
Tognazzini individua, tra le tecniche attualmente disponibili, un paio di soluzioni utili ad abbattere il tempo oggettivo:
- le tecniche di prefetching, ormai permesse da tutti i browser di ultima generazione e da alcuni plugin (come il Google Web Accelerator), affinché il browser possa pre-caricare in background le risorse che saranno necessarie nelle pagine successive;
- Ajax, per effettuare richieste al server relativamente al solo risultato delle proprie interazioni, evitando di effettuare richieste HTTP anche per le parti costanti dell’interfaccia.
A queste si dovrebbero ovviamente aggiungere tutte le tecniche di caching relative a CSS e script, nonché tutte quelle strategie di progettazione orientate alla costanza degli elementi dell’interfaccia (che quindi permettono al browser di poter recuperare dalla propria memoria elementi già a disposizione anche per la composizione di pagine mai visitate).
Grazie a queste tecniche è possibile diminuire il tempo oggettivo necessario all’interazione con un sito web, influenzando probabilmente anche il tempo soggettivo.
Ma come possiamo lavorare direttamente sul tempo soggettivo? La nostra esigenza dovrebbe essere non tanto quella di accelerare le operazioni da eseguire per ottenere un obiettivo, ma anche e soprattutto di saper evitare tutti quegli aspetti o punti del sito che rappresentano un freno alla percezione di un senso di rapidità.
Tognazzini indica tre metodi per esaminare il proprio sito web in cerca di questi punti. In sintesi essi sono:
- considerare la struttura del sito web (la sua architettura) alla ricerca di tutte quelle pagine o sezioni in cui l’utente non vorrebbe trovarsi: per esempio le introduzioni in flash sono pagine in cui il visitatore non ha interesse a visitare e che lo allontanano dal suo vero obiettivo; tutti questi punti andrebbero eliminati.
- condurre dei semplici test di usabilità cronometrando il tempo che un utente impiega a raggiungere un obiettivo e quindi chiedendo a questo di esprimere quanto tempo, a suo parere, ha percepito sia trascorso; qualora la misura soggettiva sia sensibilmente maggiore di quella oggettiva, e tale indicazione proviene da un ragionevole numero di test, è probabile che nel compito preso in considerazione siano coinvolte azioni e/o pagine problematiche;
- individuare i boredom points (”punti di noia”), pagine in cui l’utente è costretto ad attendere una risposta del server prima di poter proseguire la sua azione: in tal senso potrebbe essere necessario semplificare i compiti per ridurre il numero di questi passaggi oppure adottare una delle soluzioni tecniche in precedenza elencate.
Si pensi per esempio a una situazione d’uso tipica: la registrazione a un servizio web. Rispetto al problema: “chiedere all’utente delle informazioni per poter gestire la sua relazione con il sito”, si può rispondere in due modi. Possiamo chiedere all’utente di fornirci molte informazioni fin dal primo contatto oppure possiamo realizzare moduli di registrazione minimali e consentire l’arricchimento del profilo dell’utente in un secondo momento. Questo secondo approccio sembra il migliore ed è distintivo dei cosiddetti servizi 2.0, ma - come abbiamo visto - si può tranquillamente ricondurre a un set di linee guida di usabilità note da almeno un decennio.
L’obiettivo dell’utente, infatti, non sarà mai fornire al sito dei dati per il solo gusto di farlo. Il nostro utente sta visitando il sito per inviare un video, per usare una casella di posta, per partecipare a un forum, per scaricare un software. Tutto quello che lo allontana dal conseguimento dell’obiettivo vero e proprio è elemento di distrazione e di deviazione rispetto al compito principale. Soprattutto quando le informazioni richieste hanno poco o nulla a che fare con l’obiettivo. Perché, per esempio, dovrebbe interessare se sono maschio o femmina quando devo ottenere un programma per il foto-ritocco? Non essendo nato ieri, so bene il perché… ma la questione è un’altra: ogni volta che l’utente non è al corrente del motivo per cui gli stiamo chiedendo una data informazione, lo stiamo invitando a chiedersi perché ce la deve fornire. E potrebbe anche essere indotto a rinunciare a diventare un nostro utente / cliente se la sua motivazione non è tale da superare il dubbio o se, semplicemente, non dispone dei dati che gli vengono richiesti.
I suggerimenti, su questo fronte, sono:
- se un’informazione non è strettamente necessaria per l’interazione tra l’utente e il sito, si consideri la possibilità di non chiederla subito ma di delegarla a un apposita pagina di gestione del profilo dell’utente;
- se non è possibile eliminarla, si valuti la possibilità di non renderne obbligatorio l’inserimento e si chiarisca in modo evidente la distinzione tra ciò che è obbligatorio e ciò che non lo è;
- in un caso o nell’altro, si sfruttino vincoli e buoni default per accelerare la compilazione dell’utente (per esempio facendo scegliere all’utente da una lista anziché chiedere di scrivere liberamente, oppure usando il profilo del browser per suggerire la lingua o lo stato di appartenenza dell’utente);
Argomenti: Usabilità |
Commenti a questo articolo
Devi essere un utente registrato per lasciare un commento.