La scena la conosci. Chiedi tre preventivi per il nuovo sito, ricevi tre PDF con voci diverse, prezzi lontani tra loro e nessuna idea di come sarà il risultato. Scegli quello di mezzo, firmi, e per i mesi successivi scopri il sito un pezzo alla volta, sperando che assomigli a quello che avevi in testa.
Il problema non è il fornitore. È il metodo: stai comprando a scatola chiusa una cosa che userai per anni.
Da dove nascono le revisioni infinite
Quando il primo confronto vero avviene sul sito già sviluppato, ogni correzione costa cara. Spostare una sezione, ripensare il menu, cambiare il percorso che porta al contatto: sul codice sono giorni di lavoro, e ogni giro di revisioni logora il rapporto tra te e chi sviluppa.
Non è cattiva volontà di nessuno. È che avete iniziato a parlare della stessa cosa troppo tardi.
Cos’è un prototipo (e cosa non è)
Il prototipo è una versione navigabile del sito, costruita prima dello sviluppo: le pagine chiave, i contenuti veri, i percorsi che l’utente farà davvero. Si apre nel browser, si clicca, si mette in discussione. Non è il sito: è la sua prova generale.
Per questo diciamo che un sito serio si progetta due volte. La prima volta in prototipazione, dove cambiare idea costa ore. La seconda nel codice, dove cambiare idea costa settimane. Sbagliare nella prima fase è economico ed è esattamente il punto: è lì che devi sbagliare.
Cosa deve contenere per essere utile
Un prototipo fatto per firmare in fretta non serve a niente. Uno fatto bene contiene almeno:
- Le pagine chiave con contenuti reali. Non “lorem ipsum”: i tuoi testi, i tuoi prodotti, le tue foto anche provvisorie. Il finto nasconde i problemi.
- Il percorso completo dell’utente, dalla prima visita al contatto o all’acquisto. Se nel prototipo il percorso non si capisce, nel sito non si capirà.
- La versione mobile. È da lì che passerà la maggior parte del tuo traffico, non può essere un adattamento fatto dopo.
- I punti di conversione: dove l’utente ti scrive, chiama, compra. Sono le pagine che pagano tutto il resto.
- Le note su cosa è dinamico: cosa aggiornerai tu, cosa resta fisso, cosa arriva da un gestionale.
”Ma così pago il progetto due volte”
No: paghi una decisione informata. Il preventivo scritto dopo il prototipo è più preciso, perché chi sviluppa sa esattamente cosa deve costruire e non deve gonfiare i margini per coprire gli imprevisti. E tu sai esattamente cosa stai comprando, prima di impegnare il budget grosso.
C’è anche un beneficio meno ovvio: il prototipo ti obbliga a decidere. Quali servizi mettere in prima pagina, come descrivere l’offerta, cosa chiedere nel form. Sono decisioni tue, e prese all’inizio valgono più di qualunque rifinitura grafica presa alla fine.
Come lo applichiamo noi
Nella nostra area Digital Products la regola è fissa: UX e UI prima del codice, prototipo prima del preventivo finale. Prima capiamo insieme cosa deve fare il sito, poi lo mostriamo, poi lo quotiamo, poi lo costruiamo.
È successo anche con il plugin Starpool: l’interfaccia della palette è stata disegnata e discussa su schermate reali prima di scrivere la logica di routing. Le revisioni sono costate minuti, non giornate.
Se stai valutando un rifacimento, il test è semplice: chiedi a chi hai davanti di farti vedere il sito prima di costruirlo. Dalla risposta capirai molto del progetto che ti aspetta.