di Antonio Marchese, Amministratore delegato di Visiant Galyleo
L’Obiettivo dell’usabilità è trasferire l’informazione che serve in modo corretto, completo e più velocemente utilizzabile .
Secondo Flower e Hayes, se la scrittura è un processo di comunicazione, chi scrive deve riconoscere l’altra parte, ossia il lettore.
E’ fondamentale, come prima cosa, capire chi sono i nostri utenti, in quanto sono gli utenti che decidono quanta attenzione prestare ad un documento, o in generale ad una interfaccia utente di una applicazione informatica.
Ad esempio, chi compra un televisore non legge il manuale, pensa solo a inserire la spina e ad accenderlo. Non si può dare per scontato che le persone leggano un manuale utente solo perché esiste, così come non si può dare per scontato che prima di utilizzare una applicazione, ad esempio un totem in un ufficio postale o in un aeroporto, gli utenti leggano attentamente le istruzioni.
Se si hanno procedure complicate, o scritte male, o poco user friendly, le persone preferiranno lasciar perdere piuttosto che iniziare. Ecco perché spesso, quando si entra ad esempio in un ufficio postale, il totem per pagare i bollettini fai-da-te è spesso vuoto, mentre la fila allo sportello può durare ore.
La maggior parte delle persone usa un manuale come ultima spiaggia; non lo legge, ma ci si butta quando vi sono problemi che non si sanno risolvere o quando deve completare un’attività poco nota. Allora cerca, salta le pagine, le scorre.
In ambito lavorativo le variabili più salienti sono la mancanza di tempo e lo stress di lavoratori troppo occupati. Non hanno tempo di perdersi in documenti densi e complicati.
Ciascuno di noi, nell’esperienza di tutti i giorni, si sarà accontentato, di fronte a una spiegazione troppo complicata di funzioni di un videoregistratore o del forno, e avrà eseguito funzioni più basic o avrà trovato, dopo molti tentativi, la procedura più corretta. Spesso ci sarà capitato di renderci conto, magari dopo un anno, che la procedura corretta era molto più rapida ed efficace.
La documentazione o una applicazione è utilizzata come fosse uno strumento.
L’approccio è perciò “leggere per fare” e non “leggere per imparare”. Quindi si salta da un capitolo all’altro, o da una finestra all’altra, si cerca la procedura corretta, si cerca di capire variabili e limitazioni alla propria azione e poi si agisce.
Le domande che l’utente si pone sono di tipo problem- driven (“perché non funziona?) o task-driven (“come faccio a …?”), ma quasi mai sono system-driven (“come funziona?”).
Il significato di quanto si legge non risiede nel testo ma nella “testa” di chi ha scritto e di chi leggerà e “decodificherà” il messaggio. Poiché ogni essere umano ha delle sue caratteristiche specifiche, un testo può essere interpretato in modi diversi, tanti quanti sono i suoi lettori.
I lettori interpretano pertanto un documento alla luce delle loro conoscenze e aspettative.
Una montagna vista da un alpinista è diversa da quella vista da un turista della domenica. Un documento che si discosta da questo schema diventa difficile da interpretare e da “mappare” sulle proprie conoscenze.
Quindi sbagliare un’analisi degli utenti produce una documentazione spesso voluminosa ma inutile con costi fuori misura:
- maggior tempo per realizzare una documentazione molto più lunga e complessa di come dovrebbe essere
- maggior presenza di informazioni inutili
- maggiori costi di manutenzione per intervenire a posteriori su richiesta del cliente per apportare modifiche
- maggiori costi di help desk per rispondere a domande di utenti che non riescono a consultare la documentazione
A tutto questo c’è una soluzione, una formula che permette di dare vita a una documentazione “good enough” per quel tipo di utenza. Di seguito si riportano i passi da seguire per produrre una documentazione utente – o interfacce per l’end user - più usabili.
In primis, occorre innanzi tutto spostare la nostra attenzione dal prodotto, tipico di chi promuove (marketing), sviluppa e collauda all’utente. Si chiama user-centered approach verso un product-centered approach.
In questo modo si favorisce:
· L’enfasi sull’utente (identificando eventuali profili differenti), rispetto all’enfasi sul prodotto
· L’utilizzo di terminologia adeguata al livello tecnico dell’utente, rispetto ad una terminologia tecnica indipendente dai diversi profili utente e spesso non ben compresa anche dall’utente esperto
· L’identificazione dei task dell’utente e spiegazione dettagliata dei task specifici
Si raccomanda, quindi, di:
· tenere in considerazione le conoscenze già implicite dell’utente o di quelle mancanti in modo da non dare per scontate informazioni utili alla comprensione e all’utilizzo dell’interfaccia end-user
· Trovare un modo di sapere come la pensa l’end-user. Dipende molto dalla situazione e dal contesto. Rendere partecipe l’utente ma senza fargli perdere troppo tempo!
· Utilizzare le opinioni degli utenti. Questo principalmente per:
1. comprendere il loro livello e confrontarlo con quello che è stato definito in fase di analisi. Si ha l’opportunità con questa esperienza di affinare tecniche di intervista, di sviluppare una capacità di comprensione verso gli utenti.
2. capire quali sono gli argomenti più richiesti ma che non soddisfano abbastanza.
3. mediare sempre le richieste dell’utente.
In secondo luogo, occorre un approccio di role-taking.
Per rendere concreto l’approccio ‘user centered’, che inizia ad affermarsi su larga scala alla fine degli anni 80, si riconosce l’importanza non solo delle capacità e dei vincoli fisici e cognitivi dei singoli utenti, ma anche delle relazioni culturali, sociali e organizzative, nonché degli artefatti cognitivi distribuiti nell’ambiente che influenzano il modo di lavorare dell’uomo.
Occorre pertanto mettersi sempre nei panni dell’utente, o meglio osservare l’utente al lavoro: è l’unico vero modo per capirlo ed immaginarsi/anticipare ciò di cui ha bisogno.
Facendo riferimento al modello di comunicazione, se si vive personalmente la modaltà di lavoro dell’utente si sapranno individuare i suoi bisogni, il suo modo di accedere all’informazione e le sue difficoltà.
Pertanto, affinché un prodotto sia adeguato ai bisogni e alle aspettative degli utenti finali, occorre conoscere bene le caratteristiche degli utenti, le attività che svolgono e il contesto organizzativo e sociale nel quale sono inseriti e operano.
Per quanto attiene invece la facilità di comprensione e di utilizzo, allo stato attuale, sono disponibili principi di usabilità e linee-guida di progettazione consolidati, basati sulle conoscenze degli aspetti cognitivi e comportamentali dell’interazione uomo-computer, che possono agevolare la realizzazione di un prodotto usabile.
Tuttavia, questi aspetti non sono sufficienti. Per garantire l’usabilità è di fondamentale importanza confrontarsi costantemente con gli utenti finali, con coloro che saranno direttamente operativi sul prodotto una volta rilasciato, per verificare, valutare e, eventualmente, misurare le scelte di progettazione in termini di reale soddisfacimento dei requisiti utente.
Postato in: Approfondimenti ICT
