C'è una convinzione diffusa nelle PMI che i test di usabilità siano roba da grandi aziende: team di ricerca dedicati, laboratori con specchi unidirezionali, budget a sei cifre. Questa convinzione è sbagliata, e costa cara.
Un usability test efficace richiede cinque utenti, una videochiamata Zoom e un'ora di tempo per sessione. Il problema non è il costo, è la mancanza di abitudine al processo.
Perché il 95% delle PMI non testa e perché sbaglia
I motivi più comuni che sentiamo: "i nostri utenti sono esperti, sanno già come funziona", "non abbiamo tempo", "il software funziona, abbiamo già testato internamente".
Il problema con "abbiamo testato internamente": chi ha costruito il software non può testarne la usabilità. Non perché sia incompetente, ma perché conosce già le risposte. Sa dove si trova il pulsante, sa che quella voce di menu nasconde la funzionalità che sembra in un posto diverso, sa che bisogna salvare prima di uscire dalla schermata. Questo sapere è invisibile ma rende i test interni quasi sempre inutili per scoprire problemi reali.
Il valore del test viene fuori quando qualcuno che non sa vede l'interfaccia per la prima volta e fa cose che nessuno del team avrebbe mai immaginato di fare.
La regola dei 5 utenti: Pareto applicato alla UX
Nel 1993 Jakob Nielsen e Tom Landauer pubblicarono una ricerca che ha cambiato il modo in cui si pensa ai test di usabilità. Analizzando dati da decine di studi, mostrarono che la curva di scoperta dei problemi di usabilità segue la legge di rendimenti decrescenti:
- 1 utente: ~31% dei problemi
- 3 utenti: ~60% dei problemi
- 5 utenti: ~80% dei problemi
- 10 utenti: ~95% dei problemi
Aggiungere utenti dopo il quinto non porta quasi mai problemi nuovi: porta varianti dello stesso problema già identificato. Con 5 sessioni da un'ora ciascuna, hai abbastanza dati per identificare i problemi critici e prioritizzarli per il fix.
Questo è il principio di Pareto applicato alla ricerca utenti: il 20% dello sforzo (5 sessioni) cattura l'80% del valore (problemi di usabilità principali).
Come condurre un test con budget zero
Strumenti necessari:
- Zoom (o Google Meet, o qualsiasi videochiamata con screen sharing)
- Un documento Google Docs o Notion con le task da far completare
- Un foglio per prendere appunti durante la sessione
- Opzionale ma utile: il registratore integrato di Zoom per rivedere le sessioni
Struttura di una sessione (60 minuti):
Introduzione (10 min): spiega al partecipante che stai testando il software, non loro. Non esiste risposta sbagliata. Vuoi che pensino ad alta voce mentre usano il sistema: descrivano cosa stanno cercando, cosa si aspettano che succeda, cosa li sorprende. Questo è il "think-aloud protocol", la tecnica di base di ogni test di usabilità.
Task (35-40 min): dai al partecipante una serie di compiti concreti da completare. I task devono essere formulati in termini di obiettivo, non di azione specifica. Esempio corretto: "Sei un responsabile acquisti. Devi approvare l'ordine fornitore numero 1042." Esempio sbagliato: "Vai nel menu Ordini, clicca su 'In attesa di approvazione' e poi premi il bottone verde." Nel secondo caso stai guidando il test, non osservando come l'utente naviga autonomamente.
Debriefing (10 min): domande aperte alla fine della sessione. "Quale parte del sistema trovi più difficile?" "C'è qualcosa che ti aspettavi di trovare e non hai trovato?" "Se potessi cambiare una cosa, cosa cambieresti?"
Cosa osservare: i momenti di esitazione (l'utente si ferma, guarda lo schermo senza agire), le azioni di backtracking (torna indietro perché ha capito di essere nella sezione sbagliata), gli errori (clicca su qualcosa di diverso da quello che voleva), le verbalizzazioni di frustrazione ("ma questo non lo capisco", "dove sarà...").
Come documentare i risultati
Dopo ogni sessione, trascrivi le osservazioni in un foglio strutturato. Per ogni problema identificato:
- Descrizione: cosa è successo
- Frequenza: quanti utenti su 5 hanno avuto lo stesso problema
- Severity rating (scala 1-4):
- 1 = problema cosmetico (non causa errori)
- 2 = problema minore (rallenta l'utente ma si risolve da solo)
- 3 = problema maggiore (causa errori o richiede aiuto esterno)
- 4 = problema critico (blocca completamente il completamento del task)
Dopo 5 sessioni, costruisci una matrice: righe = problemi, colonne = utenti. Segna con una X ogni volta che un utente ha avuto quel problema. I problemi con X in 4-5 colonne e severity 3-4 sono quelli da correggere nella prossima iterazione.
Quando usare test remoti non moderati
I test moderati (descritti sopra) richiedono la presenza di un facilitatore. Esistono strumenti per test non moderati dove l'utente completa le task in autonomia, registrando lo schermo e la webcam senza nessuno presente in tempo reale.
Maze (maze.design): si integra con Figma per testare prototipi. L'utente riceve un link, completa i task nel proprio tempo e Maze registra tutto: click, heatmap, task completion rate, time on task. Costa da 99$/mese per piano team.
Hotjar Observe: per test su prodotto reale (non prototipo). Registra sessioni di utenti reali con heatmap e session recording. Utile per identificare pattern su scala, meno utile per capire il "perché" senza la parte di think-aloud.
I test non moderati hanno il vantaggio della scala (puoi raccogliere dati da 50 utenti senza 50 ore di facilitazione) e lo svantaggio della profondità: sai cosa ha fatto l'utente ma non puoi chiedergli perché.
Per la prima iterazione di test su un software nuovo, preferisci i test moderati. Per iterazioni successive su problemi specifici già identificati, i test non moderati sono più efficienti.