Si dice che designer e sviluppatori si odino: secondo la leggenda i designer progetterebbero appositamente app con corner smoothing al 100% e gli sviluppatori sposterebbero le card di 10 pixel per ripicca.

Parliamoci chiaro, nonostante questa guerra sia solo parte di uno stereotipo c’è da dire che noi designer abbiamo la nostra dose di colpe.

Realizziamo mappe dell’empatia, flussi e user journey dei nostri utenti ma ne dimentichiamo sempre uno: lo sviluppatore.

Spesso ci sembra che il nostro lavoro sia finito una volta consegnate le versioni finali delle schermate di un progetto. Magari abbiamo lavorato mesi con impegno e il cliente è felice del prodotto realizzato, possiamo finalmente goderci un po’ di meritato riposo, no?

In realtà il lavoro davvero importante è giusto dietro l’angolo, ma tendiamo a trascurarlo.

Quando si parla di processi di design si dà giustamente spazio alla fase di ricerca, di wireframe e di mockup, ma si parla molto poco –troppo poco–dell’organizzazione dei contenuti prodotti. Progettare per il piacere di farlo? Bellissimo, ma inutile.

Il vero piacere della progettazione sta nell’arrivare ad un prodotto che funzioni e soprattutto che funzioni bene. Perché ciò accada, il processo di realizzazione è determinante.

Designer che sente parlare per la prima volta di "collaborazione con sviluppatori"

No, non devi imparare a sviluppare

Un enorme muro che si trova nel parlare di far collaborare il mondo del design con quello del codice è il credere che un designer non sia in grado di capire uno sviluppatore, a meno che anche lui non sappia fare codice. In realtà, il collaborare con lo sviluppo e rendere fluido il passaggio di informazioni non richiede di imparare nuovi linguaggi o tecnicismi particolari, solo quelli che sono già parte del pacchetto da designer.

Quando inizi un nuovo progetto ti viene chiesto di empatizzare e di capire l’utente, non ti viene chiesto di diventare l’utente.

Design is really an act of communication, which means having a deep understanding of the person with whom the designer is communicating.

Citando Donald A. Norman e Design of Everyday Things ho un po’ calato l’asso di bastoni del design, ma spero me lo perdonerai.

Il mondo dello sviluppo non dovrebbe diventare il tuo campo, ma il campo con cui comunichi ad ogni progetto e che quindi conosci meglio. Studiane i punti forti, i punti deboli e trova il modo migliore per comunicarci. Anche chi sviluppa è un tuo utente, non dimenticarlo!

Ripensare il proprio flusso di design richiede sicuramente più lavoro, ma può velocizzare esponenzialmente quello di tutto il team.

Fortunatamente il tempo dei designer rockstar è finito, il vero obiettivo è portare il team alla vittoria. Bastano poche accortezze per farlo.

1. La telepatia non esiste

O, per lo meno, non rientra ancora nel pacchetto di conoscenze di uno sviluppatore, nemmeno in quello di un full stack.

Rappresentazione di sviluppatori che cercano di immaginare i sottintesi del progetto

In quanto designer avrai sicuramente parlato con gli stakeholder del progetto, o almeno conosci molto bene i loro interessi e soprattutto i loro utenti. Non puoi aspettarti però che gli sviluppatori sappiano leggere nel pensiero, assicurati di trasmettere in modo più chiaro possibile le informazioni che hai raccolto durante la progettazione.

Se sei una persona fortunata, lavori fianco a fianco con chi sviluppa e potrai comunicare facilmente. Se non lo sei e il team di sviluppo è esterno, dovrai essere in grado di comunicare ancora meglio.

Assicurati quindi di far rientrare nella consegna del progetto su cui hai lavorato tutti i documenti che potrebbero essere utili e che potrebbero aiutare chi poi ci metterà le mani a capire come funziona. Ogni progetto ha le proprie necessità, ma in generale ci sono alcune accortezze che possono aiutare:

User personas

Non aiutano solo i designer ad empatizzare, ma anche gli sviluppatori! Ci sono tanti modi per scrivere delle user personas, studia come scriverne di utili a chi sviluppa: alcune informazioni potrebbero non servire loro in alcun modo, altre potrebbero essere cruciali per la comprensione del prodotto. 

Prendi come esempio un progetto in cui sono presenti molti utenti con autorizzazioni diverse: può essere utile avere un nome e una foto da utilizzare anche nei mockup, in modo da collegare le funzionalità alla tipologia di utente.

