Gestione dei feedback nel design: il metodo per revisioni che funzionano

Gestire i feedback nel design significa trasformare commenti sparsi in decisioni. Prima si decide che tipo di osservazioni servono. Poi una persona conduce la revisione, i commenti vengono smistati per priorità e alla fine si comunica a tutti che cosa è cambiato e perché. Questo percorso, il cosiddetto feedback loop, si può progettare come si progetta un’interfaccia o un’identità visiva. In questa guida trovi le fasi, le regole per dare e ricevere feedback utili, una tabella per smistare i commenti, gli strumenti e i segnali che ti dicono se il processo sta migliorando il progetto.
In breve
- Il feedback è utile quando si misura sugli obiettivi del progetto, non sui gusti di chi lo dà: definisci gli obiettivi prima di mostrare una sola schermata.
- Ogni revisione ha bisogno di un facilitatore che gestisca tempi, temi e partecipazione, e il ruolo può ruotare all’interno del team.
- Dopo la sessione i commenti si smistano in tre gruppi: da fare, da discutere, da chiarire. Le richieste che non verranno accolte si documentano con la loro motivazione.
- Il loop si chiude solo quando chi ha dato il feedback vede che cosa ne è stato: un riepilogo subito, un aggiornamento più completo quando il design è cambiato.
- Un processo che funziona si vede da segnali concreti: meno giri di revisione, meno commenti contraddittori, persone che arrivano preparate.
Indice
- Che cosa vuol dire gestire i feedback in un progetto di design
- Prima della revisione: obiettivi, domande e persone giuste
- Durante la sessione: facilitazione e tecniche
- Dopo la sessione: come smistare i commenti
- Chiudere il loop: dire a tutti che cosa è cambiato
- Strumenti e momenti per raccogliere i feedback
- Come capire se il processo sta funzionando
- Gli errori che bloccano il feedback
- Il nostro punto di vista: il feedback funziona quando il team è quello giusto
- Un team di design che sa lavorare sulle revisioni
- Domande frequenti
- Fonti
Che cosa vuol dire gestire i feedback in un progetto di design
Nella pratica, gestire il feedback in un progetto creativo vuol dire raccogliere, analizzare e mettere in pratica le osservazioni per arrivare al miglior lavoro possibile. Non è una riunione a fine progetto: è un ciclo che si ripete a ogni versione.
La guida al design centrato sulla persona dell’amministrazione statunitense descrive il feedback loop in due fasi: si riceve un feedback da una persona o da un gruppo e si rivede il prodotto, il servizio o il sistema sulla base di quel feedback. La stessa guida ricorda a cosa serve: capire quali idee reggono in condizioni reali, rifinire le soluzioni valide e scartare quelle deboli.
Il feedback in un progetto di design arriva da almeno tre direzioni diverse, e ognuna va gestita a modo suo:
- Il team interno (designer, sviluppatori, copywriter): osservazioni tecniche e di coerenza, spesso le più rapide da applicare.
- Gli stakeholder (marketing, vendite, direzione, cliente finale nel caso di un’agenzia): osservazioni sugli obiettivi di business, sul tono, sui vincoli.
- Gli utenti: test, interviste, dati d’uso. È il feedback che dice se il design funziona davvero, non se piace.
C’è poi un significato più ristretto della parola, che conviene tenere distinto. Nella user experience il feedback è anche il segnale che un’interfaccia restituisce all’utente: un messaggio di conferma, un errore, un’animazione. In questo articolo parliamo del primo significato, cioè del processo con cui un team raccoglie e usa le opinioni sul proprio lavoro.
Prima della revisione: obiettivi, domande e persone giuste
La maggior parte dei feedback inutili nasce prima della riunione, quando nessuno ha detto che cosa si sta valutando. Le indicazioni di Nielsen Norman Group sono chiare: definire all’inizio della critica le aspettative sul tipo di feedback richiesto è il modo più semplice per ottenere osservazioni su cui si può agire. Per esempio, si può chiedere di valutare quanto il design risponde agli obiettivi degli utenti.
Prepara ogni revisione con tre elementi.

