In che modo gli sviluppatori frontend possono aiutare a colmare il divario tra designer e sviluppatori

Negli ultimi nove anni, quasi tutti i designer con cui lavoravo mi hanno espresso la loro frustrazione per il fatto che spesso devono passare giorni a fornire feedback agli sviluppatori per correggere le spaziature, le dimensioni dei caratteri, gli aspetti visivi e di layout che semplicemente non erano stati implementati correttamente . Questo spesso porta a indebolire la fiducia tra designer e sviluppatori e ha causato designer demotivati ​​insieme a una cattiva atmosfera tra le due discipline.

Molte volte gli sviluppatori sembrano avere ancora la cattiva reputazione di essere eccessivamente tecnici e ignoranti quando si tratta di essere attenti ai dettagli che il team di progettazione ha inventato. Secondo un articolo di Andy Budd, "[...] molti sviluppatori sono nella stessa posizione riguardo al design, semplicemente non se ne rendono conto". In realtà, tuttavia (come sottolinea Paul Boag), "gli sviluppatori [devono] prendere decisioni di progettazione tutto il tempo".

In questo articolo, fornirò consigli pratici agli sviluppatori frontend per evitare frustrazioni e aumentare la produttività quando lavorano con la loro controparte creativa.

Guardando attraverso gli occhi di un designer

