In che modo gli sviluppatori frontend possono potenziare il lavoro del designer

Questo articolo è principalmente rivolto a te, caro sviluppatore Frontend, a cui piace implementare le interfacce utente ma fatica ad allineare le aspettative con i designer con cui lavori. Forse vieni chiamato "Sviluppatore dell'interfaccia utente" o "Ingegnere UX". Indipendentemente dal titolo che porti con te, il tuo lavoro (e anche il mio) consiste in qualcosa di più che dare vita ai file di progettazione. Siamo inoltre responsabili di colmare il divario tra i flussi di lavoro di progettazione e sviluppo . Tuttavia, quando si attraversa quel ponte, ci troviamo di fronte a molteplici sfide.

Oggi vorrei condividere con voi suggerimenti pratici che mi hanno aiutato a collaborare in modo più efficiente con i designer negli ultimi anni.

Credo che sia nostro compito, come sviluppatori UI, aiutare non solo i designer nel loro viaggio per imparare come funziona il web, ma anche per conoscere la loro realtà e imparare la loro lingua.

Comprendere il background degli UX Designer

La maggior parte degli UX designer (indicati anche come Web Designer o Product Designer) hanno mosso i primi passi nel mondo del design attraverso strumenti come Photoshop e Illustrator. Forse erano Graphic Designer : il loro obiettivo principale era creare loghi e brand identity e progettare layout per riviste. Avrebbero potuto anche essere Marketing Designer : stampa di cartelloni pubblicitari, progettazione di banner e creazione di infografiche.

Ciò significa che la maggior parte dei designer UX ha trascorso i suoi primi giorni a progettare per la stampa, che è un paradigma completamente diverso dal loro mezzo attuale, lo schermo. Quella fu la loro prima grande sfida. Quando si trattava di stampa, i designer si preoccupavano dell'allineamento dei pixel, ma su un'area fissa (carta). Non hanno dovuto fare i conti con un layout dinamico (schermi). Anche pensare alla rottura del testo o agli stati di interazione semplicemente non faceva parte del loro lavoro. I designer avevano anche completa libertà su colori, immagini e tipografia senza vincoli di prestazioni.

Fortunatamente, ci sono stati molti sforzi da parte della comunità dei designer UX autodidatti, per insegnare i fondamenti dello sviluppo, discutere se i designer dovrebbero imparare a programmare e capire come eseguire al meglio il trasferimento agli sviluppatori. Lo stesso valeva anche per il lato sviluppo (ne parleremo tra un minuto). Tuttavia, c'è ancora attrito in corso tra i due campi.

Da un lato, i progettisti si lamentano ogni volta che un'implementazione non corrisponde ai loro progetti o si sentono incompresi quando questi vengono rifiutati dagli sviluppatori senza una chiara spiegazione. D'altra parte, gli sviluppatori potrebbero dare per scontato che i designer sappiano qualcosa di tecnico quando potrebbe non essere vero. Credo che tutti possiamo fare meglio di così.

Abbracciare un nuovo modo di pensare

I siti Web e le app che stiamo costruendo verranno visualizzati su un'ampia gamma di dimensioni dello schermo. Ogni persona li utilizzerà su più dispositivi. Il nostro obiettivo comune è creare un'esperienza familiare attraverso i loro viaggi.

Quando noi, come sviluppatori, pensiamo che i designer siano schizzinosi riguardo agli allineamenti dei pixel, dobbiamo capire perché è così. Dobbiamo riconoscere che va oltre la fedeltà e la coerenza. Si tratta della somma di tutte le parti che lavorano insieme. È coesione. Dobbiamo abbracciarlo e fare del nostro meglio per realizzarlo. Imparare i fondamenti dei principi di progettazione è un buon punto di partenza . Comprendi l'importanza di selezionare i colori giusti, come funziona la gerarchia e perché lo spazio bianco è importante.

Nota : c'è un corso online noto come "Design for Developers" e un libro chiamato "Refactoring UI": entrambi sono ottimi per iniziare. Con questi, sarai in grado di implementare interfacce utente con un occhio attento ai dettagli e ottenere una leva significativa durante la comunicazione con i designer.

