Quello che i Developer a volte non dicono

Quello che i developer non dicono (ma dovrebbero)

Molto spesso capita di leggere articoli su come i Designer dovrebbero rendere la vita più facile ai Developer, ma raramente articoli che spiegano il contrario… perché questa disparità?

In passato, la risposta poteva essere legata alla natura sequenziale del processo design-sviluppo, che aveva inizio con la fase di design e proseguiva poi con quella di sviluppo. Era quindi naturale per i designer preparare tutto il necessario da passare poi nelle mani dei developer. 

Ad oggi però il processo è notevolmente cambiato: i deliverables si muovono in tutte le direzioni, durante il ciclo di vita di un, progetto ed è necessario che i membri di un team lavorino in modo coeso e interattivo durante tutto il ciclo, anziché isolarsi nel proprio ruolo.  È un continuo incrociarsi di percorsi in cui ciascuno dovrebbe impegnarsi per rendere la vita dell’altro più facile. Questo include anche gli sviluppatori, front e back, che sono chiamati a dare un contributo sostanziale nelle fasi iniziali di design di un progetto.

Purtroppo, questo spesso non accade e, parlando con alcuni amici e colleghi sviluppatori, emerge che sono l’insicurezza e la sensazione di inadeguatezza a mettere un freno. Gli sviluppatori non sanno come aiutare, non si sentono creativi né tantomeno competenti in questo territorio.

In Ibuildings - non mentiamo - stiamo ancora lavorando per raggiungere risultati ottimali, ma siamo fieri della sinergia che siamo riusciti ad ottenere applicando alcune linee guida di base:

1. OFFRIRE LE COMPETENZE TECNICHE NELLE FASI INIZIALI

Il processo di ideazione sarebbe decisamente più fluido con maggiore comunicazione e condivisione di informazioni tecniche nelle fasi embrionali dei progetti.

“Sarà facile realizzare quello che sto progettando?”, “Ci sono altri potenziali modi per realizzarlo?” sono alcune delle domande che il designer si pone e per le quali sarebbe davvero utile un confronto con i developer.

2. TRASMETTERE LA PROPRIA CONOSCENZA

Il “me ne occupo io” dello sviluppatore è il nemico numero del designer che vuole colmare il proprio gap di conoscenza.

Questo non vuol dire che bisogna insegnare al designer come programmare, ma che sarebbe un grosso aiuto avere una conoscenza di base che gli/le permetta di comprendere come quello che volete costruire funziona.

Il designer infatti, acquistando familiarità con la parte più tecnica, produrrà delle soluzioni più attente e realistiche in termini di fattibilità in base al tempo allocato per il progetto.

3. FARE CRITICHE COSTRUTTIVE: LA TUA OPINIONE, È UTILE

Quando uno sviluppatore offre un feedback, è sempre molto utile, perché contribuisce, con una prospettiva differente, a mettere in luce alcuni punti critici anziché ritrovarsi a doverli affrontare quando è troppo tardi.

Non deve avere quindi 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.

4. FARE PRESENTE SE CI SONO DELLE LIMITAZIONI

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; così come per le preferenze lavorative (ognuno, d’altro canto, ha le sue): se è 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.

5. INTRODUZIONE NEL TEAM DI FIGURE "IBRIDE"

Introdurre figure ibride nel team di progetto che parlino un linguaggio trasversale tra Design e Sviluppo, abbiamo 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. Le figure ibride sono persone con una forte formazione lato UX Design, UI Design, Interaction e Frontend, da noi in ibuildings li abbiamo definiti "Interaction Designers", ma in molte altre aziende vengono definiti UX Engineer o UI Engineers e si occupano spesso della progettazione o fanno da spalla a chi progetta e sviluppa. In alcuni casi sono le persone che prendono in mano anche parrti dello sviluppo della UI.

Alla fine, tutto si riduce però ad una solo, ma importantissimo, aspetto da migliorare: la comunicazione.

Ma anche la comunicazione è effettiva solo se tutti decidono di prendere posto a questo tavolo e tutti si dimostrano aperti ad accettare aiuto e suggerimenti.

In Ibuildings, pur lavorando da remoto (sì abbiamo questa grande fortuna!), stiamo cercando di stimolare questo “ciclo continuo” ed abbiamo introdotto dei kick-off di progetto che coinvolgono fin dall’inizio sviluppatori e designers, con stand up e revisioni dei design deliverables fin dalla fase iniziale. 

Durante le fasi di sviluppo, inoltre, i designers sono coinvolti nel QA in modo da supportare gli sviluppatori nel testing delle varie features e nella definizione del loro funzionamento.

Crediamo fermamente che quando un designer aiuta uno sviluppatore, lo sviluppatore è meglio attrezzato per aiutare il designer, in un ciclo continuo che permette a tutto il team di raggiungere insieme il risultato.