Sappiamo che gli sviluppatori possono entrare in conflitto con i graphic designer, soprattutto quando il designer progetta qualcosa che è difficile costruire. Ma esistono molti motivi per cui i designer dovrebbero prendersela con gli sviluppatori.
Il graphic designer segue regole ben precise
Il design è spesso visto come una ‘soft skill’ che si trova a circa a metà fra un parere estetico, senza né regole rigide, né tanto meno la logica rigorosa di un codice. Eppure, i graphic designer lavorano per anni nel perfezionare un mestiere, non solo costruendo idee indefinite. Tuttavia, non è sempre facile spiegare e articolare il ‘metodo dietro la follia di progettazione’, in maniera rapida, il che porta a numerose criticità durante lo sviluppo del progetto. Fortunatamente, di solito c’è un modo per stemperare la tensione.
Come fare pace fra graphic designer e sviluppatori
Vediamo quindi come far pace fra graphic designer e sviluppatori, attraverso tipiche criticità:
01. “Ho disegnato il progetto in questo modo per una ragione precisa!”
Il problema: Il graphic designer spende -anche- settimane creando composizioni visive meticolose e documenti specifici, solo per poi essere apparentemente ignorati dallo sviluppatore. Oltre a ignorare le specifiche, alcuni sviluppatori semplicemente utilizzano le impostazioni predefinite del browser per non eseguire modifiche, se esse non sono esplicitamente previste nella documentazione, non solo mostrate nelle composizioni visive.
Il graphic designer presuppone che lo sviluppatore studierà da vicino le composizioni e cercherà di adattarle in modo ‘digitalmente’ perfetto, a prova di pixel insomma. Tuttavia, questa abitudine porta invece ad avere interfacce orribili o scarsamente organizzate, nonostante gli sforzi dei designer.
La soluzione: I graphic designer non dovrebbero presumere nulla, e sapere che la documentazione non è mai abbastanza. Una guida al buon design è il primo passo verso la soluzione a questo problema, ma i designer devono anche lavorare fianco a fianco con gli sviluppatori, riesaminando regolarmente il loro lavoro, per assicurarsi che una revisione faccia sentire lo sviluppatore a suo agio con ciò che hanno fatto.
Conosci questi famosi graphic designers?
02. Il segreto è nel Minimum Viable Product (MVP)
Il problema: Lo sviluppatore ha una quantità finita di tempo per creare il prodotto finale, ancora meno ad ogni deadline, quindi bisognerà dare la priorità alle caratteristiche e funzionalità, in base al ‘minimum viable product’ in grado di soddisfare le specifiche del prodotto. La maggior parte dei designer, però, vedono il prodotto come un insieme integrato, non una serie di componenti ad incastro. Ma spesso l’MVP è non è definito fino alla fase di sviluppo, facendo sembrare la cosa come se gli sviluppatori stessero prendendo le decisioni in base alle loro esigenze di pianificazione, piuttosto che alle esigenze degli utenti e del prodotto.
La soluzione: il MVP deve essere definito durante le fasi iniziali del prodotto, e deve essere il minimum viable product per davvero, non il più facile da ottenere, nelle diverse fasi di sviluppo / deadline. I designer possono lavorare per creare un prodotto che è viene integrato in fasi diverse, rispetto a tutto in una volta. Di conseguenza, questo dovrebbe anche rendere più facile la pianificazione per gli sviluppatori.
03. “Quanto tempo richiederà?!?!?”
Il problema: Il designer ha trascorso mesi di pianificazione, di ricerca, e la creazione di composizioni per soddisfare le esigenze degli utenti, e poi invece qualcuno dice che ci vorrà molto più tempo del previsto a causa di orari che sono in conflitto con il progetto, carenza di personale, e quindi va tutto a rotoli.
La soluzione: Uno dei risvolti positivi di qualsiasi progetto di sviluppo di interfaccia utente (UI) è che lo sviluppo viene gergalmente fatto per ultimo, ed è generalmente spremuto dagli step compiuti prima.
Un modo per aggirare questo problema è usare Agile accoppiato con Lean UX per consentire lo sviluppo in parallelo con il design, e che permette agli sviluppatori di iniziare prima che il design sia completamente completato. Questo approccio non è esente da rischi (il design può essere modificato necessariamente), ma si traduce generalmente in consegne più veloci e project manager più felici. E alla fine non è che quello che vogliamo tutti?
04. Che cosa vuoi dire “Non posso farlo!”?
Il problema: Il designer ha creato una esperienza davvero interessante, ma lo sviluppatore dà uno sguardo e sentenzia: “Non funzionerà mai”. Per gli sviluppatori, uno dei motivi per cui una cosa non possono farla è perché non si può fare, ma il più delle volte si tratta di uno di questi due motivi: 1) ci vuole troppo tempo, oppure 2) lo sviluppatore semplicemente non sa come fare.
Nel team sarà fondamentale ascoltare anche l’opinione un web designer
La soluzione: Se non può essere fatto, non può essere fatto, e il designer deve pensare alla soluzione. Se ci vorrà troppo tempo, il team ha bisogno di decidere se ridimensionare il progetto o prendersi il tempo necessario. Ma, se lo sviluppatore non sa come farlo funzionare, il graphic designer dovrà mostrare loro esempi che funzionino.
05. Il test di usabilità non è un optional
Il problema: Per molti sviluppatori ‘usabilità’ significa che “funziona come da requisiti”. Se i designer vogliono testare qualcosa, si dovrebbe fare prima che lo sviluppatore inizi a trascorrere lunghe ore a costruire la UI con le specifiche. Tuttavia, il test di usabilità può essere eseguito solo su carta e prototipi cliccabili. Spesso, i test di usabilità più efficaci vengono effetuati durante lo sviluppo.
La soluzione: il piano dei testing di usabilità spiccano in ogni progetto in Agile con interazioni che permettono di dare feedback immediati nello sviluppo del progetto.
06. “Mi stanno dicendo come fare il mio lavoro, di nuovo!”
Il problema: Uno sviluppatore legge un articolo sull’usabilità, e improvvisamente si sente un esperto di usabilità e di progettazione. I designer passano anni a sviluppare la loro abilità, le conoscenze e attitudini. Un problema è che, siccome ognuno ha una propria opinione di design (costruita o meno) in alcuni progetti – specialmente dove ci può essere una squadra che lavora su UX – la voce dei graphic designer viene spesso soffocata.
La soluzione: Questo non è un problema facile da risolvere, perché ha più a che fare con le dinamiche interpersonali e di gruppo. Il modo migliore per affrontare queste situazioni è quello di ascoltare semplicemente, senza mettersi sulla difensiva. Lascia che dicano la loro e considera quello che dicono.
Quello che hanno da dire ha un risvolto positivo? Faglielo sapere, e poi spiega perché si è scelto di fare quello che hai fatto, riconoscendo anche che sei in disaccordo con quelle ‘cattive abitudini’ di cui abbiamo parlato sopra. Spesso gli sviluppatori vogliono solo che il designer li ascolti.