Ingrandire la consapevolezza dei tuoi designer

Potresti dare per scontato che i designer conoscano il web tanto quanto te. Beh, potrebbero non farlo. In realtà, non è necessario! È nostra responsabilità, come sviluppatori, tenerli aggiornati sullo stato attuale del web.

Ho lavorato con i due lati di questo spettro: i progettisti che pensano che qualsiasi cosa possa essere costruita (come filtri complessi, nuovi comportamenti di scorrimento o input di moduli personalizzati) senza pensare alla compatibilità del browser. Poi, ci sono designer con ipotesi sui "basi limiti del web" e presumono da soli che qualcosa sia impossibile da implementare. Dobbiamo mostrare loro le vere possibilità del web design e non lasciare che i limiti ostacolino le loro capacità.

Insegna loro il codice, non come programmare

Questo sembra contraddittorio, ma abbi pazienza: sapere come programmare è al centro del lavoro di uno sviluppatore. Lavoriamo in un settore frenetico con nuove cose che spuntano ogni giorno. Sarebbe una nostra richiesta ipocrita chiedere ai progettisti di imparare a programmare. Tuttavia, possiamo aiutarli a capire il codice.

Siediti accanto al designer con cui lavori per 15 minuti e insegnagli come possono vedere da soli se le specifiche di un elemento sono corrette e come cambiarle. Trovo Firefox Page Inspector straordinariamente intuitivo per questo.

Al giorno d'oggi, è un piacere visualizzare layout, eseguire il debug di animazioni CSS e modificare la tipografia. Mostra loro un parco giochi di codice pronto per l'uso come Codepen da esplorare. Non hanno bisogno di conoscere tutte le specifiche CSS per capire come funziona il paradigma del layout. Tuttavia, hanno bisogno di sapere come vengono creati gli elementi e come si comportano per potenziare il loro lavoro quotidiano.

Includere i designer nel processo di sviluppo

Invita i designer a unirsi a te nella riunione stand-up, a partecipare al processo di QA e a sedersi con te mentre perfezioni i dettagli visivi nelle tue implementazioni. Ciò consentirà loro di comprendere i vincoli del Web e, abbastanza presto, riconosceranno perché una funzionalità richiede tempo per essere implementata.

Chiedi ai designer di includerti nel loro processo di progettazione

Ti renderai conto che fanno molto di più che "rendere le cose belle". Imparerai di più sul processo di ricerca e su come viene eseguito il test degli utenti. Scoprirai che per ogni proposta di design che ti viene mostrata, molti altri studi sono stati precedentemente abbandonati. Quando i designer richiedono una modifica, chiedine il motivo, così puoi saperne di più sulle decisioni che vengono prese . Alla fine, inizierai a capire perché sono schizzinosi riguardo agli spazi bianchi e agli allineamenti e, si spera, presto lo sarai anche tu!

Trovo fondamentale trattare lo sviluppo del frontend come una parte fondamentale del processo di progettazione e il design come una parte fondamentale del processo di sviluppo. Sostenere una mentalità in cui tutti hanno la possibilità di essere coinvolti nel ciclo di progettazione e sviluppo aiuterà tutti noi a comprendere meglio le sfide reciproche e anche a creare grandi esperienze.

Possiamo usare strumenti diversi, ma dobbiamo parlare la stessa lingua

Ora che stiamo iniziando a capire un po' meglio il flusso di lavoro dell'altro, è il momento del passaggio successivo: parlare la stessa lingua.

Guardando oltre l'editor di codice

Una volta che inizi a prestare attenzione a ciò che ti circonda, sarai meglio attrezzato per affrontare i problemi. Conosci meglio l'azienda e sii disposto ad ascoltare ciò che i designer hanno da dire. Ciò ti renderà un membro del team con contributi più ricchi al progetto. Collaborare in aree che esulano dalle nostre competenze è la chiave per creare conversazioni significative e fiducia reciproca.

Utilizzo dei sistemi dell'interfaccia utente come contratto

