Prototipazione applicativa: come trasformare i prototipi in routine di prodotto

C'è un momento nella vita di quasi ogni team di prodotto in cui qualcuno guarda uno schermo già sviluppato e dice: "non era proprio quello che immaginavo". Il codice è pronto, lo sprint è finito e la conversazione che avrebbe dovuto avvenire tre settimane fa avviene ora, con i costi moltiplicati.

Questo momento è evitabile. E ciò che lo impedisce non sono più le riunioni, né i documenti. Si tratta di prototipare prima di costruire, abbastanza spesso da diventare routine.

La prototipazione viene spesso trattata come una fase: c'è la fase di scoperta, la fase di prototipo, la fase di sviluppo. Voglio difendere il contrario. Un buon prototipo è un’abitudine quotidiana, economica e usa e getta che serve ad allineare la comprensione ed eliminare i dubbi prima che diventino linee di codice.

Perché prototipare ogni giorno, non solo al kickoff

Quando la prototipazione si limita all’inizio del progetto, diventa un rituale. Il team progetta bellissimi schermi, approva tutto in una riunione e poi scopre, durante l'implementazione, decine di decisioni che nessuno aveva preso. Cosa succede a un campo vuoto? Cosa succede se l'elenco non contiene elementi? Cosa succede se la connessione si interrompe durante il flusso?

Sono questi i dettagli che definiscono se un prodotto è buono o mediocre. E raramente compaiono in un prototipo iniziale, progettato per impressionare e approvare.

L’alternativa è trattare il prototipo come uno strumento di conversazione. Prima di aprire un ticket di sviluppo, qualcuno disegna il flusso, anche se è su carta o in uno schizzo a bassa fedeltà. L’obiettivo non è la bellezza, è l’allineamento. Si tratta di garantire che chi programma, chi progetta e chi decide parlino della stessa cosa.

Giorno per giorno, ciò significa che la prototipazione smette di essere una pietra miliare nel programma e diventa parte del perfezionamento. Ogni volta che c’è ambiguità su come dovrebbe funzionare qualcosa, il prototipo risponde più velocemente di qualsiasi descrizione testuale.

La tesi: il prototipo è uno strumento decisionale, non di consegna

La più grande confusione sulla prototipazione è trattarla come consegnabile. Quando il prototipo diventa una consegna, acquista peso, necessita di approvazione e inizia ad essere difeso da chi lo ha realizzato. Quindi smette di servire al suo scopo.

Esiste un prototipo da mettere in discussione e da buttare via. È il modo più economico per commettere un errore. Se scopri che il flusso è confuso anche nel prototipo, hai perso ore. Se scoperto in produzione, trascorse settimane, più fiducia da parte degli utenti.

Ecco perché sostengo che il prototipo venga misurato da un'unica domanda: ci ha aiutato a decidere qualcosa in modo più sicuro? Se è così, ha fatto il suo lavoro, indipendentemente da quanto fosse raffinato. Altrimenti era decorazione.

Questo cambiamento di mentalità è difficile perché va contro l’istinto di mostrare un bel lavoro. Ma i team maturi comprendono che il valore sta nella decisione presa, non nel file prodotto.

Fedeltà nella giusta misura per ogni domanda

Non tutti i prototipi devono essere uguali. La fedeltà deve rispondere al tipo di dubbio che hai.

Se la domanda riguarda il flusso, in quale ordine appaiono le schermate, cosa viene prima di cosa, uno schizzo a bassa fedeltà fa al caso nostro. Bastano caselle e frecce. Investire in pixel qui è uno spreco.

Se la domanda riguarda la comprensione, l'utente capisce questa etichetta, questa gerarchia, questo pulsante, hai bisogno di qualcosa di più vicino alla realtà, con testi autentici e immagini minimamente rifinite. Le persone reagiscono a ciò che sembra reale.

E se la domanda riguarda il comportamento, questo gesto è intuitivo, questa transizione crea confusione, forse hai bisogno di un prototipo interattivo o anche di un pezzo di codice. Ogni livello di fedeltà ha un costo, e spenderlo inutilmente è l’errore più comune commesso dai team che si innamorano dello strumento.

