Vai direttamente al contenuto

Consigli per grafici prestati al web

Tra luglio e metà agosto, sempre come Modo, mi è capitato di lavorare al progetto della nuova immagine coordinata di una startup che si trova dall'altra parte del mondo (ne racconterò i dettagli più avanti, in un post ad hoc).
Durante il lavoro ho lavorato spalla a spalla con una grafica cartacea "prestata" al mondo del web.
Nonostante la grafica in questione fosse indubbiamente brava e parte di un team di persone altrettanto brave, sviluppando il progetto siamo andati incontro alle problematiche che in questi casi si presentano tra grafici e chi fa codice.
Così durante il lavoro mi sono ritrovato a pensare: "Caspita, sarebbe davvero comodo fare una lista di tutte le problematiche che si presentano di volta in volta. Tu pensa il mondo che posto migliore sarebbe!".

Il mondo con grafici e coders che collaborano secondo i testimoni di Geova

Tornato dalle vacanze estive (sì, il mondo può diventare un posto più bello anche dopo due settimane di mare), il post di un design lead molto cool d'oltreoceano si è rivelato l'occasione giusta per fare il punto sulle dinamiche design -> codice.

Questa che segue è la traduzione quasi letterale di quel post.


All'interno della comunità del web si trovano sempre più spesso designer capaci anche di scrivere codice. Complimenti a loro.
Anche se saper scrivere codice non è un requisito fondamentale per un designer, possedere questa capacità può aumentare notevolmente la qualità del suo lavoro.
Questo non vuol dire che un designer, per fare della buona UX, debba saper scrivere codice. Non sia mai.
È comodo però fare il punto della situazione e chiedersi quali sono i principi che un designer deve saper comprendere per poter creare prodotti digitali migliori (in questo caso, prodotti web).

Non puoi controllare tutto

È nella natura del web l'essere flessibile, e questa flessibilità va di pari passo con l'impossibilità di controllare tutto. Il primo passo in questo processo è abbandonare l'idea di pixel perfection: il medium in oggetto è fluido e tutte le decisioni devono essere prese tenendolo bene a mente. È assurdo pretendere di fare il design in Photoshop e di ottenere layout dalla perfezione statica per poi criticare o, ancora peggio, per trattare quei layout come se fossero dei poster.

Evita molte varianti

Le varianti degli elementi possono aumentare durante il processo di design, soprattutto nel caso di colori, grandezze di font e spaziature.
Quando nel design sono presenti molte varianti, il codice CSS può riempirsi di “casi speciali” che alla fine portano alla creazione di file che difficilmente gli sviluppatori riescono a gestire o mantenere nel tempo.
Su progetti di grande respiro, questo problema può essere amplificato e può produrre un effetto negativo anche in termini di performance.
La soluzione è semplice: controlla il design e assicurati che le variazioni siano poche. Anzi, fai di più: devono essere il minimo numero indispensabile.

Considera le perfomance

Le performance sono una caratteristica fondamentale del design, non solo una serie di norme tecniche da rispettare.
Per questo fin dall'inizio, e non alla fine del lavoro, è utile fare delle performance una parte del flusso di design.
Sono molte le scelte che i designer possono fare per progettare tenendo conto delle performace, ad esempio impostare un performance budget, usare i conditional loading, eliminare i download non necessari (e minimizzando il numero di download in assoluto), usare grafiche vettoriali invece che rasterizzate, ottimizare le immagini e allinearsi con gli sviluppatori per le politiche riguardanti le immagini responsive.
Dando priorità alle performance e condividendo ed educando le altre persone nel tuo team, ti assicuri che il risultato finale non diventi una UX lenta.

L'ordine degli elementi nel codice sorgente

All'ordine degli elementi nel codice sorgente (HTML) corrisponde l'ordine con il quale vengono visualizzati gli elementi in pagina.
Di default gli elementi vengono visualizzati dall'alto verso il basso e da sinistra verso destra, e la loro larghezza viene determinata in base alla loro proprietà display.