Chiedi ai designer di condividere con te il loro sistema di progettazione (e se non ne usano uno, non è mai troppo tardi per iniziare). Ciò ti farà risparmiare il fastidio di scegliere manualmente i colori utilizzati, capire i margini o indovinare uno stile di testo. Assicurati di avere familiarità con il sistema dell'interfaccia utente tanto quanto loro.

Potresti già avere familiarità con il concetto basato sui componenti. Tuttavia, alcuni designer potrebbero non percepirlo come te. Mostra loro come i componenti possono aiutarti a creare interfacce utente in modo più efficiente. Diffondi quella mentalità e saluta anche nomi simili ma non uguali: intestazione vs eroe, informazioni sui prezzi vs selettore dei prezzi . Quando viene creata una parte dell'interfaccia utente (nota anche come "componente"), cerca di utilizzare gli stessi nomi in modo che possano riflettersi sia nei file di progettazione che in quelli di codice. Quindi, quando qualcuno dice: "Dobbiamo modificare il widget di invito alla proposta", tutti sanno esattamente di cosa si parla.

Riconoscere la vera fonte della verità

Nonostante il fatto che l'interfaccia utente venga prima creata nei file di progettazione, la vera fonte di verità è sul lato dello sviluppo. Alla fine della giornata, è ciò che le persone vedono davvero, giusto? Quando un design viene aggiornato, è una buona idea lasciare una nota a margine sul suo stato di sviluppo, specialmente nei progetti che coinvolgono un gran numero di persone. Questo trucco aiuta a mantenere la comunicazione fluida, quindi nessuno (compreso te) si chiede: “ Questa è diversa dalla versione live. È un bug o non è stato ancora implementato il tal dei tali? "

Tenere il debito sotto controllo

Quindi, sai tutto sul debito tecnico : succede quando il costo per implementare qualcosa di nuovo è alto a causa di una scorciatoia che abbiamo preso in passato per rispettare una scadenza. Lo stesso può accadere anche dal punto di vista del design e lo chiamiamo debito di design .

Puoi pensarci in questo modo: maggiore è l'incoerenza tra UX e UI, maggiore è il debito (tecnico e di design). Una delle incongruenze più comuni sta nell'avere elementi diversi per rappresentare la stessa azione. Questo è il motivo per cui un cattivo design di solito si riflette in un codice errato . Spetta a tutti noi, sia come designer che come sviluppatori, trattare seriamente il nostro debito di progettazione.

Essere accessibili non significa che debba essere brutto

Sono davvero felice di vedere che sia noi, come sviluppatori che designer, stiamo finalmente iniziando a portare l'accessibilità nel nostro lavoro. Tuttavia, molti di noi pensano ancora che progettare prodotti accessibili sia difficile o limiti le nostre capacità e creatività.

Lascia che ti ricordi che non stiamo creando un prodotto solo per noi stessi. Stiamo creando un prodotto che può essere utilizzato da tutte le persone , comprese quelle che utilizzano il prodotto in modi diversi da te. Tieni conto di come i singoli elementi possono essere più accessibili mantenendo gli attuali flussi di utenti chiari e coerenti.

Ad esempio, se un designer crede davvero che sia necessario creare un input selezionato migliorato, stare al suo fianco e collaborare per progettarlo e implementarlo in modo accessibile per essere utilizzato da un'ampia gamma di persone con abilità diverse.

Dare un feedback prezioso ai designer

È inevitabile che appaiano domande quando si esaminano i progetti. Tuttavia, questo non è un motivo per iniziare a lamentarti degli errori dei designer o delle loro idee ambiziose. I designer non sono lì per guidarti mentalmente, semplicemente non sempre sanno intuitivamente di cosa hai bisogno per fare il tuo lavoro. La verità è che, in passato, non sapevi nemmeno di queste cose, quindi sii paziente e abbraccia la collaborazione come un modo per imparare.

Prima è il feedback, meglio è

