Designer e developer: tre principi per aiutarli a fare grandi cose assieme

“Sai cosa mi manca di Moze?”.
“Cosa?”.
“L’intesa tra designer e developer. Quella nelle altre aziende in cui ho lavorato non l’ho più trovata”.

Questo scambio di battute è tratto da una conversazione con un amico e collega che, anni fa, scelse di lasciare il nostro team per trasferirsi all’estero.

Il processo di collaborazione tra designer e developer è qualcosa a cui abbiamo lavorato molto. Lavorando su prodotti digitali custom, dove esperienza utente e layout sono progettati ogni volta in base a necessità specifiche (e non a partire da “template” esistenti), avevamo necessariamente bisogno che quanto implementato fosse uguale (anzi, meglio) dei layout originali.

Tutto questo mi ha portato a riflettere sull’importanza di quelle buone pratiche che in qualche occasione diamo per scontate:

• Quali sono quelle condizioni che permettono a designer e developer di lavorare bene assieme?
• Come capire se ci si trova sulla strada giusta?
• Quali sono i segnali di allarme?

In questo articolo descriviamo tre semplici principi che abbiamo adottato in Moze. È scontato dire che non abbiamo la pretesa di essere perfetti: qualche volta designer e developer devono fare “ancora un’altra call” per intendersi meglio. Ciò nonostante la collaborazione funziona.

Per descrivere i principi che guidano la relazione tra designer e developer in Moze, ho cercato di andare oltre alla mia versione dei fatti: ho chiesto aiuto ad alcuni designer e developer del nostro team per descrivere un quadro il più possibile accurato.

In particolare mi hanno aiutato Matteo, mio socio e Design Director e i developer Claudio, Andrea e Gabriele.

Vediamo insieme questi principi.

1. Lavorare insieme. Dal kick-off al rilascio.

Il primo aspetto fondamentale riguarda la frequenza e le modalità con cui designer e developer hanno possibilità di lavorare assieme.

Claudio dice: “Dalle mie esperienze trascorse ho osservato due estremi: nella piccola realtà designer e developer coincidono con la stessa persona, o magari sono vicini di scrivania. Nelle grandi aziende i team di design e di sviluppo sono invece, troppo spesso, mondi distanti tra loro. Si comunica poco o per nulla, magari perché il programma di lavoro li vede impiegati in periodi temporali differenti.

In Moze, pur trattandosi di un piccolo team con meno di quindici persone, la situazione è radicalmente differente: i progetti sono organizzati in modo da mantenere sempre un certo livello di collaborazione e dialogo a due sensi tra design e sviluppo.

Il team di design si confronta con quello di sviluppo per valutare, a priori, la fattibilità tecnica e l’impatto operativo delle soluzioni che si stanno elaborando. Durante il progetto, se qualcosa è sfuggito alle valutazioni iniziali, si continua a collaborare efficacemente per trovare una soluzione che sia soddisfacente per tutti. Il team di design svolge poi sempre delle sessioni di controllo qualità, riportando eventuali feedback al team di sviluppo.”

Gabriele dice: “In Moze non passa mai troppo tempo prima di ricevere feedback sul proprio lavoro. Qui il processo di creazione dei prodotti digitali è davvero iterativo: i feedback si susseguono nelle diverse fasi di progettazione e di sviluppo. E questo è un bene, perché senza confronto un developer può perdere ore alla ricerca della soluzione tecnicamente perfetta, per poi accorgersi che il problema poteva essere aggirato in maniera assai più semplice. È sempre molto meglio ricevere tanti feedback frequenti, anziché un’unica grande review di fine lavoro.”

Riguardo alle modalità di collaborazione, le giuste domande da porsi sono le seguenti:

• Designer e developer hanno frequenti occasioni di confronto?
• Hanno la percezione che il feedback costruttivo è ben accetto e che questo ha reale impatto sulle sorti del progetto?
• I developer vengono coinvolti nelle valutazioni preliminari prima di avviare un nuovo progetto?
• I designer fanno costante review di quanto fatto dai developer?

2. Designer un po’ developer. Developer un po’ designer.

La conseguenza di una collaborazione frequente riguarda la trasformazione della cultura professionale del team di lavoro: la contaminazione di competenze e di idee è benvenuta, poiché può accelerare il processo creativo e di implementazione.

Un buon designer progetta l’interfaccia di un software conoscendo le implicazioni del suo lavoro sull’attività di sviluppo. Un buon developer trasforma un layout in codice conoscendo le basi della User Experience. Questo permette ad un team multidisciplinare di concepire lo sviluppo come un tutt’uno, passando da un’idea di business al rilascio di un prodotto digitale funzionante anche in poche settimane.

Gabriele dice: “Sviluppatori e progettisti hanno più cose in comune di quanto si possa pensare. È proprio la conoscenza del lavoro reciproco l’aspetto che facilita la definizione di un approccio comune, indipendentemente dal fatto che in un dato momento si stia utilizzando Figma o un code editor. In Moze abbiamo moltissimi momenti di confronto, con persone appartenenti a gruppi di lavoro eterogenei. Sono quelle le occasioni giuste per conoscere ciò che accade fuori dal nostro confine concettuale. In questo modo scopriamo che designer e developer non sono poi così distanti.”

