“Sarà capitato anche a voi”, diceva una vecchissima canzone di Mina… Vi sarà sicuramente capitato di imbattervi in una porta con una grossa maniglia e basta. Sono disposto a mettere i soldi sul tavolo per scommettere che almeno una volta nella vita vi è capitato di spingere e invece avreste dovuto tirare. In quei casi quello che facciamo è guardarci intorno per capire se qualcuno ci abbia visti. Ci sentiamo anche vagamente stupidi: “è una porta, possibile che non la sappia aprire?”
Non siete stupidi, la colpa è del designer
Ho una buona notizia per voi: non è colpa vostra, non è per questo che possono darvi degli stupidi.
In questo caso la colpa è del designer che ha progettato quella porta. Questo tipo di porte, tra noi adepti dell’usabilità, ha un nome. Questa è una tipica Porta di Norman, da non confondere con la più calorica e sicilianissima Pasta c’a Norma.
Una porta cosiddetta di Norman è una porta il cui design (la cui progettazione, più correttamente tradotta) ti suggerisce un uso esattamente opposto a quello che dovresti farne. O anche una porta che dà il segnale sbagliato e ha bisogno di un cartello per correggerla.
Insomma, c’è un maniglione e vi verrebbe da tirare, come suggerisce il maniglione… e invece c’è scritto spingere.
Ora, lo immagino, starete pensando: che cosa c’entra?
La differenza tra testare e dare testate al muro
C’entra perché una delle attività più misteriosamente neglette del mestiere del designer (che ora avremo subodorato è quello di chi progetta) è quella di testare l’usabilità e l’accettabilità dei prodotti o servizi che ci vengono commissionati.
Una cosa per volta. Cominciamo con l’usabilità.
Ammettiamo che voi siate un imprenditore e che abbiate commissionato una nuova, straordinaria, piattaforma digitale per ordinare del cibo a km zero comodamente da casa, visto che avete captato l’opportunità di business che è emersa ai vostri occhi durante il lockdown recente.
La vostra proposizione di valore (Value Proposition) è sicuramente appetibile, avrete pensato: i miei potenziali clienti vivono in una grande città, circondata da orti che producono frutta e verdura buonissimi e in genere si trovano a comprare queste merci in un supermercato, anziché prenderle da sotto casa, dove vengono anche potenzialmente prodotte. Fate commissionare la vostra straordinaria piattaforma che dovrà essere all’altezza della Value Proposition: ci vorranno alcuni mesi affinché possa essere messa a punto e altrettanti per congegnare un servizio di vendita (ndr: di questo parleremo in un altro articolo, ma – spoiler – la piattaforma di e-commerce non esaurisce il compito della vendita).
Avrete certamente condotto dei test interni, funzionali e non, per verificare che tutto il giro funzioni. Lo scenario? La merce appare, un ipotetico cliente la vede, la seleziona e procede all’acquisto. A questo punto, sono certo che avrete fatto anche test per verificare che la transazione economica avvenga in modo corretto, ovvero che risulti e che voi possiate ricevere il pagamento.
Per voi, insomma, la piattaforma l’avete testata. Giusto?
Sbagliato.
Sbagliato perché i vostri sviluppatori non saranno un cliente della vostra piattaforma, a meno di coincidenze territoriali improbabili, così come il resto del team che ci lavora. E comunque, pur essendo clienti, sono clienti particolari: conoscono le logiche di funzionamento.
Provate a immaginare un momento invece Gianluca. Lui vive in effetti a due passi da uno dei vostri orti convenzionati e, dovendo lavorare da casa, da una parte sta tenendo buona la propria piccola Martina, di appena 6 mesi, mentre la mamma è in call per lavoro. Dall’altra ha avuto il compito da Giovanna, la compagna e mamma di Martina, di fare la spesa. Bambina in braccio e cellulare nell’altra mano. Prova a fare la spesa sulla vostra app. Ma l’organizzazione delle verdure per colore che avete scelto la trova ostica. Si innervosisce e poggia il telefono, la spesa la farà dopo. Eppure vi sembrava un’idea eccellente: è quello che fate da sempre. È il vostro modello mentale, diremmo in gergo. Domandatevi però una cosa: avete validato che questo modello mentale valga anche per Gianluca?
Perché Gianluca, non riuscendo a comprare con agilità quello che vuole, mentre sta tenendo in braccio Martina, farà estrema fatica a cogliere la vostra Value Proposition, confondendo una cattiva esecuzione con un servizio di valore rinunciabile.
E c’è anche un’altra questione altrettanto dirimente perché scoprirete che a Gianluca la vostra piattaforma non è utile, come invece pensavate al momento della pubblicazione. Ovvero alcuni mesi, manco pochi, dopo che avrete avuto l’idea e avrete fatto i primi bozzetti (sketch) dell’idea stessa. Se ve lo chiedo ora “Vi è sembrata una buona idea?”, sono abbastanza certo – di nuovo scusate la superbia – che diciate “ma certo che no! L’avrei potuto scoprire prima!” e giù testate al muro e a maledirvi.
Please welcome, usability test
L’ho presa larga, lo so, ma ecco il valore, fondamentale, dei test di usabilità. Ho provato a riassumere, tagliandolo con l’accetta, il motivo per cui avreste dovuto testare la piattaforma, con alcuni potenziali vostri utenti. Un’app, il sito, l’interfaccia di back-office. I siti web delle scuole, che ora zoppicano… Tutto.
Un test di usabilità, in fondo, è una tecnica di ricerca qualitativa e/o quantitativa per validare la bontà delle scelte esecutive e progettuali che avete adottato, quando queste prevedono l’interazione con le persone che avevate in mente come destinatari delle stesse scelte.
Siccome l’abbiamo scoperto prima, non siete degli stupidi, avrete anche capito che questa tecnica di ricerca, che ha tantissime modalità di esecuzione, di ampiezza e profondità, non è necessariamente applicabile solo a app, siti o porte. Anzi, capire come possiamo rendere la vita più semplice alle persone, riducendo il carico cognitivo delle proprie scelte o addirittura anticipandone alcune, si può applicare a tantissime cose. Non siete convinti?
Proviamo a pensare un momento al famigerato piano terra dell’Ikea prima di arrivare alle casse. Alzi subito la mano chi, tra voi, non ha accumulato una porzione maggioritaria di spesa del proprio scontrino passando in quei corridoi diabolici, rispetto all’aver acquistato una nuova cucina, almeno una volta. Come pensate che abbiano testato la bontà di alcune scelte? E come verificano la validità delle modifiche che periodicamente fanno?
Addrizziamo le antenne
Qualcuno, forse, ricorderà questo video e il caso relativo all’uscita del lontano iPhone 4 e la linea che cadeva. Il famoso Antennagate.
Cosa succedeva?
Con una presa vigorosa del telefono fatta con la mano sinistra (un mancino che sta avendo una pessima giornata, ad esempio) dopo diversi secondi la qualità della ricezione del segnale degradava progressivamente. Perché – tecnicamente – veniva cortocircuitata l’antenna che smetteva di funzionare a dovere. Il prodotto, lo sappiamo bene tutti, andò in produzione. E a me, che sono mancino, la linea cadeva. Apple fu costretta a regalare una custodia (un bumper) per ogni telefono venduto. Non avevano fatto sufficienti test con utenti mancini? Non ho nessun dato per sostenerlo, ma non posso neanche dire il contrario.
Parliamo un attimo di come vanno fatti, almeno nella loro accezione accessibile ai più: i test di usabilità qualitativi. Il signor Nielsen, socio di Mr. Don Norman – noto esperto di porte, che abbiamo scoperto prima, oltre che autore di libri fondamentali per ogni designer che si rispetti, dentro NN Group , dice una cosa abbastanza semplice: basta condurre un test di usabilità con anche solo 5 persone per rivelare l’85% di problemi di usabilità di una piattaforma.
Fermiamoci un attimo: non è vero che un designer in gamba o esperto sarà immune da introdurre errori o problemi di usabilità. È vero magari che ne commetterà meno, perché avrà già incontrato lo stesso pattern altre volte e magari avrà imparato a prevedere alcune possibili problematiche, proprio avendo condotto altri test su ambienti simili. Ma no, non vi basta prendere un progettista più bravo per non dover fare dei test con le persone. Anzi, se vi capita che qualcuno dica una cosa del genere scappate a gambe levate mentre chiamate il 911/112.
Steve Krug, uno dei massimi esperti in materia, ha paragonato il test di usabilità alle visite di amici che non vivono nella nostra città.
Quando siamo in loro compagnia, li accompagniamo per una visita turistica e facendo da cicerone riusciamo a (ri)vedere con nuovi occhi le cose di sempre. Insomma, notiamo particolari che nella quotidianità ci sfuggono.
Ma come si fanno?
Il test di usabilità consiste nell’osservare una persona, una per volta, alle prese con il nostro prodotto. Generalmente c’è un ricercatore (o facilitatore) che chiede di svolgere dei compiti aperti (un esempio: “Stai cercando un regalo su questo e-commerce: cosa faresti?”) o chiusi (altro esempio: “Utilizza il menù di navigazione per vedere i corsi di laurea dell’Università”).
Un altro elemento distintivo è la presenza di un secondo ricercatore (o anche più ricercatori), appartato in una saletta di osservazione, al fine di analizzare il comportamento del soggetto.
Ci sono molte varianti del test di usabilità, moderato o non moderato, di persona o a distanza. L’obiettivo resta raccogliere informazioni e migliorare l’usabilità del progetto.
Siti web PA, come trasformarli in “Stargate” dei servizi al cittadino
Piccola panoramica dei vari tipi di test di usabilità:
I test possono essere eseguiti di persona, senza facilitatore, nello stesso luogo o a distanza. Cambiano i costi e la qualità di informazioni raccolte. E noi vogliamo sapere tutto sul nostro prodotto, vero?
Regola n. 1 – Quando fare i test di usabilità
Il più presto possibile!
No davvero, presto, molto molto presto. Sappiamo tutti molto bene che il denaro a disposizione per realizzare un progetto è una quantità finita e spesso risicata. Così come il tempo per farlo. E allora, sappiamo pure che non vogliamo trovarci a 6 mesi dall’inizio di un sanguinoso processo di design e sviluppo di un progetto mediamente complesso e scoprire che abbiamo buttato tempo e soldi, giusto?
Davvero avete risposto giusto? Perché se avete risposto giusto, allora perché si continua a fare così?
Condurre una campagna di test di usabilità in una fase di ideazione, magari al tempo della realizzazione dei primi prototipi cartacei – o se si tratta di un servizio, quando abbiamo un’idea della customer journey che vorremmo far fare ai nostri utenti – può darci una quantità immensa di spunti su come non farci troppo male.
Su carta.
Certo, se disegnate molto ma molto lentamente potreste impiegare moltissimo tempo e moltissimi soldi a fare i prototipi cartacei. Ma insomma forse ancora un filo meno che svilupparla tutta, no?
Regola n. 2 – Quante persone mi servono e quali?
“Meglio un test di usabilità con una persona che nessun test di usabilità” dice il sig. Nielsen, sempre lui. Certo più siamo meglio stiamo, ma il punto non è tanto la quantità ma piuttosto la varietà.
Chiediamoci piuttosto: sto coinvolgendo le persone adatte a ricoprire tutti i ruoli che sono stati pensati nella mia idea o proposizione di valore?
Perché, appunto, se servono delle competenze specifiche per utilizzare il nostro progetto – che so Google Maps per i viaggi interstellari – magari senza quelle competenze è possibile confonderci lo stesso, semplice no? Però se abbiamo accesso a un certo numero di astronauti, magari è più facile che emergano problemi effettivamente bloccanti per il loro uso. Ma la domanda era quanti, giusto? Beh, vi avevo risposto già prima. Se conduciamo una campagna di test con cinque persone, emerge già l’85% dei problemi. Ma, aggiungiamo un pezzo, i problemi emersi da risolvere saranno più di quanti riuscirete a correggerne in un mese di re-design & sviluppo.
Regola n. 3 – Poker face
Esatto, se volete partecipare in prima persona per vedere coi vostri occhi, in diretta, i problemi della vostra creatura, digitale o non, oppure se pensate di condurne in casa – senza competenze professionali ve lo sconsiglio, ma non posso mica abbattervi – almeno provate a fare la famosa poker face. Se uno dei vostri utenti coinvolti si confonde, fa la cosa che voi ritenete sbagliata, oppure non sa cosa fare… Tenetevelo per voi. Non suggeritegli le prossime mosse, non mostratevi spazientiti. Vi autorizzo a morire un po’ dentro, ma non datelo a vedere.
Regola n. 4 – Non sono cavie da laboratorio, è la vostra creatura sotto test
Non dovrete mai far sentire i vostri partecipanti come l’oggetto del test. Loro sono la vostra risorsa e i loro errori sono delle ottime notizie.
Perché? Se avete seguito i miei consigli e avete fatto prima questi benedetti test, saprete anche che c’è ancora tempo finché questo prodotto arrivi sul mercato, pertanto eventuali errori risulterebbero ampiamente correggibili. E ri-testabili.
Regola n. 5 – Ripagate il tempo delle persone
Non fate da soli i test – l’ho già detto – ma se proprio dovete, ricordate una cosa fondamentale. Le persone che prestano il loro tempo per testare un vostro prodotto, il tempo ve lo stanno regalando e anche la loro disponibilità. Ricompensatele: dal buono acquisto fino all’accesso VIP della vostra piattaforma, pensate a una ricompensa per l’aiuto ricevuto perché per voi rappresenterà un valore economico.
BONUS – State ridisegnando un prodotto esistente?
Cominciate con dei test di usabilità. Vi faranno vedere gli errori che magari conoscete già, con gli occhi delle persone e, se siete progettisti competenti, vi aiuteranno a convogliare gli sforzi nella direzione giusta.
Proviamo a vederlo su un esempio concreto. Potrebbe arrivare un collega blasonato e vi propone questa miglioria, rispetto alla precedente.
Apparentemente vi sembra subito significativa, giusto? C’è un pulsante principale, poi ci sono le altre azioni secondarie. Certo, riduce il carico cognitivo. Perfetto, no?
Abbiamo visto che vanno scritti dei task da commissionare alle persone che coinvolgiamo nel test.
Se uno dei task fosse: come cliente devi pagare il lavoro che ha fatto per te una società ACME srl e riassunto dalla Fattura 265, certamente sarebbe più efficace.
E se il task invece fosse “sei un commercialista e devi archiviare la fattura 265 del tuo cliente”… sarebbe altrettanto chiaro?
Nonostante la seconda delle opzioni rispetti alcune regole di progettazione di interfacce visuali, certamente non ne rispetta altre: ad esempio è completamente inutile e anzi controproducente se il mio scopo nell’utilizzo di questa interfaccia non è “pagare fattura” ma “archiviare fattura”.
Dovevamo ricorrere a un test per saperlo? Forse no, probabilmente il designer in questione avrebbe potuto porsi la domanda da solo.
Ma il grandissimo vantaggio dei test è anche un altro: dirimere le situazioni di stallo.
Ammettiamo che ci fosse incertezza sulla bontà o meno di questa seconda implementazione… per quale ragione insistere a far valere l’una o l’altra ipotesi? Una volta selezionata la platea di persone giuste con la quale testare la soluzione, avremo la risposta più accreditata.
Sembra sempre così ovvio, dopo.
