Interviste utente con un prototipo funzionante in 48 ore

Cosa puoi imparare con interviste in 48 ore

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.

Imposta un obiettivo ristretto (così le interviste restano focalizzate)

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”.

Scegli un segnale di successo osservabile

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:

• Dove le persone si aspettano di iniziare questo flusso?
• Quale schermata causa la prima vera confusione?
• Quale formulazione le lascia insicure?
• Cosa provano a fare che il prototipo non supporta?
• Cosa le farebbe dire “sì, lo userei”?

Imposta una regola di stop

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.

Il programma da 48 ore (semplice e realistico)

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 è:

• Ore 0-4: Scrivi la frase obiettivo, scegli 2-4 task, redigi un breve messaggio d'invito e inizia il reclutamento.
• Ore 4-12: Prenota slot, conferma l'idoneità, ottieni il consenso e fai un rapido check del prototipo così bug ovvi non rovinano la sessione.
• Ore 12-24: Esegui due sessioni. Subito dopo ognuna, scrivi un riassunto di cinque minuti: cosa hanno provato, dove hanno esitato, cosa si aspettavano.
• Ore 24-36: Esegui una o tre sessioni in più. Mantieni lo script e la configurazione identici così i risultati sono confrontabili.
• Ore 36-48: Sintetizza. Raggruppa le note in temi, scegli i tre problemi principali e trasformali in richieste di sviluppo.

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_Recruiting
• 02_Recordings
• 03_Notes
• 04_Synthesis
• 05_Tickets

Nomina 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.

Recluta in fretta senza pensarci troppo

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.

Seleziona, programma e ottieni il consenso in un solo passaggio

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:

• Cosa usi attualmente per risolvere questo problema (o cosa fai invece)?
• Raccontami l'ultima volta che ci hai provato. Cosa è successo?
• Quale di queste ti descrive meglio: [i ruoli target], e perché?

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.

Prepara il prototipo così le sessioni non deragliano

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.

Scrivi script di task che producono segnali chiari

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.

Uno script semplice riutilizzabile

Usa la stessa struttura in ogni sessione così i risultati sono comparabili:

• Intro (1 min): “Stiamo testando il prodotto, non te. Pensa ad alta voce.”
• Warm-up (2 min): “Cosa ti aspetteresti che questo prodotto ti aiuti a fare?”
• Task (20-25 min): 2-4 task, uno alla volta.
• Wrap-up (3 min): valutazione rapida e una richiesta di miglioramento.

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.

Esegui le sessioni e mantienile coerenti

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.

Prendi appunti che siano facili da sintetizzare dopo

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.

Usa un foglio condiviso per tutti

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:

• Timestamp (mm:ss) e ID partecipante
• Numero del task e schermata in cui erano
• Cosa hanno provato, cosa si aspettavano, cosa è successo
• Una citazione (solo quando conta)
• Tag: severità (alto/med/basso) + tipo

I timestamp permettono di tornare alle registrazioni e verificare la formulazione. I numeri dei task evitano di confondere problemi tra diversi flussi.

Cattura evidenze, non opinioni

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:

• Severità: alto (blocca il task), med (lo rallenta), basso (fastidioso)
• Tipo: confusione, fiducia, mancante, bug

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.

Trasforma il feedback in richieste di sviluppo precise

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:

• Problema: cosa l'utente non è riuscito a fare (una frase)
• Evidenza: osservazione o citazione esatta + dove è successo
• Impatto: perché conta (tempo perso, confusione, abbandono)
• Cambio proposto: cosa modificare nell'UI o nel flusso
• Controllo di accettazione: come saprai che è risolto nel prossimo test

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.

Esempio: cinque interviste che diventano cinque ticket azionabili

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:

• Importa una piccola lista di contatti (CSV o copia-incolla)
• Crea un primo affare per un contatto e spostalo alla fase successiva
• Imposta un promemoria per il follow-up domani alle 9:00

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:

• Aggiungi un pulsante “Importa contatti” nello stato vuoto. Controllo: visibile nella prima schermata; supporta upload CSV e incolla.
• Rinomina “Reminder” in “Follow-up” ovunque. Controllo: etichetta aggiornata su pulsante, titolo modal e messaggio di conferma.
• Crea automaticamente una pipeline predefinita con tre fasi. Controllo: nuovo account ha “New, Contacted, Won”; l'utente può modificare dopo.
• Aggiungi un testo di aiuto inline nel form “Crea affare”. Controllo: una frase sotto “Nome affare” con un esempio; riduce invii vuoti.
• Mostra un banner di successo con il passo successivo dopo ogni task. Controllo: dopo l'import suggerisci “Crea il tuo primo affare”; dopo la creazione suggerisci “Imposta un follow-up.”

Questo è il punto: task coerenti, pattern ripetuti e ticket scritti così chiaramente da poter essere sviluppati lo stesso giorno.

Trappole comuni che sprecano le interviste

La maggior parte dei risultati scadenti deriva da pochi errori piccoli, non dal prototipo stesso.

Trappole che rendono i feedback migliori di quanto siano

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.

Trappole nell'interpretare i risultati

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.

Checklist rapida e prossimi passi

Prima di prenotare la prima chiamata, blocca le basi:

• Obiettivo del round (una frase)
• Profilo utente target (per chi è, per chi non è)
• Domande screener + piano di reclutamento
• Script dei task (2-4 task) + una domanda di follow-up per task
• Piano di reset del prototipo (stato pulito, dati di test)
• Metodo di registrazione (e backup) e testo di consenso
• Template note (issue, citazioni, severità, evidenza)

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.

Wrap-up nello stesso giorno (20 minuti)

• Pattern: cosa hai visto almeno due volte
• Priorità: scegli i primi tre da sistemare
• Prossimi passi di build: scrivi la modifica minima che potrebbe risolvere ogni problema

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.