Ti è mai capitato di ritrovarti davanti al tuo collega designer o sviluppatore e avere la sensazione di parlare due lingue diverse?

Se sei un designer, forse ricordi quel progetto curato nei minimi dettagli… finché lo sviluppatore non ti ha guardato e, con aria rassegnata, ha detto:

“Sì, bello… ma così non si può fare.”

Se invece sei uno sviluppatore, magari ti sei visto trascinare in discussioni infinite su ombreggiature, allineamenti e micro-animazioni, mentre nella tua testa rimbombava un unico pensiero: “Possiamo prima far funzionare tutto senza che esploda?”

Situazioni come queste nascono quasi sempre da un cortocircuito comunicativo: prospettive diverse, priorità diverse, processi diversi. Eppure, al di là di queste frizioni, designer e sviluppatori mirano alla stessa cosa: creare un prodotto solido, utile, piacevole da usare e facile da mantenere.

La domanda allora è: come si passa da una dinamica fatta di malintesi e attriti a un vero rapporto di collaborazione, in cui ciascuno valorizza il lavoro dell’altro?

In questo articolo raccontiamo come, in Buildo, abbiamo affrontato proprio questa sfida, trasformando le differenze in un punto di forza.

Il problema della collaborazione

Nonostante anni di “Agile” e “Lean”, la collaborazione tra designer e sviluppatori soffre ancora troppo spesso di incomprensioni e lacune. Questa è una delle cause principali di inefficienze e di calo nella qualità del software prodotto.

Secondo il DesignOps Assembly Benchmarking Report, esistono aree di collaborazione critiche che continuano a rappresentare un freno per i team di design e sviluppo. Le più problematiche riguardano:

• Adozione e maturità del design system (68%)
• Organizzazione dei file e dell’ecosistema di design (67%)
• Documentazione del design (66%)

Queste inefficienze non sono solo questioni operative: hanno un impatto diretto sul business. Il report mostra infatti che quasi due terzi (65,9%) dei professionisti dichiarano di sprecare tra un quarto e metà del proprio tempo proprio a causa di problemi nella consegna del design.

Gli effetti sull’organizzazione sono evidenti e ricorrenti:

• calo del morale dei team di design
• diminuzione della produttività dei designer
• ritardi nel rilascio delle funzionalità

Questi numeri ci hanno portato a porci una domanda semplice ma fondamentale: quando c’è disallineamento, qual è davvero la causa?

Secondo il report State of the Designer prodotto da Figma, il 91% degli sviluppatori e il 92% dei designer ritengono che ci sia ancora molto margine di miglioramento nel processo di collaborazione. Le radici del problema sono sorprendentemente meno tecniche di quanto spesso si pensi. Le sfide principali evidenziate dai team includono:

• differenze nelle assunzioni e nei modelli mentali
• differenze nelle priorità e nelle motivazioni
• scarsa comprensione del processo dell’altra figura
• stili linguistici e comunicativi molto diversi

In altre parole, non è solo un problema di strumenti o metodologie: è un problema di allineamento, aspettative e comunicazione. Ed è proprio qui che una migliore collaborazione  può fare la differenza.

Due mondi distinti?

Alla base di questo disallineamento persistono preconcetti reciproci: i designer vedono gli sviluppatori come poco attenti all’esperienza utente, concentrati solo sulla sfida tecnica, mentre gli sviluppatori percepiscono i designer come troppo focalizzati sull’estetica, spesso distanti da vincoli tecnici e priorità di implementazione.

Entrambe le assunzioni, ovviamente, sono sbagliate.

Sviluppatori e designer condividono lo stesso obiettivo, ovvero creare prodotti di qualità, ma lo affrontano da prospettive diverse: i primi coltivano empatia per l’utente attraverso performance, accessibilità e manutenibilità, mentre i secondi bilanciano fattibilità e valore senza rinunciare a chiarezza e coerenza dell’esperienza.

Il segreto non sta nell’appianare queste differenze o stabilire quale delle due visioni sia “più corretta”, ma nello sfruttare le peculiarità e i punti di forza di ciascun ruolo in modo complementare. Se bilanciati correttamente, possono generare una tensione positiva, con i designer che spingono per l’innovazione e gli sviluppatori che cercano di farla diventare realtà.

Tutto questo nasce da trasparenza e comunicazione: obiettivi condivisi, contesto comune, linguaggio allineato, e una reciproca comprensione delle difficoltà e delle priorità di ciascuno.

Sostituire l’handoff con una collaborazione continua

Una delle domande che sentiamo più spesso è: “Come possiamo migliorare l’handoff tra design e sviluppo?”.

