Quando il Mockup Non Basta: Come l'AI ha Salvato Due Progetti Creativi

Nel mio lavoro ho imparato che il brief più difficile da raccogliere non è quello vago, quello si risolve con le domande giuste.

Il più difficile è quello preciso ma intraducibile: il cliente sa esattamente cosa vuole,

ha anche preparato un mockup dettagliato, eppure qualcosa nel passaggio dalla carta allo schermo continua a non tornare.

È successo con due clienti che lavorano entrambi in ambito artistico.

E in entrambi i casi la soluzione è arrivata da una direzione che non avevo considerato all'inizio.

Il Problema: quando un Mockup Non Restituisce un'Esperienza

Chi lavora nel mondo creativo, comee artisti, fotografi, designer, ha spesso una visione visiva molto precisa del risultato che vuole ottenere.

Non si tratta di scegliere un colore o un font: si tratta di una resa grafica specifica,

di un effetto, di una sensazione che una pagina deve trasmettere quando la navighi.

Qualcosa che un mockup statico, per quanto dettagliato, non riesce a comunicare del tutto.

Il problema nasce qui.

Un mockup è un'immagine ferma.

Un sito è un'esperienza in movimento: ha transizioni, animazioni, comportamenti al passaggio del mouse, risposte allo scroll.

Il cliente vede il mockup e pensa, comprensibilmente, che la controparte web sia un esercizio di copiatura fedele.

In realtà sta descrivendo un risultato senza poter descrivere il percorso per arrivarci.

Quando le istruzioni sono "deve sembrare così" e il "così" esiste solo nella testa del cliente,

si entra in un territorio fatto di iterazioni, aggiustamenti, approssimazioni successive.

Ore di lavoro in più da parte mia, frustrazione crescente da parte del cliente che,

non sapendo nulla di programmazione, e giustamente, non capisce dove stia il problema.

E inizia a chiedersi se stia chiedendo troppo, o se si sia rivolto alla persona sbagliata.

È un pensiero che posso comprendere. Ed è esattamente quello che è successo in entrambi i casi di cui parlo.

La Svolta: usare l'AI come Terreno Comune

A un certo punto, su suggerimento mio, abbiamo deciso di coinvolgere Claude nel processo.

Non per generare il sito, quello resta lavoro mio,

ma per trovare una quadra tra quello che il cliente aveva in testa e quello che io dovevo tradurre in codice.

Non entro nel dettaglio del processo perché non è questo il punto dell'articolo 

e perché diventerebbe un articolo tecnico, che non è quello che voglio scrivere qui.

Se sei curioso di come integro l'AI nel mio lavoro in modo più generale, ho scritto un articolo dedicato.

Quello che conta è il risultato: dopo qualche iterazione, sotto la mia guida, con circa un'ora di lavoro insieme,

avevamo un riferimento in codice che restituiva fedelmente l'effetto che il cliente voleva ottenere.

Non il sito finito, non qualcosa da mettere online così com'era.

Un punto di partenza condiviso, concreto, navigabile.

Qualcosa che entrambi potevamo vedere, toccare e usare come riferimento preciso per il resto dello sviluppo.

La reazione del cliente è stata di sollievo.

Aveva iniziato a temere che quello che voleva non fosse tecnicamente ottenibile,

non aveva riferimenti di altri siti con effetti simili, non riusciva a spiegare a parole quello che vedeva nella sua testa,

e ogni iterazione che non centrava il bersaglio alimentava il dubbio di stare chiedendo qualcosa di impossibile.

Vedere il risultato prendere forma esattamente come lo immaginava ha chiuso quella spirale in un'ora.

Perché Funziona (e Quando Non Funziona)

Questo approccio non è universale. Perché funzioni servono due condizioni.

La prima: il cliente deve avere un minimo di dimestichezza con l'intelligenza artificiale, o

almeno la disponibilità a lavorarci con un po' di guida.

Non serve essere esperti, serve non avere resistenza verso lo strumento.

La seconda: lo sviluppatore deve saper costruire prompt efficaci.

L'AI non legge nel pensiero, risponde a quello che gli chiedi, nel modo in cui glielo chiedi.

Guidare il cliente attraverso il processo di descrizione dell'effetto che vuole ottenere,

trasformarlo in istruzioni utilizzabili, valutare i risultati e iterare nella direzione giusta:

questa parte richiede competenza tecnica ed esperienza con lo strumento.

Detto questo, quando le condizioni ci sono, il guadagno è reale per entrambe le parti.

Il cliente ottiene un riferimento visivo concreto invece di rincorrere un'idea astratta.

Io parto con le idee chiare invece di procedere per tentativi.

Meno ore di lavoro sprecate, meno frustrazione, risultato finale più fedele all'intenzione originale.

Cosa Cambia nel Modo di Lavorare

Questi due casi mi hanno convinto di una cosa: su progetti creativi con requisiti grafici complessi,

investire un'ora all'inizio per allinearsi visivamente vale sempre più delle ore che si perdono a correggere il tiro a sviluppo avanzato.

Un mockup statico descrive un risultato.

Un prototipo in codice, anche grezzo, anche imperfetto, descrive un'esperienza.

E su certi tipi di progetti, la differenza tra le due cose è enorme.

Se stai lavorando a un sito con una componente creativa forte che sia un portfolio, un sito per un'artista, una pagina con effetti visivi specifici

e temi che le tue idee siano difficili da comunicare, contattami per una consulenza gratuita.

Troviamo insieme il modo di tradurre quello che hai in testa in qualcosa di concreto, prima ancora di iniziare a sviluppare.

---

Ti è capitato qualcosa di simile, dalla parte del cliente o dello sviluppatore? Scrivilo nei commenti.