Può l’usabilità far modificare anche le scelte strategiche
di un sito e persino il suo business model? Non solo lo può, ma
dovrebbe.

Alcuni anni fa svolsi dei test su un sito commerciale che evidenziarono
come il tipo di proposta commerciale e il modo in cui questa veniva mostrata
agli utenti non venivano assolutamente capiti da questi ultimi. I quali
tuttavia riuscivano perfettamente a muoversi nel sito,
dimostrando di apprezzare strumenti di navigazione, cue visivi e semantici,
convenzioni. In sostanza, il sito si comportava bene, ma gli utenti
non avrebbero mai fatto quello che il business model del sito richiedeva
facessero per rispettare i guadagni attesi. Il test rivelava
che il business model non era adeguato alla realtà dei comportamenti
degli utenti, e avrebbe dovuto essere ripensato. In parte lo fu, ma non
bastò.

Tempo dopo il sito chiuse, nonostante i parametri "funzionali"
fossero buoni (tasso di penetrazione del sito, numero di pagine viste
per utente, eccetera). Le entrate economiche erano troppo poche rispetto
alle previsioni: accadde proprio ciò che i test avevano evidenziato
precocemente. Gli utenti non si comportavano come quel business model
pensava si sarebbero comportati.
Uno dei benefit principali delle tecniche di
usabilità, e in generale di tutte le tecniche di progettazione
centrata sull’utente, è prorio quello di consentire di
prendere decisioni. L’usabilità offre indicazioni, che,
per essere produttive, devono poter incidere sulle scelte: progettuali,
strategiche, di business. L’usabilità è dunque un
grande strumento in mano al management per orientare il progetto, correggerlo,
ripensarlo. Meglio (cioè con maggiori benefici a parità
di costi) se in fase precoce.

Capita invece che l’usabilità venga considerata una specie di
verifica di make-up (e di mark-up….) del sito in fase finale, quando
tutte le decisioni sono state prese e non sono più modificabili.
In quel caso è possibile senz’altro dare qualche utile indicazione:
in fondo, l’usabilità identifica categorie di problemi molto diverse
fra loro. Ma ridurre l’usabilità a un semplice imbellettamento
del sito, senza consentire modifiche anche corpose che investono i vari
settori di produzione (programmatori, designer, ecc.) significa sfruttare
al minimo lo strumento. Più o meno come usare la Ferrari
per andare in ufficio. Certo, ci si va, magari si fa anche bella figura,
ma non è certo un uso efficiente dello strumento…

I requisiti dell’utenza come vincoli di progetto

Uno degli aspetti più trascurati delle tecniche dell’usabilità
è la possibilità di confrontare il punto di vista del progettista
(o del management, o del programmatore, o di chiunque altro ha responsabilità
decisionali nel progetto) con il punto di vista dell’utenza finale. Capita
più spesso di quanto si creda che, nonostante il marketing sia
abituato ad usare focus group per studiare gli utenti, i progetti nascano
su basi fantasiose, o, più frequentemente, che si enfatizzino
nel progetto soprattutto gli aspetti che interessano di più ai
decisori, trascurando invece quelli che interessano di più agli
utilizzatori. La cosa è abbastanza ovvia: i decisori sono
i primi clienti del marketing, che dunque tiene in particolare considerazione
le loro indicazioni, a costo di doverle talvolta imporre ai consumatori
finali. Tuttavia, in un ambito realmente interattivo, è impossibile
costruire prodotti che spingano gli utenti a comportarsi come la dirigenza
vorrebbe si comportassero. Se un utente non vuol fare una cosa, semplicemente
non la farà, per quanti link possiamo mettere
in evidenza e quanti slogan o testi esplicativi inseriamo nella pagina.

Capire cosa realmente vuole un utente da un prodotto o da una certa categoria
di prodotti è essenziale anche per realizzare le esigenze
e le aspettative della dirigenza: ma il punto di vista dell’utente
è un vincolo, e spesso non è modificabile oltre un certo
livello. E’ dunque fondamentale capirlo e tenerlo in debita considerazione
in fase di progetto. L’usabilità ha degli strumenti che meglio
di altri riescono a mettere in evidenza i vincoli dati dalle aspettative
e dal punto di vista di un utente.

Alcuni esempi. Io posso ben pensare che un sito di booking online serva
a catalizzare l’attenzione del mio utente, a dargli un’impressione di
efficienza, affinché questo mi contatti telefonicamente per attivare
realmente il servizio (perché per motivi di sicurezza non voglio
trasferirlo completamente online). La realtà potrebbe non funzionare
così: l’utente si aspetta di fare tutto sul sito, altrimenti perché
dovrebbe raddoppiare gli sforzi (prima informarsi online, poi contattare
il servizio con canali tradizionali: a quel punto meglio rivolgersi direttamente
ai canali tradizionali, visto che deve farlo comunque)?

Ancora: io posso sperare di mettere delle FAQ
nel mio sito in maniera da diminuire il numero delle chiamate al numero
verde di assistenza clienti. Questo può funzionare se i problemi
che l’utente incontra con un servizio (ad esempio un servizio bancario)
non sono gravi, o, meglio, se l’utente cerca semplici informazioni preventive.
Ma se sul suo conto appare un addebito inaspettato, pensate davvero che
l’utente voglia innanzitutto consultare le FAQ? E’ molto più probabile
che, allarmato, si metta alla ricerca di un contatto diretto con la banca,
alzando il telefono o recandovisi di persona. Un’analisi potrebbe evidenziare
che semplicemente l’utente non prende proprio in considerazione l’ipotesi
di avvalersi di FAQ statiche per problemi gravi.