1. L’obiettivo della versione
Una frase sola: “Questa homepage deve far capire in cinque secondi che cosa vendiamo e portare al modulo di contatto”. Se il progetto è partito da un brief creativo scritto bene, l’obiettivo c’è già: basta riprenderlo. Se manca, un discovery workshop a inizio progetto evita di scoprirlo alla terza revisione.
2. Le domande precise
Invece di “Cosa ne pensate?”, chiedi: “Il percorso dal prodotto al carrello è chiaro?”, “Il tono del titolo è coerente con il posizionamento?”, “Ci sono vincoli tecnici su questa animazione?”. Indica anche che cosa non è in discussione in quella sessione, per esempio la palette già approvata.
3. Le persone giuste
Per coprire usabilità, fattibilità tecnica e obiettivi di prodotto serve un gruppo con ruoli e competenze diversi: sviluppatori, designer, stakeholder, chi segue l’assistenza clienti. Meglio cinque persone con ruoli diversi che dodici che guardano tutte la stessa cosa.
Un consiglio pratico: manda il materiale e le domande almeno un giorno prima. Chi arriva avendo già guardato i file dà commenti più ragionati e meno di pancia.
Durante la sessione: facilitazione e tecniche
Una revisione senza conduzione scivola presto nelle preferenze personali o nella discussione tra le due persone più rumorose. Per questo Nielsen Norman Group raccomanda un facilitatore designato, con il compito di gestire i tempi, tenere il focus e far parlare tutti. Il ruolo dovrebbe ruotare tra i membri del team. La stessa fonte insiste su un punto: facilitare non vuol dire solo tenere l’agenda, ma portare la conversazione verso una conclusione costruttiva.
Due tecniche aiutano a strutturare la sessione:
- Round robin: ognuno, a turno, condivide le proprie osservazioni. Nessuno resta in silenzio e nessuno monopolizza.
- Quote: ogni partecipante dà un numero prestabilito di commenti positivi e di commenti critici, per esempio due e due. Costringe a cercare anche ciò che funziona, che è informazione utile quanto i problemi.
Il facilitatore ha anche un altro compito: riformulare i commenti soggettivi. “Il blu non mi piace” diventa, con una domanda, “Il blu rende il pulsante meno visibile rispetto al resto della pagina?”. NN/g suggerisce proprio questo: collegare ogni osservazione agli obiettivi del design invece che ai gusti di chi parla.
Come dare un feedback sul design che si può usare
Se sei tu a dare il feedback, una struttura semplice funziona quasi sempre:
- Osservazione: che cosa vedi, in modo concreto (“Il prezzo compare solo dopo lo scroll”).
- Impatto sull’obiettivo: perché conta (“Chi confronta offerte potrebbe uscire prima di vederlo”).
- Domanda o proposta: aperta, senza imporre la soluzione (“Possiamo portarlo sopra la piega?”).
Il designer resta responsabile della soluzione. Chi revisiona segnala il problema; dire “mettilo rosso” toglie al team la possibilità di trovare un’opzione migliore.
Dopo la sessione: come smistare i commenti
Una revisione con sei persone può produrre decine di osservazioni. Senza un metodo per ordinarle, il designer finisce per applicare quelle dell’ultima persona che ha scritto o di chi ha più peso nell’organigramma. NN/g propone di classificare i commenti in tre categorie, a cui conviene aggiungere una priorità.
| Categoria | Che cosa contiene | Che cosa si fa | Esempio |
|---|---|---|---|
| Da fare | Osservazioni chiare e coerenti con gli obiettivi | Si assegnano con responsabile e scadenza | “Il contrasto del testo sui pulsanti è troppo basso” |
| Da discutere | Richieste in conflitto con gli obiettivi o con altri commenti | Si negozia con chi le ha fatte, portando dati o motivazioni | “Aggiungiamo tre banner promozionali in homepage” |
| Da chiarire | Commenti vaghi o incompleti | Si chiede un esempio o un dettaglio a chi li ha scritti | “La pagina è un po’ fredda” |
Dentro la categoria “da fare” aiuta separare ciò che va risolto prima del rilascio da ciò che si può migliorare se resta tempo. Per le richieste che il team decide di non accogliere vale una regola: si scrivono, con la motivazione. Dire “non lo facciamo perché rallenta il caricamento della pagina su mobile” prende sul serio chi ha parlato, molto più di un silenzio.
Un registro ordinato delle revisioni, con versioni, commenti e decisioni, è utile anche fuori dal team. Se l’azienda valuta agevolazioni come il credito d’imposta per design e ideazione estetica, avere traccia del lavoro svolto e delle scelte fatte rende più semplice ricostruire il percorso del progetto con il proprio consulente.
Chiudere il loop: dire a tutti che cosa è cambiato

