I test di usabilità hanno una reputazione ingiusta di essere costosi e lenti. Quando le persone sentono "ricerca utente", immagino uno specchio unidirezionale, un moderatore con una lavagna e una timeline di due settimane. Quella versione del testing esiste e ha i suoi usi — ma non è la versione che la maggior parte dei team di prodotto ha più bisogno la maggior parte delle volte.
La versione che la maggior parte dei team ha bisogno è più semplice: cinque utenti, un prototipo Figma o un ambiente di staging, una videochiamata, e 45 minuti per sessione. Fatto bene, questo porta a galla la maggior parte dei gravi problemi di usabilità prima che vengano spediti. Fatto consistentemente — anche una volta per sprint — produce un miglioramento composto nella qualità del prodotto che nessuna quantità di analitiche post-lancio può replicare.
Ecco come eseguirlo da zero.
Cinque partecipanti è il numero giusto per la maggior parte dei test di usabilità. La ricerca di Jakob Nielsen ha stabilito che cinque utenti scoprono circa l'85% dei problemi di usabilità, con rendimenti decrescenti dopo. Eseguire tre sessioni di cinque utenti in diversi punti del processo di design è più prezioso che una sessione con quindici.
I criteri per il reclutamento sono più importanti del numero. Un test di usabilità con cinque persone che corrispondono strettamente al tuo utente target rivelerà problemi reali. Un test con quindici persone che non corrispondono genererà rumore. Definisci due o tre criteri di screening — ruolo, contesto di utilizzo, livello di comfort tecnico — e rispettali.
La rotta di reclutamento più veloce per la maggior parte dei team è inviare email agli utenti esistenti che hanno dato il permesso di contatto. Offri un modesto incentivo — un buono regalo £20 è sufficiente per una sessione di 45 minuti. Mira a pianificare sessioni entro la stessa settimana; più lungo è il divario tra il reclutamento e il testing, più alto è il tasso di assenza.
L'errore di script più comune è scrivere compiti come istruzioni: "Fai clic su Impostazioni, quindi vai a Notifiche e modifica la tua preferenza in..." Questo dice all'utente cosa fare, il che significa che stai testando se possono seguire le direzioni, non se l'interfaccia è intuitiva.
Scrivi i compiti come scenari: "Immagina che tu stia ricevendo troppe notifiche e tu voglia ricevere solo avvisi quando qualcuno ti menziona direttamente. Mostrami quello che faresti." Questo dà all'utente un obiettivo realistico e ti consente di osservare come effettivamente navigano — incluso dove si confondono.
La parte più difficile della moderazione di un test di usabilità è resistere all'istinto di aiutare. Quando un utente è confuso, ogni istinto dice di saltare dentro e mostrare loro dove fare clic. Ma la confusione è il dato. Un utente che sta lottando ti sta dicendo che qualcosa non va con l'interfaccia — e nel momento in cui intervieni, perdi il segnale.
Chiedi agli utenti di pensare ad alta voce durante la sessione: "Mentre procedi, dimmi semplicemente a cosa stai guardando e cosa stai pensando." Questo produce un flusso continuo di dati su come pensano. Nota non solo gli errori ma le esitazioni — un utente che pausa per tre secondi prima di fare clic sul pulsante giusto ha comunque rivelato un problema di design, anche se alla fine hanno avuto successo.
La fase di sintesi è dove viene creato la maggior parte del valore — e dove la maggior parte dei team taglia gli angoli. Le note grezze da cinque sessioni non sono risultati. Diventano risultati quando dibatti come un team, raggruppi le osservazioni per tema e assegni valutazioni di gravità.
Fai il dibattito lo stesso giorno delle sessioni, mentre le osservazioni sono fresche. Raggruppa i problemi in tre bucket: critico (gli utenti non potevano completare il compito), moderato (gli utenti hanno completato il compito ma con difficoltà o errore significativo), e minore (attrito che non ha impedito il completamento). I problemi critici devono essere corretti prima del lancio. I problemi moderati dovrebbero essere prioritizzati nel prossimo sprint. I problemi minori vanno nel backlog.
Scrivi i risultati in una singola pagina: i tre principali problemi critici, con prove da almeno due partecipanti ciascuno, e un cambio di design proposto per ciascuno. Qualsiasi cosa che abbia bisogno di più spazio di quello appartiene a un documento separato.