Andrea dice: “Feedback frequenti durante lo sviluppo di un progetto arricchiscono sia i designer che i developer. Uno sviluppatore imparerà a vedere un sito web attraverso gli occhi delle persone che lo utilizzeranno, impegnandosi non solo a scrivere codice di qualità, ma anche ad assicurare la migliore esperienza utente possibile. Il designer, d’altro canto, acquisirà familiarità con le difficoltà incontrate dagli sviluppatori nell’implementazione, imparando in futuro a semplificare e ad anticipare problemi.”

Riguardo l’opportunità di una contaminazione culturale, è utile chiedersi:

• Il team di design ha occasione di imparare dalle osservazioni poste dai developer?
• Il team di sviluppo ha modo di dialogare con i designer, di riflettere e di apprendere buone e cattive pratiche in termini di User Experience?
• In definitiva, ci sono le condizioni per facilitare lo sviluppo di interesse nella sfera di competenze altrui?

3. Stabilità del team.

Un aspetto da non trascurare riguarda poi le relazioni tra persone che si conoscono bene e hanno imparato a lavorare assieme nel corso degli anni.

Gabriele dice: “Un aspetto fondamentale riguarda la continuità nei rapporti di collaborazione. Realizzare un prodotto digitale è un lavoro di squadra: più questa è affiatata, più è abituata a lavorare insieme e migliore sarà il risultato finale. In Moze si respira un ottimo spirito di squadra, le persone lavorano insieme e si conoscono da anni, ci sono dinamiche e processi ormai consolidati molto utili anche per i nuovi arrivati”.

Matteo dice: “Conoscere a fondo le persone con cui lavori è la cosa più importante. So che quel developer è bravissimo con la logica JavaScript e tutto funzionerà alla grande, ma che dovrò dargli maggior feedback sulla stilizzazione CSS dei componenti. Poi c’è quel developer a cui so di poter chiedere rapidamente un parere tecnico per disegnare una soluzione fattibile in tempi brevi. È davvero essenziale.”

Riguardo la questione della stabilità, è buona cosa chiedersi:

• I membri del team più affiatati hanno occasione di collaborare continuativamente su diversi progetti?
• Sto creando occasioni per creare affiatamento tra persone che non hanno ancora avuto modo di lavorare assieme?

Bonus: design tool fatti bene.

Infine, la scelta degli strumenti è di grande importanza.

Andrea dice: “L’utilizzo di software in Cloud come Figma ha migliorato notevolmente la collaborazione tra designer e developer, rendendola quando necessario addirittura in real time: posso commentare gli elementi del layout su cui ho necessità di chiarimenti o discutere assieme il funzionamento di un componente condividendo lo schermo. Insomma, è davvero comodo.”

Gabriele dice: “Questo è un aspetto fondamentale per me in quanto sviluppatore front-end. In passato mi è capitato di realizzare interfacce utente a partire da bozze su carta, o di ricevere indicazioni direttamente utilizzando l’inspector del browser. In Moze ogni idea viene fortunatamente rappresentata graficamente da subito grazie all’utilizzo di software di progettazione moderni, utilizzabili anche da noi sviluppatori per interpretare pensieri e approcci elaborati dai designer”.

Un buon approccio

Ogni azienda ha la sua cultura lavorativa e differenti processi. Parlando di designer e developer, troppo spesso si cade nella tentazione di sottovalutare le implicazioni che riguardano le modalità di collaborazione. È facile pensare che sia sufficiente “inviare i layout” ai developer, e che questi completeranno fedelmente l’implementazione in totale autonomia.

Nella nostra esperienza ciò che funziona ruota attorno a queste raccomandazioni:

• Coinvolgere i developer per un’analisi preliminare prima ancora di avviare le attività di UX & UI Design.
• Creare frequenti spazi di conversazione tra designer e developer per feedback bi-direzionali: i developer danno feedback riguardo il progresso sui layout, designer effettuano controllo qualità su quanto realizzato dai developer.
• Facilitare lo sviluppo di interessi interdisciplinari, mirando a creare un ambiente “contaminato” in cui, pur conservando ciascuno la propria professionalità, i confini di interesse e dialogo sono sfumati.
• Facilitare la stabilità nei team di lavoro, consentendo allo stesso tempo il giusto “rodaggio” a chi non ha ancora avuto occasione di lavorare assieme.
• Usare strumenti che facilitano il lavoro. Senza esagerare in quantità, puntando alla sostanza di ciò che è utile rendendo più semplice il lavoro di designer e developer.

Leggi anche

• Il designer di prodotti digitali Come riconoscere un buon designer? Quali metodologie e processi adottare? Come collaborare in modo efficace con gli sviluppatori? Raccontiamo la nostra esperienza dialogando con Matteo Montolli, partner e Design Director di Moze.
• Designers and Developers Sei anni fa abbiamo cominciato a parlare di design con i nostri developer. Ecco cos’è successo e perché dovresti farlo anche nel tuo team.