6 frustrazioni che gli sviluppatori hanno con i designer

A meno che tu non stia progettando solo per il piacere di farlo – o tu sia uno dei leggendari “unicorni” che possono fare TUTTO – ad un certo punto incontrerai (e probabilmente incastrerai) qualcuno incaricato di scattare le tue graziose foto e trasformandoli in un prodotto del mondo reale. Come cani e gatti, queste relazioni sono storicamente note per essere… tese.

Ovviamente non tutte le relazioni designer / sviluppatore sono controverse o basate sulla reciproca sfiducia. In effetti, sempre più designer e sviluppatori stanno lavorando a stretto contatto in ambienti agili, dove i muri devono cadere per necessità.

Tuttavia, alcune delle cattive volontà persistono. Per aiutare ad alleviare questo stress, presento le frustrazioni più comuni che trovo che gli sviluppatori abbiano con i designer e come puoi lavorare per evitarle.

01. Ci sono cinquanta sfumature di grigio!

Il problema : il risultato finale è un file Photoshop / Illustrator / Sketch con 53.002 livelli che lo sviluppatore deve attraversare e ogni grigio ha un valore leggermente diverso.

La soluzione : in poche parole, hai bisogno di una guida di stile. Piuttosto che fare affidamento su tutti i valori in una composizione visiva per essere “pixel perfetti”, registra i valori standard importanti (colori, margini, spaziatura interna, bordi, ecc …) in un riferimento comune. Ciò riduce notevolmente le supposizioni e l’interpretazione che lo sviluppatore deve eseguire e può ridurre drasticamente il tempo di sviluppo. Ottieni punti bonus se lo fai utilizzando CSS e punti ultra-bonus utilizzando SASS o LESS per acquisire valori variabili come il colore.

02. Hai anche guardato il contenuto di questa cosa?

Il problema : il design viene fornito utilizzando il testo segnaposto Lorem Ipsum, ma quando la gomma colpisce la strada, questo non ha nulla a che fare con il contenuto effettivo che entra nel prodotto.

La soluzione : il contenuto è re! I design devono adattarsi al contenuto, non il contrario. Gli sviluppatori, dal momento che sono in prima linea nel punto in cui il contenuto colpisce i design, sono quelli lasciati a tenere la borsa quando non si progetta pensando prima ai contenuti. I designer, da parte loro, devono assicurarsi di disporre di un inventario completo dei contenuti prima di finalizzare i progetti.

03. Il tuo compito è solo renderlo carino, non dirmi come funziona

Il problema : il designer crea un prototipo interattivo / temporale accuratamente realizzato che funziona nel modo desiderato, ma è tutto codice “usa e getta”.

La soluzione : gli sviluppatori sono abituati a ottenere una pila di diagrammi statici e quindi a cercare di capire come farli funzionare. Passare alla prototipazione interattiva spesso si intromette in quello che pensano sia il loro territorio. Il design non è più solo quello che sembra, ma anche come funziona.

Tuttavia, il panorama su come comunicare questo aspetto sta cambiando e non tutti gli sviluppatori hanno imparato a comunicare in modo efficace. Quindi, il lavoro dei designer è parlare con loro. Fagli sapere che non stai cercando di portargli via il lavoro, ma solo di trovare modi migliori per chiarire quali sono le tue idee. E se lo sviluppatore utilizza il vecchio argomento “codice usa e getta”, chiedigli semplicemente “cosa pensi di fare con i diagrammi statici?”

04. Eseguiremo test di usabilità quando sarà disponibile

Il problema : nel mondo agile, il test utente è qualcosa di un lusso, che per gli sviluppatori può sembrare una distrazione inutile dal portare a termine il lavoro. Ma i progettisti sanno che i test utente sono efficaci solo se informano le decisioni prima del lancio.

La soluzione : durante la pianificazione degli sprint, i progettisti devono incorporare picchi di test utente che consentano loro di testare e ripetere nuovamente la fase di sviluppo. Finché gli sviluppatori pianificano questi miglioramenti, di solito accettano la loro necessità.

05. Non posso farlo

Il problema : i progetti sono stati approvati dai poteri forti, ma lo sviluppatore non li vede finché non viene detto loro di “farlo così”. L’unico problema è che il il designer stava pensando a cosa volevano fare, non a cosa era possibile.

La soluzione : in primo luogo, i progettisti devono essere radicati nelle capacità della piattaforma per cui stanno progettando. Che si tratti di Web, iOS, Android o altro, conosci il tuo mezzo. In secondo luogo, non puoi mai coinvolgere lo sviluppatore abbastanza presto nella fase di progettazione. Come minimo, includi gli sviluppatori nelle sessioni di revisione in modo da poter evitare potenziali problemi prima che sfuggano di mano.

06. Lo vuoi quando?

Il problema : poiché arriva alla fine della creazione del prodotto, la fase di sviluppo spesso viene modificata se le altre fasi sono più lunghe, soprattutto se c’è una scadenza di consegna. Se stai ancora lavorando in un processo a cascata o anche “ibrido-agile”, questo problema è aggravato.

La soluzione : se non puoi essere agile con lean-UX, almeno includi gli sviluppatori in ogni fase e lascia che inizino a lavorare su ciò che possono anche se non hai finito l’intero design.

Ero molto ostinato nel rilasciare i progetti prima di finire le schermate finali, perché ero preoccupato di dover cambiare qualcosa sugli schermi precedenti a causa delle decisioni prese a valle. Ciò ha causato infiniti problemi agli sviluppatori e ho imparato rapidamente che se li avessi preparati in anticipo per l’iterazione, avrei potuto apportare le mie modifiche e continuare a dar loro da mangiare mentre completavo le sezioni.

Originariamente pubblicato su www.jasonspeaking.com il 7 marzo 2016.

Jason CranfordTeague è il co-fondatore e capo creativo del The CranfordTeague Group , specializzato nella formazione di non designer su come creare un’ottima esperienza utente.