Mentre posizionare gli elementi fuori dal loro flusso di visualizzazione è facile, cambiare l'ordine secondo il quale gli elementi appaiono all'interno del documento visualizzato è un po' più difficile e presenta alcune limitazioni.
Il naturale ordine all'interno del codice dovrebbe guidarti quando progetti i layout che poi si adattano alle diverse larghezze di pagina.
Per cambiare questo aspetto devi avere delle ottime ragioni e devi dimostrarti il più selettivo possibile.

Allineati con gli strumenti

Senza dubbio, è frustrante vedere un progetto in produzione che presenta elementi che non appaiono come erano stati progettati inizialmente. Dalla dimensione dei testi alla generica spaziatura tra gli elementi in griglia, il design è pieno di numeri e dettagli tecnici che dovresti conoscere e tenere sempre in considerazione.
Se chi scrive il codice utilizza un framework, sarebbe carino che tu conoscessi i valori di default di questo framework insieme alle opzioni disponibili.
Se il tuo progetto è legato ad una piattaforma, sarebbe carino che tu conoscessi quella specifica piattaforma e che tu avessi qualche esperienza legata alla piattaforma stessa.
Più conoscerai gli aspetti "tecnici" che riguardano il design, più sarà facile e costruttivo comunicare con chi scrive il codice.

I breakpoints li determina il contenuto

Impostare i breakpoints basandosi sulle dimensioni dei dispositivi più comuni è efficace quanto costruire una casa sulla sabbia: in un contesto che cambia così velocemente, prendere decisioni basandosi su quello che oggi è disponibile è intrinsecamente sbagliato.
Ha molto più senso determinare i breakpoints sulla base del contenuto invece che farlo sulla base dei dispositivi utilizzati, più o meno, al giorno d'oggi.

Mantieni una coerenza

Quando devi creare un ambiente che risulti di facile utilizzo, avere un contesto che si mantiene coerente è fondamentale.
Dove è possibile è importante controllare la coerenza all'interno del progetto ovunque sia possibile, così da ridurre i casi "speciali".
Mantenere un linguaggio comune significherà avere meno casi speciali da dover considerare, e di conseguenza ti permetterà di sviluppare più semplicemente.

Comunica subito e spesso

L'aspetto più importante quando si lavora con chi scrive codice è senza dubbio la comunicazione: occorre comunicare subito e spesso. È essenziale per una collaborazione di successo essere proattivi e capire di cosa ha bisogno chi scrive codice, includendolo nelle decisioni di design e prendendo in considerazione gli eventuali vincoli tecnici che vengono evidenziati.
Ricorda: chi scrive codice condivide il tuo stesso obiettivo e, come te, vuole assicurarsi la migliore esperienza possibile per l'utente finale.


Tenendo a mente questi principi, non solo i tuoi artefatti miglioreranno ma potrai riscontrare numerosi effetti positivi a catena: design migliori equivalgono a meno avanti-indietro con gli sviluppatori, e questo vuol dire avere più tempo a disposizione da spendere sugli aspetti che migliorano la user experience dell'utente. Una migliore user experience darà come risultato utenti finali più felici, e questo produrrà di rimando clienti più contenti. Alla fine, clienti contenti portano a progetti sempre migliori.

E alla fine, come dicevo, progetti migliori equivalgono ad un mondo migliore.

Momento promozione

Bello ‘sto sito eh, ma me lo dimentico tra meno di subito

Ti capisco amico mio. Neanche io mi ricorderei di me. Per questo ho fatto una pagina about e creato una newsletter che uso per avvisarti quando pubblico qualcosa di nuovo. Metti che ti fa comodo.

Una newsletter? Sì: email molto brevi, molto di rado (la stessa frequenza con cui pubblico), e puoi cancellarti quando vuoi. Non mi offendo.

Facciamolo 💌