Pianifica interviste utente con un prototipo funzionante in 48 ore: recluta rapidamente, scrivi script di task, prendi appunti e trasforma il feedback in richieste di sviluppo chiare.
Un prototipo funzionante mette fine alla maggior parte delle discussioni rapidamente. Quando qualcuno prova a completare un compito reale, smetti di indovinare cosa farebbe e inizi a vedere cosa fa davvero. Per questo le interviste con un prototipo funzionante battono il dibattere idee in chat, anche se il prototipo è grezzo.
Con 3-6 sessioni puoi imparare molto se mantieni lo scope ristretto. Non otterrai statistiche perfette, ma vedrai pattern ripetuti che puoi correggere questa settimana.
In 48 ore puoi scoprire con affidabilità dove le persone si bloccano o tornano indietro, quali etichette le confondono, cosa provano prima (e cosa ignorano), cosa manca prima che si fidino del flusso e quali momenti generano dubbi, come prezzi, permessi o il salvataggio dei progressi.
Questo approccio evita grandi progetti di ricerca, lunghe survey e esplorazioni troppo aperte. Non stai cercando di mappare tutto il mercato. Stai cercando di rimuovere la frizione più grande in un flusso importante.
Definisci un unico obiettivo di apprendimento prima di programmare chiunque. Un formato semplice funziona bene: “Un utente alle prime armi può fare X in meno di Y minuti senza aiuto?” Se stai costruendo un CRM semplice, potrebbe essere: “Un nuovo utente riesce ad aggiungere un contatto, taggarlo e ritrovarlo?”
Se hai costruito il prototipo velocemente in uno strumento come Koder.ai, l'obiettivo rimane lo stesso: scegli un flusso, osserva persone reali provarlo e cattura esattamente cosa deve cambiare.
Un round da 48 ore funziona solo se riduci lo scope. Scegli un tipo di utente specifico e uno scenario che già conoscono. Se provi a coprire onboarding, prezzi, impostazioni e casi limite nella stessa sessione, finirai con opinioni invece che con evidenze.
Scrivi un obiettivo in una frase come: “Un/una designer freelance alla prima esperienza riesce a creare e inviare una fattura in meno di 3 minuti senza aiuto?” Quella frase ti dice chi è la persona, cosa deve fare e cosa significa “buono”.
Decidi cosa misurerai prima di parlare con chiunque. Tienilo semplice e visibile durante la sessione. Per la maggior parte dei team è una combinazione di velocità (tempo per completare), attrito (quanto spesso si bloccano o chiedono “e adesso?”), problemi di navigazione (esitazione, rilettura, tornare indietro) e segnali di fiducia (preoccupazioni su pagamenti, privacy o errori).
Poi scrivi 3-5 domande che devi poter rispondere entro la fine del round. Esempi:
Non continuare a intervistare solo perché puoi. Decidi in anticipo quando fermarti così puoi tornare a costruire. Una regola pratica: fermati dopo cinque sessioni, o prima se gli stessi primi due problemi si ripetono per tre sessioni di fila.
Esempio: se tre partecipanti su cinque non trovano “Crea fattura” perché nascosto sotto “Fatturazione”, hai già una richiesta di sviluppo chiara: rinomina l'etichetta, sposta l'accesso e ritesta quella modifica.
Puoi condurre interviste utili con un prototipo funzionante in due giorni se lo tratti come uno short sprint: recluta, prepara, esegui e poi sintetizza mentre i dettagli sono freschi. Mira a 3-5 sessioni. Tre è il minimo per individuare i problemi più grandi. Cinque solitamente mostra pattern.
Un piano realistico è:
Se il reclutamento è lento, non aspettare. Riduci lo scope e amplia la disponibilità. Offri più fasce orarie (inclusi mattina presto o sera), accorcia le sessioni a 15 minuti, o recluta da un cerchio più vicino che comunque corrisponde al tuo tipo di utente.
Per mantenere tutto organizzato, crea prima della prima chiamata una piccola struttura di cartelle:
01_Recruiting02_Recordings03_Notes04_Synthesis05_TicketsNomina i file come P01_2026-01-16_Record.mp4 e P01_Notes.md. Questa piccola abitudine rende più facile rivedere i risultati dei test di usabilità del prototipo.
La velocità conta più della perfezione. Il tuo obiettivo non è un campione statisticamente perfetto. È avere 5-8 persone reali che corrispondono più o meno agli utenti che vuoi, prenotate entro un giorno.
Inizia dalle pool più veloci, poi amplia. Parti da persone che già chiedono il prodotto (clienti, utenti in prova, lista d'attesa), poi passa a conversazioni recenti (thread di supporto, richieste di demo, risposte email). Se servono altre, cerca community dove si discute il problema, chiedi introdizioni tramite conoscenti (non opinioni), e contatta ex colleghi o clienti con lo stesso flusso di lavoro.
Mantieni l'invito corto e specifico. Chiarisci che non è una chiamata di vendita e che stai testando il prodotto, non la persona. Indica cosa stai costruendo e per chi, la richiesta (20 minuti in video o audio), cosa faranno (provare 2-3 task su un prototipo) e un piccolo ringraziamento come una gift card, un mese gratuito o una donazione. Offri due opzioni orarie oggi o domani.
Se hai creato un rapido prototipo CRM interno (per esempio in Koder.ai) per freelance, invita sia utenti che lavorano con fogli di calcolo “disordinati” sia persone già usando un CRM. Quel mix ti aiuta a evitare feedback solo dai power user. Inoltre, non contare solo su amici stretti: cercheranno di essere carini.
Gli incentivi devono sembrare normali, non imbarazzanti. Una piccola somma fissa funziona meglio di “paga quello che pensi”. Se offri un mese gratuito, assicurati che non richieda un acquisto.
Infine, prenota riserve. Mira a reclutare due persone in più rispetto al necessario. I no-show succedono e i backup mantengono intatto il tuo programma.
Risparmia ore trattando screening, programmazione e consenso come un unico flusso veloce. Conferma che somigliano al tuo utente reale, prenota l'orario e chiarisci registrazione e presa di appunti prima di incontrarli.
Un leggero screener può essere solo tre domande:
Fai attenzione ai segnali che sprecano le sessioni. Persone lontane dal target daranno feedback sicuri ma non pertinenti. Persone troppo coinvolte (un amico stretto, un partner, qualcuno che sta costruendo la stessa cosa) tendono a spingere un'agenda personale. Persone troppo occupate si affretteranno, faranno multitasking o non si presenteranno.
Per la programmazione, tienila stretta: sessioni da 30 minuti con un buffer di 15 minuti. Il buffer è dove scrivi note pulite, nomini le registrazioni e resetti il prototipo. Se accavalli le chiamate, le note diventano disordinate e i pattern vengono persi.
Il consenso può essere un breve messaggio: chiedi il permesso di registrare, spiega che le note saranno usate per migliorare il prodotto e che le citazioni saranno anonimizzate se condivise. Dai un'opzione semplice: possono dire no alla registrazione e prenderai appunti al suo posto.
Invia un rapido messaggio pre-call con l'orario, la durata prevista, l'agenda (5 minuti intro, 20 minuti task, 5 minuti wrap-up) e cosa serve (laptop o telefono, login se richiesto, luogo silenzioso). Questo evita sorprese come “sono entrato da mobile” che mandano a monte i test di usabilità del prototipo.
Una buona intervista può comunque fallire se il prototipo è disordinato. L'obiettivo non è impressionare con ampiezza. È rendere facile per le persone tentare i task senza finire in dead end o aver bisogno di spiegazioni.
Mantieni il prototipo piccolo. Includi solo le schermate e i percorsi richiesti dai task e nascondi tutto il resto. Un percorso più corto batte un “app completa” a metà.
Fai sembrare i contenuti reali. Sostituisci il lorem ipsum con copy e dati credibili così gli utenti reagiscono naturalmente. Se testi un flusso CRM, mostra 6-10 contatti con nomi, aziende e poche note. Se testi il checkout, usa prezzi e opzioni di consegna realistici. Finto ma specifico vale più di generico.
Prima delle sessioni, decidi cosa osserverai e annotalo ogni volta: dove cliccano per primo, momenti di confusione (cosa dicono e cosa fanno dopo), dove si ripetono o tornano indietro, parole che usano per le funzionalità e domande che rivelano informazioni mancanti.
Configura un account di test dedicato e una routine di reset così ogni partecipante parte dallo stesso stato. Se il prototipo crea record, tieni una breve checklist di reset (svuota il carrello, cancella l'ultimo elemento creato, torna alla schermata principale, esegui logout e login).
Scegli gli strumenti di cattura prima di parlare con chiunque. Registra la chiamata se puoi e tieni un semplice template note con tre colonne: Task, Osservazioni (cosa è successo) e Citazioni (parole esatte). Se usi Koder.ai, fare uno snapshot prima della prima sessione rende più semplice tornare indietro se cambi qualcosa per errore durante la giornata.
Un buon script di task fa comportare le persone come nella vita reale, non come se stanno facendo un test. Mantienilo corto, ripetibile e legato a uno scenario principale. Per un prototipo funzionante, 2-4 task sono solitamente sufficienti per evidenziare pattern senza correre.
Inizia nominando lo scenario principale in parole semplici (esempio: “Voglio impostare il mio primo progetto e invitare un collega”). Poi scegli task che rappresentino i momenti in cui il fallimento sarebbe più dannoso: configurazione iniziale, trovare una funzione chiave e completare un'azione significativa.
Usa la stessa struttura in ogni sessione così i risultati sono comparabili:
Scrivi ogni prompt del task in modo che non riveli il nome del pulsante o il percorso esatto. Male: “Clicca Snapshots e ripristina.” Meglio: “Hai fatto un errore e vuoi tornare alla versione di ieri. Mostrami cosa faresti.”
Dopo ogni task, fai una domanda corta. Prima del click: “Dove inizieresti?” Dopo: “Cosa ti ha portato a scegliere quel percorso?” Se si bloccano, chiedi “Cosa stai cercando adesso?” non “Hai visto il menu?”
Se hai costruito il prototipo in Koder.ai, mantieni i task ancorati ai risultati (crea un'app, esporta il codice sorgente, imposta un dominio personalizzato) piuttosto che ai termini della piattaforma. In questo modo, le tue note si traducono facilmente in richieste di sviluppo.
Inizia ogni sessione allo stesso modo. Abbassa la tensione e rende i risultati più facili da confrontare.
Apri con uno script rapido: ringrazia, spiega che stai testando il prodotto (non la persona) e che non ci sono risposte sbagliate. Chiedi di pensare ad alta voce e di condividere cosa si aspettano prima di cliccare.
Dai un task alla volta e poi rimani in silenzio. Il tuo compito principale è osservare dove esitano e fare brevi domande neutrali come “A cosa stai pensando?” e “Cosa ti aspettavi di vedere?” Evita di insegnare, lodare o difendere il prototipo.
Quando si bloccano, spingi con una domanda che riguardi il loro obiettivo, non l'interfaccia: “Cosa proveresti dopo?” o “Dove cercheresti quello?” Se sono veramente bloccati per più di un minuto, passa oltre e annotalo come problema ad alta gravità. Resisti alla tentazione di correggere il prototipo durante la chiamata. Catturalo e continua la sessione.
Le richieste di funzionalità sono utili, ma non discuterne. Mettile da parte con una domanda: “Quale problema risolverebbe questo per te?” Poi torna al task corrente.
Chiudi con coerenza. Chiedi cosa è piaciuto, cosa ha frustrato, se pagherebbero (e quanto sarebbe giusto) e se puoi ricontattarli dopo l'aggiornamento successivo.
Buone note non sono “tutto quello che è successo.” Sono unità piccole e coerenti che puoi ordinare dopo. Se mantieni la stessa struttura tra le sessioni, i pattern emergono dopo la terza intervista.
Scegli un documento o foglio che tutti gli osservatori usano. Crea una riga per ogni tentativo di task e scrivi note brevi e fattuali sempre negli stessi punti. Un layout semplice:
I timestamp permettono di tornare alle registrazioni e verificare la formulazione. I numeri dei task evitano di confondere problemi tra diversi flussi.
Quando qualcosa va storto, scrivilo come una frase chiara che un collega possa capire senza contesto. Includi il momento, non la tua interpretazione.
Esempio: “T2 06:14: cliccato ‘Salva’ aspettandosi una conferma, ma nulla è cambiato e ha chiesto se ha funzionato.”
Aggiungi una citazione quando rafforza il punto, specialmente per fiducia o confusione (“Non sono sicuro che sia sicuro” o “Da dove comincio?”). Le citazioni facilitano la prioritizzazione perché mostrano l'impatto.
Mantieni i tag piccoli così puoi filtrare rapidamente:
Se il tuo prototipo è stato costruito in Koder.ai, concentra le note sul comportamento dell'utente e sul comportamento del prodotto, non su come il prototipo è stato generato.
Una regola finale: se non riesci a trasformare una nota in un titolo di ticket, riscrivila finché non puoi.
Il modo più veloce per perdere slancio è lasciare il feedback come sensazioni. Trasforma quello che hai visto in richieste di sviluppo che un builder può eseguire senza indovinare.
Inizia raggruppando i problemi per task, non per persona. Se tre persone hanno avuto difficoltà durante “creare un account”, è un solo problema con più punti dati, non tre opinioni separate.
Usa un formato coerente per le richieste così ogni issue è comparabile:
Separa le correzioni di “parole e chiarezza” dai cambi di “scope”. “Non capisco cosa fa questo pulsante” è spesso un problema di etichetta o posizione. “Ho bisogno di esportazioni, ruoli e approvazioni” è una decisione di prodotto più ampia. Mescolarli crea ticket gonfi.
Poi decidi per ogni issue: correggere ora, ritestare o parcheggiare. Un metodo semplice è assegnare impatto utente, sforzo, confidenza (si è ripetuto?) e l'azione successiva (build, re-test o park).
Se lavori in Koder.ai, scrivi il controllo di accettazione in inglese semplice così puoi incollarlo nella chat di sviluppo come istruzione chiara e verificabile.
Un founder non tecnico costruisce un semplice flusso di onboarding CRM in Koder.ai e poi fa interviste il giorno successivo. L'obiettivo è ristretto: un sales rep riesce ad arrivare a “primo affare creato” senza aiuto.
Il reclutamento è rapido: manda messaggi alla rete e a qualche community locale di vendite, offrendo una piccola gift card. Cinque sales rep prenotano slot da 20 minuti nello stesso pomeriggio.
Ogni sessione usa gli stessi tre task letti parola per parola:
In cinque sessioni registrano problemi ripetuti e un paio di blocchi. Due rep non trovano dove importare. Tre pensano che “Reminder” sia un'impostazione di notifica, non un follow-up.
A fine giornata quelle osservazioni diventano richieste di sviluppo che un builder può implementare subito:
Questo è il punto: task coerenti, pattern ripetuti e ticket scritti così chiaramente da poter essere sviluppati lo stesso giorno.
La maggior parte dei risultati scadenti deriva da pochi errori piccoli, non dal prototipo stesso.
Domande guidate come “Ha senso, vero?” ottengono consensi educati. Usa prompt neutri come “Cosa pensi che faccia questo?” e poi stai in silenzio.
Cercare di testare troppo in una sessione crea commenti superficiali e segnali deboli. Scegli 2-3 flussi core.
Cambiare lo script a metà strada rompe la comparabilità. Metti le nuove idee in backlog e mantieni i task stabili.
Note disordinate sono un altro fallimento silenzioso. Se ti affidi alla memoria, ricorderai le parti divertenti, non quelle dolorose. Annota il passo esatto dove si sono bloccati e cosa hanno provato dopo.
Un semplice reality check: se un partecipante dice “Sembra ok” ma impiega 90 secondi per trovare il pulsante successivo, le azioni sono i dati. Il complimento è rumore.
Un'opinione forte può diventare il piano. Tratta le opinioni forti come ipotesi finché non vedi lo stesso problema in più sessioni.
Se fai grandi modifiche, ritestale in fretta. Anche due sessioni brevi possono confermare che hai risolto il problema invece di spostarlo.
Prima di prenotare la prima chiamata, blocca le basi:
Subito dopo ogni sessione, fai un check di tre minuti mentre è ancora fresco: annota le prime tre problematiche e una sorpresa. Se non riesci a nominarle, i tuoi task potrebbero essere troppo larghi o le tue note troppo vaghe.
Lo stesso giorno, fai un breve wrap-up che trasformi le note grezze in decisioni. Raggruppa problemi simili, scegli cosa conta di più e definisci cosa cambierai dopo.
Poi programma un re-test entro 72 ore dal rilascio delle correzioni. Anche tre sessioni rapide possono confermare se la modifica ha funzionato.
Se stai iterando in Koder.ai (koder.ai), Planning Mode può aiutarti a riscrivere i risultati come task limitati (“Cambia X così l'utente può fare Y senza Z”), e gli snapshot rendono semplice provare correzioni rapidamente senza perdere una versione stabile.
Punta a 3-5 sessioni. Tre solitamente rivela i blocchi più grandi, e cinque spesso sono sufficienti per confermare i pattern. Interrompi prima se gli stessi due problemi principali si ripetono per tre sessioni consecutive, poi torna a correggere e ritestare.
Usa una frase che indichi l'utente, il compito e una soglia misurabile. Un buon formato: “Un/a [tipo di utente] alle prime armi riesce a [compito] in meno di [tempo] senza aiuto?” Questo mantiene la sessione focalizzata sul comportamento osservabile.
Scegli 2-4 task che rappresentino i momenti più importanti di un flusso: configurazione iniziale e completamento di un'azione significativa. Mantieni i task basati sul risultato, così testi se le persone riescono a completare l'obiettivo, non se trovano un pulsante con un nome preciso.
Inizia dalle fonti più veloci: persone già vicine al prodotto come utenti in prova, iscritti alla lista d'attesa, thread di supporto o richieste di demo. Mantieni l'invito breve, chiarisci che non è una chiamata di vendita, e proponi due opzioni orarie specifiche oggi o domani per evitare scambi lunghi.
Fai tre domande rapide: cosa usi oggi per risolvere questo problema (o cosa fai invece), raccontami l'ultima volta che hai provato a farlo e cosa è successo, e quale ruolo ti descrive meglio (e perché). Evita persone lontane dal tuo utente target, troppo coinvolte (amici stretti o concorrenti) o troppo occupate per presentarsi concentrate.
Chiedi il permesso di registrare, spiega che registrazioni e note servono a migliorare il prodotto e prometti che le citazioni saranno anonime se condivise. Offri un semplice opz-out: possono rifiutare la registrazione e partecipare comunque mentre prendi appunti.
Limita il prototipo alle schermate necessarie per i task e rendi i contenuti credibili così le reazioni siano naturali. Crea un account di test dedicato e una semplice routine di reset in modo che ogni partecipante parta dallo stesso stato; questo rende i risultati confrontabili.
Inizia ogni sessione allo stesso modo: stessa introduzione, stessi task e rimani per lo più in silenzio mentre lavorano. Usa domande neutre come “Cosa stai cercando adesso?” ed evita di insegnare o difendere il design, perché questo nasconde dove il prodotto realmente fallisce.
Scrivi note brevi e coerenti per ogni tentativo di task: cosa hanno provato, cosa si aspettavano e cosa è successo, aggiungendo una citazione quando conta. Aggiungi un tag di severità semplice (blocca, rallenta, minore) così puoi dare priorità velocemente mentre le evidenze sono ancora fresche.
Trasforma ogni problema ripetuto in una richiesta di sviluppo con cinque parti: problema (una frase), evidenza (osservazione o citazione + dove è successo), impatto (perché conta), cambiamento proposto (cosa cambiare nell'interfaccia o nel flusso) e controllo di accettazione semplice per verificare la correzione nel prossimo test. Raggruppa i problemi per task, non per partecipante.