Qui la maggior parte dei team si ferma, ed è qui che il processo si rompe. Secondo Nielsen Norman Group, quando le persone contribuiscono a una revisione e non sanno mai che fine ha fatto il loro contributo, smettono di contribuire e si presentano impreparate alle sessioni successive.
Il follow-up ha due momenti.
- Il riepilogo immediato, entro la giornata. Può essere un messaggio su Slack o Teams in tre righe: che cosa portiamo avanti, che cosa stiamo ancora verificando, che cosa abbiamo deciso di non fare. Conta la precisione, non la lunghezza.
- L’aggiornamento approfondito, quando il design è cambiato. Mostra il prima e il dopo e collega ogni modifica al commento che l’ha generata: “Abbiamo spostato il prezzo sopra la piega dopo l’osservazione di Giulia sul confronto tra offerte”.
È questo secondo passaggio a costruire fiducia. Chi vede le proprie parole diventare una modifica concreta arriva alla revisione successiva con più attenzione, e il loop si rinforza da solo.
Ecco un esempio pratico per un sito e-commerce in rifacimento:
- Lunedì: revisione dei wireframe con marketing, sviluppo e assistenza clienti, 45 minuti, tre domande dichiarate in anticipo.
- Lunedì sera: il facilitatore manda il riepilogo con 9 punti da fare, 3 da discutere, 2 da chiarire.
- Martedì: il designer chiarisce i due commenti vaghi con chi li ha scritti e fissa un confronto di 15 minuti sui tre punti da discutere.
- Venerdì: nuova versione condivisa con le modifiche evidenziate e una nota per ciascuna, comprese le due richieste non accolte e il motivo.
Strumenti e momenti per raccogliere i feedback
Gli strumenti contano meno del metodo. Però un posto unico dove vivono file, commenti e attività evita la dispersione tra email, chat e telefonate. Un esempio di configurazione: le riunioni di revisione del design in Asana si organizzano con un’agenda condivisa, i commenti diventano attività assegnate e l’integrazione con Slack invia notifiche e aggiornamenti al team. Lo stesso schema si replica con altri strumenti di project management e con i commenti nei file di design.
Quanto ai momenti, in un progetto di design tipico servono almeno:
- Revisioni interne brevi e frequenti, anche settimanali, tra designer e sviluppatori.
- Revisioni con gli stakeholder a ogni passaggio di fase: concept, wireframe, UI, prototipo.
- Test con gli utenti prima delle decisioni costose da annullare.
- Una retrospettiva a fine fase o a fine progetto, dedicata al processo stesso.
Se il tuo team produce molti contenuti oltre al design, lo stesso principio vale per il workflow di revisione e approvazione dei contenuti: ruoli chiari, un solo canale, una persona che consolida le richieste.
Come capire se il processo sta funzionando
Retrospettive, aggiornamenti di stato e report servono a monitorare nel tempo l’integrazione dei feedback. Nella pratica, guarda questi segnali:
- Numero di giri di revisione per consegna: se scende da un progetto all’altro, le revisioni stanno diventando più mirate.
- Quota di commenti “da chiarire”: se resta alta, le domande della revisione non sono abbastanza precise.
- Commenti contraddittori tra stakeholder: se arrivano tutti al designer, manca qualcuno che li consolidi prima.
- Tempo tra la revisione e il riepilogo: oltre le 24 ore il loop si raffredda.
- Partecipazione: le persone arrivano avendo visto i file? Parlano tutte o sempre le stesse?
Basta un foglio condiviso con questi cinque valori per progetto. Dopo tre o quattro cicli avrai un quadro chiaro di dove intervenire.
Gli errori che bloccano il feedback
- Nessuna linea guida: senza obiettivi e domande dichiarati, i commenti diventano soggettivi e difficili da applicare.
- Revisioni allargate a tutti: più persone non significa più qualità. Significa più rumore da smistare.
- Feedback su canali diversi: un commento in email, uno in chat, uno a voce. Metà andranno persi.
- Soluzioni al posto dei problemi: “fallo più grande” invece di “non si vede”. Toglie al designer lo spazio per la soluzione migliore.
- Silenzio sulle richieste scartate: chi non riceve risposta pensa di non essere stato ascoltato, anche quando la scelta era giusta.
- Nessun follow-up: il feedback finisce in un documento che nessuno riapre.
C’è anche un riferimento utile da un ambito vicino. Il Design Council britannico descrive un modello di Design Review per l’architettura e il paesaggio. In questo modello chi presiede il panel ha il compito di integrare le diverse opinioni e sintetizzare i punti di vista discordanti in un resoconto chiaro. È la stessa funzione che serve in un team digitale: qualcuno che trasformi tante voci in una direzione.
Il nostro punto di vista: il feedback funziona quando il team è quello giusto
Nei progetti che seguiamo vediamo spesso lo stesso schema: il problema non sono i commenti, è che nessuno li tiene insieme. Il designer freelance riceve osservazioni dal marketing, dallo sviluppo e dalla direzione, ognuno con le sue priorità. Finisce per fare da arbitro senza averne il mandato, e ogni giro di revisione costa giorni e un po’ di fiducia.
Per questo, quando formiamo un team, non selezioniamo solo le competenze tecniche: guardiamo anche al fit culturale e al modo di lavorare insieme. Un team coeso parla la stessa lingua in revisione. Sa dare e ricevere osservazioni sugli obiettivi e non sui gusti, e sa chi ha l’ultima parola su ciascun tema. La gestione centralizzata del progetto fa il resto: le richieste dell’azienda arrivano in un unico punto, dove vengono consolidate prima di passare ai talenti. Così l’azienda può concentrarsi sulla strategia invece di inseguire i singoli freelance.
Il feedback loop, per noi, è prima di tutto una questione di relazioni umane. Gli strumenti aiutano e il metodo serve. Ma sono le persone giuste nel posto giusto a far sì che una revisione diventi un passo avanti e non un passo di lato.
— Marco
Un team di design che sa lavorare sulle revisioni
Se in azienda le revisioni del design si moltiplicano senza portare a decisioni, il punto di partenza può essere capire dove si inceppa il processo. Con il nostro assessment per le aziende analizziamo le tue esigenze e ti indichiamo quali competenze e quale assetto di team servono al tuo progetto.

