Usabilità, modelli di business e scelte strategiche | Usabile.it

Usabile.it

usabilità, accessibilità e interaction-design per il web

home » Articoli » Usabilità, modelli di business e scelte strategiche

28/07/2003

Usabilità, modelli di business e scelte strategiche

[di Maurizio Boscarol]

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.

Articoli correlati:

torna su Torna su