Questa domanda, però, rivela una visione ancora molto lineare del processo di sviluppo, che non ha ancora del tutto abbandonato il modello waterfall del passato.

In questo modello, gli sviluppatori vedono per la prima volta il design solo quando devono iniziare a implementarlo. A questo punto, però, molte delle decisioni sono già state prese: gli stakeholders hanno già approvato i prototipi, e le scadenze di rilascio sono già state definite.

L’handoff diventa quindi un momento critico e carico di tensione: gli sviluppatori non hanno partecipato al processo di raccolta e definizione dei requisiti (e quindi non hanno contesto delle decisioni prese), e rimane poco spazio per contributi tecnici o iterazioni. A questo punto è spesso troppo tardi per proporre soluzioni alternative, negoziare compromessi tecnici o provare a semplificare la soluzione mantenendo il valore inalterato. Ne deriva frustrazione da entrambe le parti, e il “non si può fare” diventa spesso la risposta più semplice, se non l’unica possibile.

E se sostituissimo completamente l’handoff con una collaborazione costante già dalle prime fasi del progetto? Avere gli sviluppatori a bordo già dal principio, anche nelle fasi di discovery o ideazione, renderebbe il passaggio di consegne addirittura superfluo, perché ci sarebbe già allineamento su obiettivi e decisioni, consentendo anche di mantenere un feedback loop più rapido e costante.

Strategie pronte all’uso per collaborare in un progetto

Vediamo nel dettaglio come possiamo intervenire in ogni fase del progetto, applicando questa mentalità diversa.

Kickoff: Prepariamo il terreno

L’inizio di un nuovo progetto (o di una nuova fase all’interno di un prodotto) è il momento ideale per definire le regole della collaborazione, introdurre novità o correggere ciò che non ha funzionato in passato.

È utile prevedere uno o più incontri preliminari in cui il team (direttamente o tramite figure chiave) si allinei su obiettivi, tempistiche e aspettative, iniziando così a costruire un terreno e un linguaggio comuni.

In questa fase va anche chiarita, o aggiornata, la distribuzione delle responsabilità.

‍

Oltre alle attività principali di ciascun ruolo (ricerca, design, sviluppo, ecc.), molte attività secondarie ricadono spesso in un limbo senza un vero owner esplicito, diventando così la prima causa dei conflitti. A seconda del progetto, può essere utile definire, ad esempio:

• Chi gestisce le relazioni con le altre funzioni (content, marketing, stakeholder esterni)?
• Chi garantisce che vengano eseguiti i desk check tecnici tra designer e sviluppatori?
• Chi si occupa dell’organizzazione delle demo verso gli stakeholders?
• Chi garantisce la formalizzazione di requisiti o criteri di accettazione?

Definire le responsabilità di ciascuno già da questa fase iniziale aiuta a sentirsi partecipi al progetto, evita futuri malintesi e permette di pianificare attività di supporto alle attività principali dell’altro ruolo (ad esempio, prevedere del tempo per la review tecnica del design).

Ogni processo veramente efficace si basa inoltre su un ciclo continuo di miglioramento.

È quindi importante ritagliarsi un momento per riflettere sulle specificità del progetto, integrare i feedback passati e definire azioni correttive, sia sul piano tecnico che organizzativo.

A delle attività di kickoff più tradizionali (incentrate sul chiarire il contesto, gli obiettivi e le milestone del progetto) si possono affiancare ragionamenti più operativi, volti a stabilire strumenti, processi e modalità di collaborazione. Questo è un ottimo momento per riflettere su cosa non ha funzionano in passato nella comunicazione tra ruoli, e pensare a quali cambiamenti introdurre per provare a risolvere le difficoltà.

Se, ad esempio, in passato è successo di arrivare in produzione con dei difetti grafici, potremmo prevedere più momenti ritualizzati di verifica dell’implementato. Se ci sono state incomprensioni sul design prodotto nel momento in cui veniva dato in mano allo sviluppo, potremmo pensare a degli incontri di confronto, o di sperimentare delle sessioni di co-design, o ancora di formalizzare dei processi di coinvolgimento del design durante lo sviluppo. Ogni nuova sperimentazione partirà da pain point precisi, e dovrà includere delle metriche atte a decidere se ha portato un reale miglioramento rispetto al passato.

Discovery & Definizione dello scope: Esploriamo insieme

Troppo spesso, gli sviluppatori vengono coinvolti solo dopo la finalizzazione e convergenza della fase di discovery.

Includerli già nelle prime fasi di ricerca e ideazione, non come supervisori, ma come partner nell’esplorazione, può invece rendere la collaborazione molto più fluida ed efficace: si condivide il contesto, l’handoff diventa più naturale (o persino superfluo), cresce l’empatia delle figure più tecniche verso stakeholder e utenti e si ottiene una validazione tecnica precoce delle soluzioni proposte, prima che queste raggiungano gli stakeholder per l’approvazione.

