Una semplice introduzione all'usabilità per sviluppatori.
Molti sviluppatori odiano la parola usabilità per un motivo molto semplice: l'usabilità ci costringe a mettere da parte il codice e a pensare invece al suo funzionamento in relazione con l'interazione utente. Il problema principale è dato dal fatto che uno sviluppatore quasi mai riesce a mettersi nei panni di un utente per il semplice motivo che lui conosce tutti i dettagli del funzionamento interno di un sito o di un'applicazione, mentre l'utente interagisce solo con la sua interfaccia.
Uno sviluppatore lavora sul codice per risolvere problemi specifici. Una volta trovata la soluzione e dopo averla testata con successo, in genere lo sviluppatore pensa che il suo lavoro sia finito. In realtà non è così, perché non ha tenuto conto dell'impatto che questa soluzione avrà sull'usabilità del sito.
Immaginiamo di dover implementare un sistema di validazione di un form tramite JavaScript. Questo form presenta un campo testuale in cui l'utente può specificare il suo numero di telefono. Il campo è corredato da un menu a tendina in cui l'utente può selezionare la sua area geografica.
Il difetto del form è che la validazione del numero di telefono dipende dalla scelta dell'area geografica. Un utente la cui area geografica non è presente nell'elenco non può inviare il form. Aggiungendo il prefisso internazionale +39 al numero si ottiene un errore di validazione. L'utente è in un vicolo cieco.
Probabilmente allo sviluppatore sarà stato detto di implementare in quel modo la già citata soluzione. Ma in un sito famoso in tutto il mondo una simile scelta significa perdere moltissimi clienti. La soluzione è inusabile e dannosa per gli interessi dell'azienda.
La soluzione più semplice sarebbe stata quella di aggiungere un'opzione per cui l'utente poteva specificare il suo numero di telefono indipendentemente dall'area geografica se questa non era presente nell'elenco. Al clic il menu a tendina spariva e al campo di testo veniva aggiunto il prefisso +39 o un messaggio informativo che forniva istruzioni per la compilazione di quel campo.
Questa soluzione è molto più flessibile. La domanda che molti utenti ora si porranno è: in che misura uno sviluppatore è responsabile di un problema di usabilità?
Se consideriamo gli sviluppatori solo come servomotori o automi che obbediscono ad ordini superiori, allora lo sviluppatore non ha nessuna colpa. Se invece pensiamo che gli sviluppatori abbiano una coscienza ed idee proprie, e che quindi siano responsabili di alcune scelte, allora la colpa dello sviluppatore è quella di non aver segnalato il potenziale problema.
In questo caso ci sono due alternative: o lo sviluppatore non ha alcuna nozione di usabilità e quindi non ha notato il problema, oppure lo sviluppatore ha preferito ignorare il problema perché così facendo il suo lavoro non avrebbe necessitato di ulteriori modifiche.
C'è da dire tuttavia che un problema di usabilità è diverso da un problema di programmazione: i due tipi di problemi vivono in spazi diversi e separati. A livello mentale individuare lo spazio di un problema è fondamentale per la risoluzione del problema stesso.
Lo sviluppatore conosce bene lo spazio del suo problema, ossia i form e la loro validazione. Viceversa lo spazio del problema utente ha contorni molto difficili da delineare: non si conosce né l'esperienza né l'alfabetizzazione informatica dell'utente né il suo stato psicologico. Quello che uno sviluppatore sa di un utente riguarda il browser utilizzato, il sistema operativo e un'approssimativa collocazione geografica.
Tutti questi dati così confusi fanno si che in genere si pensi ad un fantomatico utente medio per cercare di implementare soluzioni che vadano bene per la maggioranza degli utenti. Ma non per tutti, come dimostra l'esempio di prima.
Uno sviluppatore per capire il problema utente ha una sola alternativa: usare il Web come utente e non come sviluppatore. In altre parole dovrebbe prestare attenzione e ricordare bene tutti quegli episodi che lo hanno visto vittima di una cattiva usabilità.
La sensazione che si prova in questi casi è frustrazione. Quindi occorrerebbe tenere a mente tutti quei siti e quelle applicazioni legate a questa sensazione specifica. Quali sono state le scelte del sito o dell'applicazione a livello di interazione utente che hanno generato in me quella sensazione?
Lo scopo è quello di fare tesoro delle proprie esperienze come utente per cercare di evitare di commettere gli stessi errori nelle soluzioni che si andranno ad implementare.
Solo in questo modo si riuscirà a colmare quel vuoto che separa il punto di vista interno di uno sviluppatore dal punto di vista esterno di un utente.