Allo stesso modo, perché un utente dovrebbe sottoscrivere un’assicurazione
online, senza la garanzia di un contatto diretto, se questa non è
economicamente molto più vantaggiosa di uno stesso servizio offline?

Potremmo fare altri esempi tratti da siti reali, dove si chiede agli
utenti di compiere azioni che per loro non sono ovvie o convenienti, o
che richiedono un’apertura di credito al buio nei confronti dell’ente.
Di fatto, poi, questi comportamenti non vengono attuati, e il risultato
è che il sito "non funziona" come se lo aspettava chi
lo ha progettato: non diminuiscono le chiamate all’help desk (anzi, magari
aumentano, per chiedere come funziona il sito…), non si crea fatturato
attraverso l’online, non vengo contattato grazie alle informazioni che
dò sul sito.

Il punto è che tutte queste cose si potevano prevedere
in anticipo. Inserendo tecniche di usabilità (non necessariamente
test: anche questionari mirati, interviste con diverse tecniche) nelle
fasi precoci del progetto, è possibile raccogliere dati sulle aspettative
concrete dell’utenza in rapporto al sito. Cosa gradiscono, cosa si aspettano,
cosa non gradiscono o non si aspettano. E di conseguenza rimodellare il
progetto su ciò che gli utenti effettivamente faranno.

Usabilità o marketing?

Altre tecniche di analisi dell’utenza appartengono al marketing. A volte
è l’obiettivo di queste ricerche, a volte il metodo, ad essere
inadeguato all’online. Un esempio sono i focus group: una tecnica che
consente di raccogliere indicazioni e idee, anche innovative e creative,
su un progetto, un’idea o un prodotto, ma che è soggetta a dinamiche
di gruppo (naturalmente quella tecnica trae beneficio proprio dalle dinamiche
di gruppo opportunamente controllate: solo che non sono adatte
ai nostri scopi). Le azioni online sono invece azioni private,
singole, che ognuno svolge fra sé e sé, davanti ad un computer
con il quale magari non ha nemmeno un buon rapporto. Molto spesso ciò
che qualcuno afferma in contesti di gruppo non è ciò che
vuole o ciò che fa (o riesce a fare) quando è da solo. Spesso
quel che fa davanti ad un computer non è addirittura quello che
pensava di fare.

Anche le interviste condotte in un piano di marketing si concentrano
spesso sugli attributi di un prodotto o sulla propensione a certi comportamenti.
Invece le interviste e i questionari condotti nell’ambito di un
intervento di usabilità tentano di capire quello che l’utente
vuole e si aspetta da un servizio, ciò che gli serve, cosa fa e
farebbe davvero, e cosa invece non vuole fare. Molto spesso questi dati
vengono raccolti ed elaborati attraverso indicatori statistici che danno
un’idea anche della dispersione delle risposte, e queste indicazioni,
sebbene vadano comunque confrontate con obiettivi dell’azienda e possibilità
pratiche, possono far emergere un piano di priorità diverso da
quello che il management aveva in mente.

Il progetto orientato dallo studio preventivo (e controllato in più
fasi) dell’utente (e non dei gruppi) ha bisogno di minori correttivi in
corsa. Se queste analisi vengono condotte al momento giusto possono contribuire
ad evitare spese sbagliate. Ad esempio, se è necessario acquistare
un CMS
per la gestione di un sito, e lo si sceglie senza tener conto delle esigenze
degli utenti, ci si potrebbe trovare a scoprire che quel CMS non
consente di fare (o rende difficile, e dunque crea delle resistenze
da parte dei programmatori che lo devono customizzare) cose che
per gli utenti sono essenziali.
Viceversa, magari ci si accorge che alcuni aspetti che credevamo essenziali
(e che quel CMS consente perfettamente di fare) non sono importanti per
la nostra utenza. E dunque è possibile scegliere e acquistare un
prodotto diverso, magari più economico: ma che sicuramente ci creerà
meno problemi.

Ovviamente le decisioni si prendono sulla base di molte considerazioni,
molte delle quali necessariamente interne all’azienda e non orientate
all’utente. Tuttavia utilizzare tecniche precoci di analisi dei bisogni
degli utenti consente di dare almeno un più equilibrato peso a
questi fattori nei processi decisionali, dove invece sono di solito sottostimati
o, peggio, addirittura distorti (si crede che l’utente voglia quello che
invece non vuole, e non si ha percezione di cosa vuole davvero). Tra le
tecniche adeguate a questo scopo, dunque, menzioniamo i questionari
(aperti o chiusi, con risposte multiple, scale likert, ecc.), le
interviste, il card sorting, l’ideazione di
scenari d’uso, e altri di cui parleremo in futuro.

L’usabilità per prendere decisioni

E’ vero e legittimo dire che l’usabilità e le sue tecniche, se
condotte al momento giusto, servono non solo ad abbellire un prodotto,
ma soprattutto a prendere le corrette decisioni, a orientare le scelte
progettuali, a ripensare persino il business model, ottenendo
così un progetto più adeguato all’utenza. Il costo
ridotto di queste tecniche e i benefici precoci
che ne derivano rendono questo processo molto spesso più economico
del consueto processo che fa partire un progetto e poi lo corregge in
corsa. Molti
autori hanno già dimostrato che la progettazione centrata sull’utente,
anche se in apparenza sembra più dispendiosa di altri metodi, porta
infine a vantaggi economici e ad un risparmo di tempo e risorse. Questa
è esattamente anche la mia esperienza. Ma perché ciò
si verifichi è necessario un management illuminato,
che dia fiducia a questi metodi fin dall’inizio del progetto e sia in
grado di sfruttarne le indicazioni e di dar loro il giusto peso nei processi
decisionali.