Si potrebbe obiettare che questo approccio richieda troppo tempo o organizzazione, ma esistono formati semplici da introdurre senza stravolgere i processi esistenti.

Sessioni come Crazy 8 o 6-up 1-up, ad esempio, permettono di coinvolgere gli sviluppatori nel brainstorming, allineandoli contemporaneamente sugli obiettivi e raccogliendo input divergenti e più tecnici con un minimo sforzo di preparazione.

‍

Incontri di Value–Effort, invece, aiutano a discutere e negoziare il valore e il costo di sviluppo di una funzionalità o di soluzioni alternative, integrando la prospettiva dell’utente con quella di sforzo tecnico.

Infine, potreste provare a organizzare sessioni di stime condivise: sviluppatori e designer stimano reciprocamente l’effort richiesto nelle fasi di ideazione, prototipazione e sviluppo. Non serve puntare alla precisione: il vero valore nasce dalle discussioni che emergono quando le percezioni sull’effort richiesto dall’altro ruolo divergono in modo significativo.

Delivery: Mantenere viva la conversazione

Nella fase di Delivery, l’attenzione di sposta man mano verso il lavoro dello sviluppatore. È però fondamentale mantenere sempre attivo il coinvolgimento dei designer, per validare l’implementazione e gestire con agilità eventuali cambi di rotta nei requisiti.

Da un lato, è importante lavorare insieme per definire con chiarezza i requisiti dell’applicazione, sciogliendo dubbi e prevenendo possibili blocchi. Per nostra esperienza, è estremamente utile la produzione di un documento condiviso, la fonte di verità sul comportamento atteso del prodotto (sottoforma di specifiche, user stories, product requirements o il formato che più preferite), su cui continuare a iterare nelle fasi successive.

Dall’altro, demo interne, sessioni di desk check o incontri di revisione regolari aiutano a mantenere viva la collaborazione: permettono ai designer di validare quanto implementato prima che arrivi agli stakeholder o ai clienti, e offrono agli sviluppatori un canale diretto per chiarire dubbi o proporre miglioramenti in modo rapido.

La cultura del feedback

Tutto quanto visto finora ha alla base un prerequisito fondamentale: saper comunicare e scambiarsi feedback continui su ciò che sta funzionando e su quanto invece può essere migliorato.

Con l’esperienza, abbiamo realizzato come le difficoltà incontrate nello svolgimento delle attività pratiche hanno quasi sempre alla base dei problemi di comunicazione o incomprensioni tra le diverse figure.

Per questo motivo, e notato la tendenza dei nostri team a concentrarsi molto spesso sul problema tecnico, senza però risalire fino al problema di collaborazione alla base, abbiamo sperimentato l’introduzione di “retrospettive del cuore”: alle più tradizionali retrospettive operative (basate ad esempio su formati come “liked, learned, lacked”) abbiamo intervallato degli incontri dove il focus si sposta sui sentimenti e le interazioni tra i membri del team. Analizzando episodi concreti con l’aiuto di una figura esterna (come può essere una figura di People & Culture), cerchiamo di capire dove la collaborazione e la comunicazione hanno incontrato degli ostacoli, pensando a come migliorare in futuro dal punto di vista dell’interazione umana.

Come già visto nella fase di kickoff, diventa poi indispensabile garantire un processo in cui i problemi e le azioni correttive pensate durante queste retrospettive vengano concretizzati, ad esempio all’inizio di un nuovo ciclo di sviluppo. Senza questo processo, si rischia che le discussioni affrontate cadano nel vuoto e non portino mai a un reale miglioramento.

Conclusioni

Collaborare davvero non significa eliminare le differenze, ma imparare a metterle a frutto. Quando designer e sviluppatori condividono contesto, linguaggio e obiettivi, il lavoro scorre meglio, le decisioni diventano più solide e il prodotto finale ne guadagna in qualità. Noi di Buildo abbiamo imparato che non serve stravolgere i processi: basta creare gli spazi e i momenti giusti perché le competenze di ciascuno possano incontrarsi, confrontarsi e, a volte, anche scontrarsi con garbo. È proprio in quella frizione costruttiva che spesso nasce il valore.

Vuoi continuare ad approfondire come migliorare la collaborazione tra designer e developer? Segui la nostra rubrica mensile DES ♥️ DEV curata da Agnese Ragucci su Instagram e LinkedIn: statistiche, spunti di riflessione e consigli pratici per lavorare meglio, insieme.