Immaginiamo per un momento che tu sia un designer e che abbia trascorso le ultime settimane, se non mesi, a elaborare un design per un sito web. Tu e i tuoi compagni di squadra avete eseguito più revisioni interne e presentazioni dei clienti e vi siete impegnati molto per mettere a punto i dettagli visivi come lo spazio bianco, gli stili dei caratteri e le dimensioni. (In un'era reattiva, per schermi di dimensioni multiple, ovviamente.) I progetti sono stati approvati dal cliente e sono stati consegnati agli sviluppatori. Ti senti sollevato e felice.

Poche settimane dopo, ricevi un'e-mail dal tuo sviluppatore che dice:

“Il sito di staging è allestito. Ecco il link. Puoi per favore QA?"

In un brivido di anticipazione, apri quel link di staging e dopo aver sfogliato alcune pagine, noti che il sito sembra un po' strano. Le spaziature non sono nemmeno vicine a quelle suggerite dal tuo design e noti alcuni nodi nel layout: caratteri e colori errati, nonché interazioni e stati al passaggio del mouse errati. La tua eccitazione inizia lentamente a svanire e si trasforma in una sensazione di frustrazione. Non puoi fare a meno di chiederti: "Come è possibile che sia successo?"

La ricerca di ragioni

Forse ci sono stati solo molti sfortunati malintesi nella comunicazione tra i designer e gli sviluppatori. Tuttavia, continui a chiederti:

• Com'era la consegna dei disegni? C'erano solo alcuni file PDF, Photoshop o Sketch condivisi via e-mail con alcuni commenti, o c'è stato un vero e proprio incontro di consegna in cui sono stati discussi vari aspetti come un possibile sistema di progettazione, tipografia, comportamento reattivo, interazioni e animazioni?
• Esistono prototipi interattivi o di movimento che aiutano a visualizzare determinate interazioni?
• È stato creato un elenco di aspetti importanti con livelli di priorità definiti?
• Quante conversazioni hanno avuto luogo, con designer e sviluppatori nella stessa stanza insieme?

Poiché la comunicazione e la consegna sono due punti chiave molto importanti, diamo un'occhiata più da vicino a ciascuno.

La comunicazione è fondamentale

Designer e sviluppatori, parlate tra loro. Parla molto . Prima nel progetto e più spesso, meglio è. Se possibile, rivedere insieme il lavoro di progettazione in corso all'inizio del progetto (e regolarmente) al fine di valutare costantemente la fattibilità e ottenere input interdisciplinari. Designer e sviluppatori naturalmente si concentrano entrambi su aspetti diversi della stessa parte e quindi vedono le cose da diverse angolazioni e prospettive .

Il check-in anticipato consente agli sviluppatori di familiarizzare con il progetto in modo che possano iniziare a ricercare e pianificare in anticipo i termini tecnici e portare le loro idee su come ottimizzare le funzionalità. Avere frequenti check-in riunisce anche il team a livello personale e sociale e impari come avvicinarti l'un l'altro per comunicare in modo efficace.

Il passaggio dalla progettazione allo sviluppo

A meno che un'organizzazione non segua un flusso di lavoro veramente agile, a un certo punto del progetto avverrà probabilmente un passaggio iniziale di componenti di progettazione e risorse (dal team di progettazione agli sviluppatori). Questo passaggio di consegne, se fatto a fondo, può essere una solida base di conoscenza e accordi tra le due parti. Pertanto, è essenziale non affrettarsi e pianificare del tempo extra.

Poni molte domande e parla di ogni requisito, pagina, componente, funzionalità, interazione, animazione, qualsiasi cosa e prendi appunti. Se le cose non sono chiare, chiedi chiarimenti . Ad esempio, quando si lavora con team esterni oa contratto, sia i progettisti che gli sviluppatori possono firmare le note prese come documento di reciproco accordo per riferimento futuro.

Le composizioni di design piatte e statiche sono utili per mostrare gli aspetti grafici e di layout di un sito Web, ma ovviamente mancano della rappresentazione adeguata delle interazioni e delle animazioni. La richiesta di prototipi o demo funzionanti di animazioni complesse creerà una visione più chiara di ciò che deve essere costruito per tutti i soggetti coinvolti.

Al giorno d'oggi, è disponibile un'ampia gamma di strumenti di prototipazione che i progettisti possono utilizzare per simulare flussi e interazioni a diversi livelli di fedeltà. Javier Cuello spiega come scegliere lo strumento di prototipazione giusto per il tuo progetto in uno dei suoi articoli completi.

Ogni progetto è unico, così come i suoi requisiti. A causa di questi requisiti, non è sempre possibile creare tutte le funzionalità concettualizzate. Spesso il tempo e le risorse disponibili per costruire qualcosa possono essere un fattore limitante. Inoltre, i vincoli possono derivare da requisiti tecnici come fattibilità, accessibilità, prestazioni, usabilità e supporto cross-browser, requisiti economici come budget e costi di licenza o vincoli personali come il livello di abilità e la disponibilità degli sviluppatori.

Quindi, cosa succede se questi vincoli causano conflitti tra designer e sviluppatori?

Trovare compromessi e costruire conoscenze condivise

Per spedire con successo un progetto in tempo e soddisfare tutti i requisiti definiti, è per lo più inevitabile trovare compromessi tra le due discipline. Gli sviluppatori devono imparare a parlare con i progettisti in termini non tecnici quando spiegano i motivi per cui le cose hanno bisogno di modifiche o non possono essere costruite in una situazione specifica.

Invece di limitarsi a dire "Mi dispiace, non possiamo costruirlo", gli sviluppatori dovrebbero cercare di fornire una spiegazione comprensibile per i progettisti e, nel migliore dei casi, preparare suggerimenti per una soluzione alternativa che funzioni entro i vincoli noti. Sostenere il tuo punto con statistiche, ricerche o articoli può aiutare a enfatizzare la tua argomentazione. Inoltre, se la tempistica è un problema, forse l'implementazione di alcune parti che richiedono tempo può essere spostata in una fase successiva del progetto?

Anche se non è sempre possibile, avere designer e sviluppatori seduti uno accanto all'altro può ridurre i cicli di feedback e rendere più facile elaborare una soluzione compromessa. L'adattamento e la prototipazione possono essere eseguiti direttamente tramite la codifica e l'ottimizzazione con DevTools aperto.

Mostra ai tuoi colleghi designer come utilizzare DevTools in un browser in modo che possano modificare le informazioni di base e visualizzare in anteprima piccole modifiche nel browser (ad es. riempimenti, margini, dimensioni dei caratteri, nomi delle classi) al volo.

Se il progetto e la struttura del team lo consentono, la creazione e la prototipazione nel browser il prima possibile possono fornire a tutti i soggetti coinvolti una migliore comprensione del comportamento reattivo e possono aiutare a eliminare bug ed errori nella fase iniziale del progetto.

Più a lungo designer e sviluppatori lavorano insieme, meglio i designer capiranno cosa è più facile e cosa è più difficile da costruire per gli sviluppatori. Nel tempo, possono eventualmente fare riferimento a soluzioni che hanno funzionato per entrambe le parti in passato:

"Abbiamo usato quella soluzione per trovare un compromesso nel Progetto A. Possiamo usarla anche per questo progetto?"

Questo aiuta anche gli sviluppatori a capire meglio quali dettagli i designer sono molto specifici e quali aspetti visivi sono importanti per loro.

I designer si aspettano che il frontend appaia (e funzioni) come il loro design

Il file di progettazione vs. Confronto browser

Una tecnica utile per evitare frustrazioni ai progettisti consiste nel fare un semplice confronto sinistro-destro tra il file di progettazione che ti è stato consegnato e l'aspetto del tuo attuale stato di sviluppo. Potrebbe sembrare banale, ma come sviluppatore, devi occuparti di così tante cose che devono funzionare sotto il cofano che potresti aver perso alcuni dettagli visivi. Se vedi delle discrepanze evidenti, correggile semplicemente.

Pensala in questo modo: ogni dettaglio della tua implementazione che sembra esattamente come è stato progettato fa risparmiare tempo prezioso e grattacapi sia a te che al designer e incoraggia la fiducia. Non tutti potrebbero avere lo stesso livello di attenzione ai dettagli, ma per allenare l'occhio a notare le differenze visive, un breve giro di Can't Unsee potrebbe essere di buon aiuto.

Questo mi ricorda nostalgicamente un gioco a cui giocavamo molto tempo fa chiamato "Trova". Dovevi trovare discrepanze confrontando due immagini apparentemente simili per ottenere punti.

Tuttavia, potresti pensare:

"E se semplicemente non ci fosse un sistema evidente di dimensioni e spaziature dei caratteri nel design?"

Bene, buon punto! L'esperienza mi ha dimostrato che può aiutare ad avviare una conversazione con i designer chiedendo chiarimenti piuttosto che iniziare a cambiare radicalmente le cose da soli e creare sorprese indesiderate per i designer in seguito.

Impara le regole tipografiche e di progettazione di base

Come afferma Oliver Reichenstein in uno dei suoi articoli, il 95% delle informazioni sul web è in lingua scritta. Pertanto, la tipografia gioca un ruolo fondamentale non solo nel web design ma anche nello sviluppo. Comprendere i termini e i concetti di base della tipografia può aiutarti a comunicare in modo più efficace con i designer e ti renderà anche più versatile come sviluppatore. Consiglio di leggere l'articolo di Oliver in quanto elabora l'importanza della tipografia sul web e spiega termini come micro e macro-tipografia .

Nella "Guida di riferimento per la tipografia nel Web design mobile", Suzanne Scacca tratta in modo approfondito la terminologia tipografica come carattere tipografico, carattere, dimensione, peso, crenatura, guida e tracciamento, nonché il ruolo della tipografia nel moderno web design.

Se desideri espandere ulteriormente il tuo orizzonte tipografico, vale la pena leggere il libro di Matthew Butterick "La tipografia pratica di Butterick". Fornisce inoltre un riepilogo delle regole chiave della tipografia.

Una cosa che ho trovato particolarmente utile nel responsive web design è che si dovrebbe puntare a una lunghezza media di riga (caratteri per riga) da 45 a 90 caratteri poiché le righe più corte sono più comode da leggere rispetto alle righe più lunghe.

Gli sviluppatori dovrebbero progettare?

Si è discusso molto se i designer debbano imparare a programmare e potresti farti la stessa domanda al contrario. Credo che difficilmente si possa eccellere in entrambe le discipline, e va benissimo così.

Rachel Andrew sottolinea bene nel suo articolo "Lavorare insieme: come designer e sviluppatori possono comunicare per creare progetti migliori" che per collaborare in modo più efficace , dobbiamo tutti imparare qualcosa della lingua, delle abilità e delle priorità dei nostri compagni di squadra in modo da poter può creare un linguaggio condiviso e aree di competenza sovrapposte.

Un modo per diventare più informati nel campo del design è un corso online noto come "Design for Developers" offerto da Sarah Drasner in cui parla dei principi di base del layout e della teoria del colore, due aree fondamentali del web design.

"Più impari al di fuori della tua disciplina, in realtà è meglio per te [...] come sviluppatore."

— Sarah Drasner

Il centro visivo

Collaborando con i designer, ho imparato la differenza tra il centro matematico e quello visivo. Quando vogliamo attirare l'attenzione del lettore su un determinato elemento, il punto focale naturale del nostro occhio si trova appena sopra il centro matematico della pagina.

Possiamo applicare questo concetto, ad esempio, per posizionare modali o qualsiasi tipo di sovrapposizione. Questa tecnica ci aiuta ad attirare naturalmente l'attenzione dell'utente e fa apparire il design più equilibrato:

Siamo tutti sulla stessa barca

In ambienti di agenzia frenetici e non così agili con scadenze ravvicinate, agli sviluppatori viene spesso chiesto di implementare frontend reattivi completamente funzionali basati su un mockup mobile e desktop. Ciò obbliga inevitabilmente lo sviluppatore a prendere decisioni di progettazione durante tutto il processo. Domande come "A quale larghezza ridurremo la dimensione del carattere dei titoli?" o "Quando dovremmo cambiare il nostro layout a tre colonne in una singola colonna?" può sorgere.

Inoltre, nella foga del momento, può succedere che dettagli come stati di errore, notifiche, stati di caricamento, modali o stili di 404 pagine semplicemente cadano attraverso le crepe. In tali situazioni, è facile iniziare a puntare il dito e incolpare le persone che avrebbero dovuto pensarci prima. Idealmente, gli sviluppatori non dovrebbero mai trovarsi in una situazione del genere, ma se fosse così?

Quando ho ascoltato il fondatore e CEO di Ueno, Haraldur Thorleifsson, parlare a una conferenza a San Francisco nel 2018, ha presentato due dei loro valori fondamentali:

"Niente qui è un problema di qualcun altro."

"Raccogliamo la spazzatura che non abbiamo gettato".

E se più sviluppatori iniziassero in modo proattivo a simulare le parti mancanti sopra menzionate nel miglior modo possibile in primo luogo, e poi perfezionassero insieme al designer seduto accanto a loro? I siti Web risiedono nel browser, quindi perché non utilizzarlo per creare e perfezionare?

Anche se l'ala mancante o dimenticata potrebbe non essere sempre l'ideale, ho imparato nelle mie esperienze passate che ci ha sempre aiutato ad andare avanti più velocemente ed eliminare gli errori al volo, come una squadra .

Naturalmente, questo non significa che i designer debbano essere annullati nel processo. Significa che gli sviluppatori dovrebbero cercare di incontrare rispettosamente i designer a metà strada mostrando iniziativa nella risoluzione dei problemi. Oltre a ciò, io come sviluppatore sono stato apprezzato molto di più dal team semplicemente per la cura e l'assunzione di responsabilità.

Costruire la fiducia tra designer e sviluppatori

Avere un rapporto di fiducia e positivo tra il team creativo e tecnico può aumentare notevolmente la produttività e il risultato del lavoro. Quindi cosa possiamo fare noi, come sviluppatori, per aumentare la fiducia tra le due discipline? Ecco alcuni suggerimenti:

1. Mostra un occhio per i dettagli .
   Costruire le cose esattamente come sono state progettate mostrerà ai designer che ci tieni e farà sorridere i loro volti.
2. Comunicare con rispetto .
   Siamo tutti esseri umani in un ambiente professionale che lotta per il miglior risultato possibile. Mostrare rispetto per la disciplina dell'altro dovrebbe essere la base di ogni comunicazione.
3. Check-in presto e regolarmente .
   Coinvolgere gli sviluppatori fin dall'inizio può aiutare a eliminare gli errori fin dall'inizio. Attraverso una comunicazione frequente, i membri del team possono sviluppare un linguaggio condiviso e una migliore comprensione delle reciproche posizioni.
4. Renditi disponibile .
   Avere almeno una finestra opzionale di 30 minuti al giorno in cui i designer possono discutere le idee con gli sviluppatori può dare ai designer la sensazione di essere supportati. Questo dà anche agli sviluppatori l'opportunità di spiegare cose tecniche complesse con parole che le persone meno tecniche possono capire meglio.

Il risultato: una situazione vantaggiosa per tutti

Il fatto di dover dedicare meno tempo al QA attraverso una comunicazione efficace e una corretta consegna dei progetti offre sia al team creativo che a quello di sviluppo più tempo per concentrarsi sulla creazione di cose reali e meno grattacapi. Alla fine crea un'atmosfera migliore e crea fiducia tra designer e sviluppatori. La voce degli sviluppatori frontend che mostrano interesse e conoscenza in alcuni campi legati al design sarà ascoltata maggiormente nelle riunioni di design.

Contribuire in modo proattivo alla ricerca di un compromesso tra designer e sviluppatori e alla risoluzione dei problemi come sviluppatore può darti un più ampio senso di appartenenza e coinvolgimento nell'intero progetto. Anche nell'industria creativa in forte espansione di oggi, non è facile trovare sviluppatori che, oltre alle loro competenze tecniche, si preoccupino e abbiano occhio per i dettagli visivi. Questa può essere la tua opportunità per aiutare a colmare il divario nella tua squadra.

Risorse correlate

• "Come scegliere lo strumento di prototipazione giusto", Javier Cuello
• "Una guida di riferimento per la tipografia nel Web design mobile", Suzanne Scacca
• "La tipografia pratica di Butterick", Matthew Butterick
• "Lavorare insieme: come designer e sviluppatori possono comunicare per creare progetti migliori", Rachel Andrew
• "Design per sviluppatori", Sarah Drasner, Master Frontend
• "Il web design è per il 95% tipografia", Oliver Reichenstein
• "Can't Unsee", un quiz del browser per allenare il tuo senso di riconoscimento dei dettagli visivi.