La tempistica per il feedback è cruciale. Il flusso di lavoro del feedback dipende molto dalla struttura del progetto, quindi non esiste una soluzione valida per tutti. Tuttavia, quando possibile, credo che dovremmo puntare a un flusso di lavoro di feedback periodico , a partire dalle prime fasi. Avere questa mentalità di collaborazione aperta è il modo per ridurre la possibilità di grandi ripetizioni inaspettate più avanti nel percorso. Tieni presente che più tardi fornirai al designer il tuo primo feedback, maggiore sarà il costo per esplorare un nuovo approccio, se necessario.

Spiega le idee astratte in termini semplici

Ricordi quando ho detto che le prestazioni non erano una preoccupazione dei precedenti lavori dei designer? Non impazzire quando non sono a conoscenza di come creare SVG ottimizzati per il Web. Di fronte a un design che richiede il caricamento di molti font diversi, spiega loro perché dovremmo ridurre al minimo il numero di richieste, magari anche sfruttare i Variable Fonts. Oltre a caricare più velocemente, fornisce anche un'esperienza utente più coerente. A meno che i designer non vogliano imparare, evita di usare troppi termini tecnici quando spieghi qualcosa. Puoi vedere questa come un'opportunità per migliorare le tue capacità comunicative e chiarire i tuoi pensieri.

Non lasciare che le ipotesi si trasformino in decisioni

Alcune domande su una specifica di progettazione vengono visualizzate solo quando ci sporchiamo le mani nel codice. Per accelerare le cose, potremmo sentirci tentati di prendere decisioni basate sui nostri presupposti. Per favore, non farlo. Ogni volta che trasformi un'ipotesi in una decisione, stai rischiando la fiducia che il team di progettazione ripone in te per implementare l'interfaccia utente. In caso di dubbio, raggiungi e chiarisci i tuoi dubbi . Questo mostrerà loro che tieni al risultato finale tanto quanto loro.

Non fare soluzioni alternative da solo

Quando ti viene chiesto di implementare un progetto che è troppo difficile, non dire "È impossibile" o iniziare a implementarne una versione alternativa economica da solo. Ciò provoca immediatamente l'attrito con il team di progettazione quando vede che i loro progetti non sono stati implementati come previsto. Potrebbero reagire con rabbia o non dire nulla ma sentirsi sconfitti o frustrati. Tutto ciò può essere evitato se spieghiamo loro perché qualcosa non è possibile, in termini semplici e suggeriamo approcci alternativi. Evita comportamenti dogmatici e sii aperto a collaborare a una nuova soluzione .

Fai loro conoscere le tecniche di Graziosa Degradazione e Miglioramento Progressivo e costruisci insieme una soluzione ideale e una soluzione di fallback. Ad esempio, possiamo migliorare un layout da flexbox a CSS Grid. Questo ci consente di rispettare lo scopo principale di una funzionalità e allo stesso tempo utilizzare al meglio le tecnologie web.

Quando si tratta di animazioni, siamo realisti: in fondo sei entusiasta di implementare la prossima animazione wow tanto quanto i designer lo sono di crearla. La differenza tra noi e loro è che siamo più consapevoli dei vincoli del web. Tuttavia, non lasciare che ciò limiti le tue abilità! Il web si evolve velocemente, quindi dobbiamo usarlo a nostro favore.

La prossima volta che ti verrà chiesto di dare vita a un prototipo, cerca di non rifiutarlo in anticipo o di fare tutto da solo. Vedila come un'opportunità per spingerti oltre. Le animazioni sono una delle parti più difficili dello sviluppo web, quindi assicurati di perfezionare ogni fotogramma chiave con il tuo designer, di persona o condividendo un collegamento sincronizzato privato.

Pensare oltre lo stato ideale: insieme

Ecco il punto: non si tratta solo di te. Una delle sfide dei designer è capire davvero i loro utenti e presentare i progetti nel modo più attraente da vendere al Product Manager. A volte dimenticano ciò che è oltre lo stato ideale e anche gli sviluppatori lo dimenticano.

Per evitare che si verifichino queste lacune, allineare con i progettisti i requisiti dello scenario:

