Blog
Sviluppo Web

Usability test per PMI: come farlo anche senza budget da grande azienda

Come condurre un usability test con budget limitato: metodo lean a 5 utenti, Zoom e task list. Guida pratica per PMI che vogliono migliorare la UX del proprio software.

6 minTeam Sydus8 febbraio 2026

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.

Tag

usability-testUXricerca-utentiPMI

Domande frequenti

Hai ancora dubbi?

Quante persone devo coinvolgere in un usability test?

La risposta basata sulla ricerca è 5. Jakob Nielsen e Tom Landauer dimostrarono nel 1993 che 5 utenti scoprono circa l'80% dei problemi di usabilità di un'interfaccia. Aggiungere più partecipanti ha rendimenti decrescenti: i problemi successivi emersi dal 6° utente in poi sono quasi sempre varianti di problemi già identificati. Per test su più tipologie di utenti molto diverse (es. utenti esperti + utenti nuovi), si possono fare 5 test per segmento.

Il test di usabilità si può fare con dipendenti interni?

Con cautela. I dipendenti che hanno partecipato allo sviluppo o che usano già il sistema hanno un bias cognitivo che li rende utenti atipici: conoscono già i workaround, hanno aspettative calibrate sul sistema attuale, e potrebbero sentirsi a disagio nel criticare qualcosa che i colleghi hanno costruito. Meglio usare dipendenti di altri reparti che non hanno familiarità con il sistema, o utenti di aziende clienti esterne. Se non hai alternativa, esplicita ai partecipanti che stai testando il software, non loro.

Come recluto i partecipanti al test?

Per software B2B, le fonti più efficaci sono: clienti esistenti disposti a dedicare 45-60 minuti in cambio di un feedback genuino (molti lo fanno volentieri), dipendenti di partner o fornitori, o la rete professionale del fondatore/manager. Strumenti come User Interviews o Respondent.io consentono di reclutare utenti con profili specifici pagandoli per la partecipazione (tipicamente 50-100€ per sessione di un'ora per profili B2B). Non usare Mechanical Turk o piattaforme consumer per software aziendali: i profili non corrispondono.