Ho imparato che quando un cliente dice 'non mi convince' sta quasi sempre descrivendo una sensazione, non un problema specifico. Il mio lavoro a quel punto non è difendere il design, è fare domande: 'Cosa non ti convince — la struttura, il colore, il tono del testo?' e soprattutto 'Questo elemento serve all'utente o ti piace a te?'. La seconda domanda è potente perché sposta il frame: non è più una questione di gusto, è una questione di obiettivo.
Il round di feedback è strutturato nel contratto: numero di revisioni incluse, formato in cui viene consegnato il feedback (documento scritto, non chiamata), e deadline per riceverlo. Questo non è burocratico — è protezione per entrambi. Il feedback orale su una chiamata di mezz'ora genera ambiguità che porta a revisioni infinite. Il feedback scritto è più lento da produrre ma molto più utile.
La cosa più difficile è distinguere il feedback che ha senso da quello che non ha senso, senza farlo sentire al cliente come un giudizio. Ho sviluppato una risposta standard per i feedback basati su preferenze personali: 'Capisco questa preferenza, ma ho scelto questa soluzione perché [ragione tecnica/UX]. Possiamo testare entrambe le versioni se vuoi dati concreti'. In questo modo non rifiuto il feedback, lo metto in un contesto più ampio.
L'errore che facevo all'inizio era implementare tutto il feedback senza filtrarlo. Risultato: design ibridi che non seguivano nessuna logica, clienti insoddisfatti anche dopo 5 round di revisioni, e io sempre più confuso su cosa stessi effettivamente cercando di costruire. Oggi il feedback del cliente è input, non istruzione. La differenza è sostanziale.