Quello che designer e developer non dicono
--
Da UX Designer che ha lavorato fin dall’inizio della sua carriera in un contesto altamente tecnologico, cercare un buon modo di collaborare con i colleghi sviluppatori è sempre stata una parte cruciale del mio lavoro.
Ci vuole una perfetta integrazione tra design e sviluppo per creare prodotti digitali che le persone saranno felici e soddisfatte di usare, ma questo non è sempre considerato un fattore critico di successo da alcune organizzazioni e aziende.
Gli sviluppatori sperimentano spesso frustrazione quando i designer pensano a prodotti e funzionalità date per “impossibili”/difficili da implementare, che non supporterebbero le API o che potrebbero causare problemi cross browser e si sentono responsabili e impotenti, poiché devono stare costantemente all’erta su tutti i bug indotti dalla complessità dei progetti che devono implementare.
D’altra parte, i designer non si rassegnano al fatto che i loro prodotti non arrivino all’utente finale nella maniera esatta in cui erano stati pensati. Sembra che gli sviluppatori non notino l’impegno e la difficoltà della scelta del font, dei colori, interazioni, architettura dell’informazione e della spaziatura giusta. Perché il risultato assomiglia a malapena al file Sketch /Figma/Photoshop? Perché i designer devono indicare sempre le specifiche in modo maniacale agli sviluppatori e loro non sembrano in grado di fare le scelte giuste da soli?
Credo davvero che questo sia un nodo importante: non è così che dovrebbe funzionare.
I processi stanno iniziando ad evolversi, soprattutto in quelle organizzazioni che sono disposte a riconsiderare il loro approccio rispetto al vecchio modus operandi, che assomiglia tristemente ad una catena di montaggio: invece di passare attraverso la progettazione a compartimenti stagni e procedere per fasi, si stanno spostando verso un approccio più ibrido in cui designer e sviluppatori condividono il contesto, le tempistiche, il linguaggio e gli incentivi, lavorando insieme per raggiungere obiettivi comuni.
Come ha osservato Melvin Conway nel 1967:
Un sistema (qui definito più ampiamente rispetto a semplici sistemi di informazione) produrrà inevitabilmente un software la cui struttura è una copia della struttura di comunicazione dell’organizzazione.
Sfortunatamente, implementare processi che favoriscano una comunicazione aperta e facilitino la collaborazione tra team interfunzionali può rivelarsi piuttosto impegnativo. Per questo, ritengo che il nostro settore abbia ancora bisogno di lavorare verso la costruzione di una cultura che risolva tali problemi.
Cosa possiamo quindi aiutarci a creare tale cultura? Facciamo qualche esempio pratico:
1. Gli sviluppatori dovrebbero offrire le loro competenze tecniche nelle fasi iniziali di progetto
Se lo sviluppatore ha intenzione di utilizzare qualche framework o grid particolare al quale il designer dovrà poi aderire, è meglio che sia chiaro fin da subito. È utile stabilire un processo che faciliti poi la presa in carico lato sviluppo, meglio renderlo chiaro ed esplicito. Il designer saprà andare incontro a queste richieste e renderà il processo più fluido.
Il processo di ideazione sarebbe decisamente più fluido con maggiore comunicazione e condivisione di informazioni tecniche nelle fasi embrionali dei progetti.
“Il design riguarda la co-creazione; gli sviluppatori sono parte integrante di questo processo”
2. I designer dovrebbero sempre creare documentazione a supporto delle interazioni
Annotazioni e documentazione aiutano ad assicurarsi di non perdersi pezzi per strada, soprattutto quando si tratta di come funziona un’interazione. Si possono creare annotazioni utilizzando uno strumento come Sketch Notebook o come i commenti di Invision. Specificare l’aspetto dei diversi stati dei pulsanti, creare diagrammi, includere esempi ecc. aiuta gli sviluppatori a comprendere meglio ciò che ci si aspetta da loro.
A volte non è fattibile, ma quando possibile, creare prototipi high fidelity è ormai un must. I prototipi mostrano meglio e nel modo più semplice, come qualcosa dovrebbe funzionare, lasciando meno spazio ad interpretazioni errate. Se invece vengono utilizzati wireframe statici, è importante ricordarsi di creare sempre le annotazioni appropriate.
“If a picture is worth 1000 words, a prototype is worth 1000 meetings.”
— Tom & David Kelley, Creative Brothers at IDEO
3. Gli sviluppatori dovrebbe cercare di condividere con i designer la propria conoscenza
Il “me ne occupo io” dello sviluppatore è il nemico numero uno del designer che vuole colmare il proprio gap di conoscenza.
Questo non vuol dire che debbano insegnare ai designer come programmare, ma che sarebbe un grosso aiuto aiutare a costruire una conoscenza di base che permetta di comprendere l’ambito funzionale.
I designer infatti, acquistando familiarità con la parte più tecnica, produrranno delle soluzioni più attente e realistiche in termini di fattibilità aiutando a rispettare il tempo allocato per il progetto.
4. I designer dovrebbero sforzarsi di apprendere i metodi di lavoro e i processi dei propri colleghi sviluppatori
É importante prendersi il tempo e l’iniziativa per apprendere le metodologie e i processi che coinvolgono gli sviluppatori. Partecipare alla pianificazione dello sprint. Scrivere i task su JIRA in modo che tutti sappiamo quali funzionalità vengono create quando.
5. Allo stesso modo I designer devono essere organizzati
A volte i designer costringono gli sviluppatori a “scavare” tra le cartelle per trovare le ultime versioni dei file o inviano pezzi sparsi via mail e slack. Semplifichiamo la vita delle persone! Quando vengono inviati file puliti e ben organizzati, diventa molto più facile e veloce sviluppare. Denominare e ordinare componenti e layer in modo semplice e coerente è un salva vita. Importantissimo inoltre centralizzare dove questi file vengono collocati, sopratutto quando il team di design è composto da più persone.
6. Gli sviluppatori dovrebbero inoltre sforzarsi di fare critiche costruttive (e i designer essere aperti a riceverle)
Quando gli sviluppatori offrono un feedback, è sempre molto utile, perché contribuiscono, con una prospettiva differente, a mettere in luce alcuni punti critici in modo da non ritrovarsi ad affrontarli quando è troppo tardi.
Non devono avere paura di dire le cose come stanno: se una determinata scelta stilistica andrà a richiedere maggior tempo di lavorazione (e consumo di budget) è meglio saperlo subito perché, confrontandosi si riesce facilmente a trovare soluzioni ugualmente idonee a livello di user experience, ma che rendono la vita più facile a tutti.
Dall’altra parte i designer devono imparare ad accettare le critiche e a trovare soluzioni condivise: erigere muri con la scusa di essere gli “user advocate” non aiuta a creare né utenti felici, né un ambiente lavorativo costruttivo.
7. Gli sviluppatori dovrebbero sforzarsi di essere più empatici
Anche se per gli sviluppatori sembra poco importante che il nome di un campo sia distante 5px da esso, definire una distanza differente potrebbe avere un impatto sulla user experience.
Un utente potrebbe infatti confondere due campi perché la label è più vicina al campo sbagliato. Non bisogna dare per scontato che qualcosa sia “solo estetico” o “di poca importanza”.
Il buon design è intenzionale.
8. Per aiutare gli sviluppatori ad essere più empatici, i designer dovrebbero provare a coinvolgerli nelle fasi di ricerca e/o in qualche call con il cliente/referente di progetto
Tutti i membri di un team di prodotto dovrebbero essere coinvolti nelle fasi di ricerca. Ciò può avvenire sotto forma di ascolto durante una chiamata, registrazione o lettura del transcript. Coinvolgere gli sviluppatori, almeno in parte del processo di ricerca, aiuta a creare empatia con i nostri utenti. Anche come sviluppatore, è importante entrare in empatia con le persone per le quali si sta costruendo un prodotto. Aiuta a fornire una comprensione approfondita di ciò che deve essere fatto prima e perché, creando un senso più forte di ownership e co-creazione.
Mi è capitato in passato di eseguire Guerrilla Testing con alcuni colleghi sviluppatori: dopo questa esperienza è stato naturale per loro preoccuparsi maggiormente del punto di vista dell’utilizzatore finale e sentirsi maggiormente coinvolti nella realizzazione del prodotto. Lo stesso accade quando gli sviluppatori hanno contatto diretto con il referente di progetto/cliente, questo li aiuta a comprendere meglio le esigenze e motivazioni.
9. Infine può essere molto utile l’introduzione nel team di figure ibride
Le figure ibride sono persone con una forte formazione lato UX Design, UI Design, Interaction e Frontend, in molte aziende vengono definiti UX Engineer o UI Engineer e si occupano spesso della progettazione o fanno da spalla a chi progetta e sviluppa.
Introdurre figure ibride nel team di progetto, che parlino un linguaggio trasversale tra Design e Sviluppo, ho notato essere un elemento che fornisce una marcia in più. Aiuta a far sentire sia i colleghi designers che sviluppatori più a proprio agio nei momenti di scambio e progettazione.
In conclusione per creare una buona sinergia tra designers e sviluppatori, gli elementi chiave sono: l’empatia, la comunicazione e la definizione di processi condivisi. Poiché il design riguarda la co-creazione, gli sviluppatori svolgono un ruolo importante.
Tutti fanno parte della stessa squadra e hanno come obiettivo quello di creare un ottimo prodotto.
I contributi di tutti i membri del team hanno lo stesso valore e amo vedere entrambe le parti lavorare insieme il meglio possibile per creare qualcosa di cui alla fine saranno orgogliosi.
Se siete curiosi di approfondire queste tematiche, vi consiglio di partecipare a Intersection Conference, conferenza internazionale che sto organizzando a Milano, insieme al team di Ibuildings Italia, l’ 1 e il 2 Ottobre.
Intersection Conference ospiterà workshop di rilievo nel primo giorno e conferenze nel secondo (qui il programma dell’evento): speriamo che promuovendo la comunicazione aperta e i processi di lavoro integrativi tra i team di sviluppo e progettazione, apriremo la scena a interessanti conversazioni incentrate su UI, UX e sviluppo migliorando i processi di lavoro del nostro settore, consentendo ai partecipanti di costruire prodotti digitali eccellenti e di livello mondiale. Sono sicura che tutto questo porterà a prodotti migliori e a utenti e persone più felici.
Sharing is caring:
L’articolo era interessante? Lasciaci qualche applauso 👏👏👏👏 e condividilo con qualcuno!
UX Tales è una pubblicazione aperta: ✍️ proponi qui il tuo articolo, oppure scrivici su Twitter o su Facebook
