Anche i designer e i developers possono parlare la stessa lingua
La sincronizzazione è alla base di un team che funziona. E un team che funziona produce prodotti migliori.
Un prodotto digitale è il risultato di una vasta quantità di processi. Il loro intreccio genera ciò che poi verrà consegnato e utilizzato.
Il positivo intrecciarsi di tali processi è direttamente correlato al successo del prodotto — se c’è armonia e la comunicazione funziona, anche la creazione e produzione riescono a raggiungere gli obiettivi con qualità e puntualità.
Uno dei passaggi che ho visto che più spaventa in un prodotto digitale è il developer handoff.
Dai diversi designer è spesso vissuto come una minaccia incombente per i loro progetti — il dev modificherà tutto o non implementerà niente delle figate che sono state create.
D’altra parte, il dev si aspetterà l’ennesimo unicorno da parte dei designer, svarionata grafica con altissimi costi di implementazione.
Un layout completamente stravolto o un carnevale di Rio al posto di un’interfaccia, però, sono enormi fari lampeggianti che dicono che qualcosa non sta funzionando.
Che cosa?
La comunicazione.
E cattiva comunicazione genera processi di cooperazione e collaborazione che sprecano risorse e tempistiche. Quindi, un prodotto mediocre.
La sincronizzazione
Un team funziona per bene se tutti i membri sono sincronizzati.
È un po’ come con i device — se l’iPhone è in sync con l’iPad continuare il lavoro iniziato su un uno usando l’altro non è problematico e la produttività aumenta.
Con gli esseri umani, specialmente in un team che prevede la coesistenza di figure, ciò richiede dei presupposti:
- Linguaggio comune
- Luogo comune
- Feedback continuo
Linguaggio comune
Designer e developers parlano linguaggi diversi, sia all’interno dei due team che tra di loro.
È ciò che spesso porta a un processo erroneo che vede il developer handoff come un momento di contatto unico tra i due mondi: i designer progettano, creano le spec, rendono gli elementi implementabili, poi passano il materiale ai dev e loro si preoccupano di scrivere il codice — se hanno bisogno, chiedono chiarimenti sul progetto.
Un processo simile è un circuito dove l’attrito è tale che lo spreco di risorse e tempo è lì in agguato — il momento feedback è ritardato e alla fine della progettazione e la frustrazione sale facilmente.
Come fanno allora i due mondi a comunicare?
Con le sync sessions.
Tali sessioni sono intense, spesso richiedono l’uscita dalle proprie aree di comfort ma sono molto utili perchè è in tali momenti che:
- i developers comunicano che tecniche di implementazione useranno, quali framework, i linguaggi di programmazione, come funzionano le macchine sulle quali monteranno il prodotto;
- verrà discussa l’architettura del software stesso;
- i designer esporranno le loro strategie di testing e di progettazione, con i tools di produzione;
- i due mondi potranno chiedere chiarimenti.
Personalmente, nei progetti a cui ho partecipato ho sempre cercato di avere delle sync sessions molto intense — molti erano i punti oscuri del mondo dev che avevo bisogno di chiarire e che hanno facilitato il momento di implementazione e di progettazione, arricchendo il mio know-how di conoscenze in settori anche molto lontani dal design.
Luogo comune
Dopo l’importante passo di framing sui termini, sui tools e sulle metodologie, la sincronizzazioen richiede unità.
E tale unità deriva da avere l’intero prodotto raccolto in un unico luogo — codice, assets e file sorgente delle interfacce.
Come mai?
Perchè i dev possono visionare cosa stanno costruendo i designers e questi ultimi possono capire come il lavoro viene implementato e provare ad applicare tali cambiamenti direttamente sul codice.
Il luogo ideale è GitHub.
Citando Wikipedia, «Il sito è principalmente utilizzato dagli sviluppatori, che caricano il codice sorgente dei loro programmi e lo rendono scaricabile dagli utenti. Questi ultimi possono interagire con lo sviluppatore tramite un sistema di issue tracking, pull request e commenti che permette di migliorare il codice della repository risolvendo bug o aggiungendo funzionalità. Inoltre Github elabora dettagliate pagine che riassumono come gli sviluppatori lavorano sulle varie versioni dei repository».
Non solo gli sviluppatori possono farne uso ma, per esperienza personale, anche gli stessi designer — creare le fork permette di avere tutti i file sui propri computer e il merging permette di integrare le modifiche accettate dal team.
(In una prossima storia vi parlo come uso GitHub da designer)
Feedback continui
Le sync session e il common place sono essenziali perchè permettono di facilitare il processo di feedback.
Nel processo di creazione, dev e designers non dovrebbero essere universi separati che si accavallano in semplici processi [first A then B], ma dovrebbero collaborare assieme e contaminarsi in ogni fase, anche quella più fuori dai loro mondi.
Ho trovato gran beneficio nel parlare ai dev, soprattutto back.ender, mentre costruivano l’architettura e il back-end del prodotto.
Oppure a fare delle free-hand sessions sviluppando wireframe tutti assieme e gettando le basi per futuri design-systems con i giusti appunti sui framwork utilizzati.
Gli sviluppatori possono dare importanti contributi in fase di progettazione tanto quanto un designer e viceversa.
Per ottenere ciò, io cerco di limitare l’uso dei tools in nome del principio di unità:
- GitHub è eccezionale grazie al meccanismo di issue tracking e di pull request, che permette di elaborare feedback di varia natura e in caso prendersi l’incarico di apportare la modifica voluta;
- InVision è il nirvana dei designer ma ho visto sviluppatori con gli occhi illuminati — si possono commentare in diretta tutti gli elementi dell’interfaccia e, con la funzione Freehand, collaborare in diretta sullo sviluppo di copy e wireframes.
Il metodo che uso è una delle tante vie che puntando a quello che tutti dovrebbero puntare: comunicazione e sincronizzazione.
Perchè un team sincronizzato e che sa comunicare è un team produttivo, che riesce a investire una maggior parte delle proprie risorse in processi virtuosi.