Note per i mockup

Per quanto le schermate possano parlare da sole, è meglio essere specifici in tutti i punti non comunicabili dalla UI. Lasciare sottintese alcune informazioni non va mai bene: da dove arriva quel dato? Viene scritto da admin o è il risultato di un’altra azione fatta nel progetto? Scrivere delle note tra le schermate è estremamente utile per non lasciare nulla al caso.

Documenti dei flussi 

Avere un documento in cui viene riepilogato tutto il progetto è importante tanto quanto avere tutte le schermate completate. È utile per scrivere nero su bianco tutte le decisioni prese nel processo di design, per essere letto prima di cominciare a sviluppare e per controllarlo durante lo sviluppo.

2. Semplifica il lavoro altrui

Per quanto un progetto di design possa essere lungo, lo sviluppo richiede altrettanto tempo, spesso (se non sempre) anche di più. Una buona pratica è quella di preparare in una cartella tutto il materiale utile, da condividere agli sviluppatori: icone, font, SVG e immagini varie presenti nel progetto. Sono tutte cose che uno sviluppatore probabilmente è in grado di fare, ma impiegandoci più tempo e con il rischio che chieda comunque aiuto a noi designer. Perché non giocare d’anticipo?

Creare poi una mappa delle schermate del progetto verrà sicuramente apprezzato: lo scopo della mappa è molto simile a quello di un prototipo ad alta fedeltà, risulta però molto più esaustivo e di semplice lettura per chi dovrà sviluppare quelle schermate. Il prototipo è sicuramente utile ad un cliente per capire se se il prodotto è ciò che desiderava, per uno sviluppatore potrebbe però risultare poco comodo nella consultazione. Dei collegamenti tra schermate sono ciò che basta per comunicare al meglio i flussi.

Se oltre a fare tutto questo scrivi anche i copy delle notifiche e dei permessi del progetto, diventerai il designer preferito del team.

3. Lavoro di squadra

Molto spesso design e sviluppo vengono visti come due mondi separati, quando in realtà dovrebbero essere come asola e bottone. La collaborazione è ciò che fa funzionare davvero un progetto! Dopo la progettazione, un prodotto non dovrebbe avere alcun segreto per un designer.

Questa conoscenza può essere usata per scrivere i task insieme a chi svilupperà il progetto, in modo da capire a chi è rivolta ogni feature, i bisogni che vanno soddisfatti e quali sono le richieste. È un ulteriore step per trasmettere in modo chiaro cosa comporti il progetto.

4. Non affezionarti al tuo design

Il processo di design è la base da cui parte un progetto, spesso però tra progettazione e realizzazione possono passare mesi e le cose cambiano. Nonostante possa sembrare una frase da guru spirituale, devi imparare ad abbracciare il cambiamento. 

Designer in adorazione del proprio progetto

Durante lo sviluppo possono nascere problemi che non avevi considerato o che non esistevano precedentemente, cambi di direzione sul focus del progetto o sulle tecnologie utilizzate che potrebbero cambiare alcuni aspetti del design. Se sei parte di un team, fai in modo di esserci anche in quei momenti e non farti influenzare dal lavoro che avevi fatto precedentemente.

5. Chiedi feedback

Ripetiamolo: anche chi svilupperà il progetto è un tuo utente, trattalo come tale! A fine progetto è importante sapere cosa ha funzionato e cosa no, di cosa si è sentita la mancanza e cosa invece avrebbe potuto non essere necessario. 

Ogni team è diverso e ha le proprie esigenze, considera anche di chiedere del tempo per una retrospettiva o per delle interviste, raccogli i dati e progetta come far funzionare al meglio il prossimo flusso di lavoro.

Lo stereotipo della guerra tra design e sviluppo sarà duro a morire, ma può essere abbattuto un progetto alla volta.

Ovviamente, quelli scritti in precedenza sono consigli da prendere in considerazione ma non da seguire ciecamente: in alcuni casi le user personas, le cartelle di documentazione o lo scrivere insieme i task potrebbero non servire, sono tutte azioni che andrebbero valutate insieme al proprio team.

L’unica cosa davvero necessaria è il tenere sempre a mente che la progettazione è un lavoro importante solo se poi renderà più semplice la vita a chi ne farà utilizzo, anche gli sviluppatori.

Se l’articolo ti è piaciuto iscriviti alla nostra 📧 newsletter! Posteremo tanti altri contenuti come questo, anche in anteprima!