Con Talent as a service, HOOOP Studio e Fractional Management mettiamo insieme talenti selezionati per design, branding, marketing e sviluppo digitale. La gestione operativa centralizzata tiene in ordine anche il flusso dei feedback. Se vuoi capire come funziona un team esterno integrato nei tuoi processi, leggi la nostra guida al Team as a Service e quella al project management con i freelance.
Domande frequenti
Che cos’è un feedback loop nel design?
È il ciclo con cui un team riceve osservazioni su un design e lo rivede sulla base di quelle osservazioni, ripetendo il passaggio a ogni versione. Un loop completo comprende anche l’ultimo passo: comunicare a chi ha dato il feedback che cosa è cambiato. Senza quel passaggio il ciclo resta aperto e la partecipazione cala.
Quante persone dovrebbero partecipare a una revisione del design?
Non esiste un numero fisso, ma conta più la varietà dei ruoli della quantità. Un gruppo ristretto che copra design, sviluppo, obiettivi di business e conoscenza dei clienti dà osservazioni più utili di una riunione aperta a tutti. Gli altri si possono aggiornare con il riepilogo.
Come si gestiscono feedback contraddittori tra stakeholder?
Si mettono nella categoria “da discutere” e si riportano agli obiettivi del progetto, che fanno da criterio per decidere. Se due richieste restano incompatibili, serve una persona con il mandato di scegliere. La decisione va comunicata a entrambi con la motivazione.
Che differenza c’è tra feedback e approvazione?
Il feedback serve a migliorare il design ed è aperto al confronto. L’approvazione è una decisione formale che chiude una fase e permette di passare alla successiva. Tenerli separati evita due problemi: che ogni revisione diventi un’approvazione mancata e che un’approvazione venga riaperta a ogni commento.
Fonti
- Project Feedback Management For Creative Projects, Filestage
- Feedback, Digital.gov
- Derailed Design Critiques: Tactics for Getting Back on Track, Nielsen Norman Group
- Design Critiques: Encourage a Positive Culture to Improve Products, Nielsen Norman Group
- Closing the Loop: What to Do After a Design Critique Ends, Nielsen Norman Group
- Critica del prodotto, Atlassian
- Riunioni di revisione e feedback sul design, Asana
- Design Review: Principles and Practice, Design Council