La regola pratica che utilizzo: inizia sempre con la fedeltà più bassa che risponde alla tua domanda. Sali di livello solo quando il dubbio lo richiede.

Come si connette tutto questo con il resto della squadra?

La prototipazione quotidiana cambia le dinamiche tra design, ingegneria e business. Quando il prototipo viene fatto circolare in anticipo, lo sviluppatore è in grado di evidenziare le restrizioni tecniche prima che il progetto diventi una promessa. Il product Owner può vedere l'ipotesi prendere forma e modificarla. E chi disegna riceve un contesto reale, non solo un briefing.

In un progetto di governo digitale, ad esempio, la prototipazione anticipata è ancora più preziosa. I servizi pubblici servono popolazioni diverse, con diversi livelli di alfabetizzazione digitale, e spesso, in situazioni di stress, richiedono un duplicato, fissano un appuntamento, risolvono una questione in sospeso. Un prototipo testato con cittadini reali rivela barriere che nessun incontro interno rivelerebbe.

Lo stesso vale per una startup che tenta di convalidare un flusso di registrazione. Mostrare un prototipo cliccabile a dieci utenti costa un pomeriggio e può far risparmiare un mese di sviluppo andando nella direzione sbagliata.

La prototipazione, in questo senso, è uno strumento di comunicazione tanto quanto di progettazione. Allinea le persone che pensano in modi diversi attorno a qualcosa di concreto.

I rischi di una prototipazione inadeguata

Anche la prototipazione presenta delle insidie e ignorarle è ingenuo.

Il primo è il prototipo davvero bellissimo. Quando sembra pronto, le parti interessate pensano che il lavoro sia finito e chiedono la consegna immediata, senza capire che la convalida e la costruzione devono ancora arrivare. Un’elevata lealtà crea aspettative a breve termine.

Il secondo è l'attaccamento. Chi ha investito ore in un prototipo tende a difenderlo anche quando i test mostrano problemi. Il prototipo dovrebbe ridurre l'ego nel processo, ma un uso improprio fa il contrario.

Il terzo è confondere il prototipo con la specifica. Un prototipo mostra l'intento, non copre tutti gli stati, gli errori e le eccezioni. I team che trattano il prototipo come un contratto completo scoprono, durante l'implementazione, tutti i buchi che non sono stati coperti.

E la quarta, forse la più insidiosa, è prototipare senza chiedere nulla. Il prototipo senza ipotesi è solo un disegno. Prima di aprire lo strumento, vale la pena scrivere in una frase ciò che vuoi scoprire. Senza questa domanda si producono schermi, non conoscenza.

Rendere la prototipazione un'abitudine sostenibile

Affinché la prototipazione diventi routine, deve essere economica e veloce. Se ogni prototipo richiede un progetto separato, nessuno lo farà quotidianamente. Il segreto è avere componenti riutilizzabili, uno standard visivo già definito e la disciplina di accettare il brutto schizzo quando basta.

La leadership qui fa la differenza. Quando il leader tecnico o di prodotto apprezza il prototipo usa e getta e non richiede rifiniture inutili, il team si sente sicuro di sperimentare. Quando la cultura premia solo il risultato finale, la prototipazione muore alla prima scadenza.

Il vantaggio a lungo termine è silenzioso ma reale: meno rielaborazioni, meno discussioni circolari, decisioni prese sulla base di prove piuttosto che di opinioni. Un team che realizza bene i prototipi commette errori più velocemente e in modo più economico, e commettere errori a basso costo è uno dei maggiori vantaggi competitivi che ci siano.

In fondo, realizzare prototipi ogni giorno è un modo per rispettare il tempo di ognuno. Si tratta di preferire la conversazione difficile adesso, nella bozza, piuttosto che quella costosa successiva, nel prodotto.

Se il tuo team considera ancora il prototipo come una fase isolata e continua a scoprire i problemi troppo tardi, potrebbe valere la pena riconsiderare questa abitudine. Ho scritto di prototipazione, validazione e processo del prodotto qui sul blog e sono disponibile a scambiare idee su come adattarlo alla tua realtà.