• Lo scenario peggiore
  Uno scenario in cui si stanno verificando le peggiori possibilità. Questo aiuta i designer a dire no ai contenuti fissi e a renderli fluidi. Cosa succede se il titolo ha più di 60 caratteri o se l'elenco è troppo lungo? Lo stesso vale per l'opposto, lo scenario vuoto. Cosa deve fare l'utente quando l'elenco è vuoto?
• Stati di interazione
  Il browser è più che passare il mouse e fare clic. Ci sono un sacco di stati: predefinito, hover, focus, attivo, disabilita, errore... e alcuni di essi possono verificarsi contemporaneamente. Diamo loro la giusta attenzione.
• Lo stato di caricamento
  Quando costruiamo cose in locale, potremmo usare mock e dimenticare che le cose in realtà richiedono tempo per essere caricate. Fai conoscere anche ai designer questa possibilità e mostra loro che sono modi per far percepire alle persone che le cose non impiegano molto a caricarsi.

Prendere in considerazione tutti questi scenari ti farà risparmiare un sacco di tempo andando avanti e indietro durante la fase di sviluppo.

Nota : c'è un ottimo articolo di Scott Hurff su come correggere le interfacce utente errate che ci porterà un passo avanti verso un prodotto accessibile.

Accetta le richieste di modifica

Gli sviluppatori sono noti per non essere troppo contenti che qualcuno trovi un bug nel loro codice, specialmente quando si tratta di un bug di progettazione segnalato da un designer. Ci sono molti meme intorno ad esso, ma hai mai riflettuto su come quei bug possono rovinare in modo combinato sia la qualità dell'esperienza che la tua relazione quando questi bug di progettazione vengono ignorati casualmente? Succede lentamente, quasi come addormentarsi. A poco a poco, poi tutto in una volta. I designer potrebbero iniziare dicendo: " È solo un minuscolo dettaglio", fino a quando l'indifferenza e il risentimento si accumulano e non viene detto nulla. Il danno allora è già stato fatto.

Questa situazione è duplice: sia per i tuoi coetanei che per il tuo lavoro. Non lasciare che accada. Lavora su cosa sta colorando la tua reazione. Un designer che è "pignolo" può essere scomodo, ma può anche essere l'interpretazione superficiale di attenzione ed entusiasmo da parte di un ingegnere. Quando qualcuno ti dice che la tua implementazione non è (ancora) perfetta, metti da parte il tuo ego e mostragli come riconosci il loro duro lavoro nel perfezionare il risultato finale.

Andare fuori registro una volta ogni tanto

Tutti abbiamo compiti da consegnare e tabelle di marcia da portare a termine. Tuttavia, alcuni dei migliori lavori vengono eseguiti fuori dagli archivi. Non verrà registrato nella scheda DA FARE e va bene. Se trovi un designer con cui hai un rapporto, entra di soppiatto nel suo spazio di lavoro ed esplora insieme nuovi esperimenti. Non si sa mai cosa può venire da lì!

Conclusione

Quando sei disposto a imparare dal team di progettazione, stai anche imparando diversi modi di pensare. Farai evolvere la tua mentalità di collaborazione con altre aree fuori dalla tua esperienza, affinando il tuo occhio per creare nuove esperienze. Essere lì per aiutare ed essere aperti all'apprendimento, perché la condivisione è ciò che ci rende migliori.

Questo articolo non sarebbe possibile senza il feedback di molte persone fantastiche. Voglio ringraziare con gratitudine i designer Jasmine Meijer e Margarida Botelho per avermi aiutato a condividere una prospettiva equilibrata sulle incomprensioni tra designer e sviluppatori.

Letture correlate su SmashingMag:

• "Design per sviluppatori" di Mason Gentry
• "Lavorare insieme: come designer e sviluppatori possono comunicare per creare progetti migliori" di Rachel Andrew
• "Come gli sviluppatori frontend possono aiutare a colmare il divario tra designer e sviluppatori" di Stefan Kaltenegger
• "Quali podcast dovrebbero ascoltare web designer e sviluppatori?" di Ricky Onsman