Da qualche mese ho il piacere di insegnare UX/UI Design a giovani designer e più di una volta mi è capitato di raccontare loro alcuni aneddoti relativi a errori compiuti nei miei progetti.
Ecco quindi una lista di errori (ovviamente io li ho fatto tutti) da tenere a mente quando progetterai la tua prossima interfaccia.
1. Ignorare il contesto
Non è raro che i designer introducano funzionalità che complicano eccessivamente il processo di sviluppo senza apportare alcun valore aggiuntivo all’applicazione. Concentrarsi sugli obiettivi di business, l’ambito del progetto, la tempistica e il modo in cui i prodotti vengono sviluppati sono tutte considerazioni preziose quando si assegnano le priorità alle funzionalità per la progettazione.
Se, ad esempio, stiamo progettando un’opzione per consentire agli utenti di caricare un’immagine del profilo ma aggiungiamo anche funzionalità per ritagliare, ridimensionare e ruotare la foto, ciò potrebbe complicare inutilmente il design.
È facile aggiungere un pulsante “ruota” o “ritaglia” nel mockup, ma sarebbe più complicato da implementare durante lo sviluppo.
Progetta sempre le funzionalità essenziali per l’applicazione, tenendo a mente gli obiettivi aziendali e degli utenti nel processo di progettazione.
2. Non preparare i file per l’handoff
Quando progettiamo un prodotto o un’esperienza, dobbiamo tenere conto di chi altro utilizzerà il nostro lavoro.
I nostri progetti saranno consegnati a sviluppatori o altri designer, quindi tutto deve essere organizzato e adeguatamente documentato.
I nostri file di progettazione dovrebbero avere tavole da disegno denominate e disposte in modo ordinato.
Dovremmo ad esempio avere un file organizzato che contenga tutte le icone in formato SVG e una versione di alta qualità di qualsiasi immagine utilizzata nei nostri progetti.
Quando cedo il mio lavoro agli sviluppatori, spesso utilizzo Zeplin, all’interno del quale carico tutti i file di Sketch.
Zeplin consente agli sviluppatori di acquisire facilmente snippet di codice, dimensioni, spaziatura, dimensioni dei caratteri, risorse SVG e così via.
3. Trascurare il contesto in cui l’utente utilizzerebbe il mio prodotto
Esistono vari fattori che influenzano il comportamento di un utente quando interagisce con un’interfaccia.
Considera dove si trova l’utente quando utilizza la nostra app, quanto tempo ha a disposizione e qual è il suo stato emotivo.
Puoi vedere esempi buoni e cattivi di questo ovunque.
Se la nostra app è pensata per essere utilizzata durante il jogging ad esempio, è necessario tenere conto di alcuni vincoli e considerazioni nella progettazione.
Il modo migliore per garantire che la nostra interfaccia e la nostra UX si adattino al contesto dell’utente è testarlo in situazioni in cui può essere utilizzato e testarlo con gli utenti.
Shopify ha scritto un ottimo articolo su questo tema e consiglio a chiunque sia interessato ad approfondire questo argomento.
4. Progettare direttamente in alta fedeltà
Andare direttamente a lavorare sul visual prima di convalidare le nostre idee o comprendere appieno il problema che stiamo risolvendo è un errore facile da fare.
Questo non è necessariamente un approccio sbagliato, ma spesso si tradurrà in una perdita di tempo se i progetti non funzionano.
Il wireframe è un modo veloce e per raccogliere e testare idee. In questo modo è possibile valutare facilmente la propria idea del layout e della gerarchia del nostro design.
È anche più difficile innamorarsi di un design quando è solo un wireframe, quindi possiamo accettare critiche e feedback molto più facilmente.
5. Trascurare le disabilità
Progettare un prodotto è come costruire un edificio pubblico: deve essere inclusivo e accessibile a tutti.
Ciò include utenti non vedenti, daltonici e ipovedenti.
Spesso cerchiamo di progettare ciò che a noi sembra buono, dimenticandoci di considerare i diversi utenti che interagiranno con il nostro prodotto.
Man mano che sono cresciuto come designer, ho fatto i conti con tutti i vari vincoli che minano la mia idea di un design perfetto.
Restringere il testo fino a 8 px perché si adatta meglio al nostro spazio orizzontale o utilizzare una leggera tonalità di grigio perché sembra carino significa trascurare gli utenti con problemi di vista.
Per dare sfogo alla nostra creatività senza tenere in considerazione questi aspetti possiamo ussare Dribbble, ma non è bene farlo quando si sviluppa un prodotto per veri utenti.
Le linee guida per l’accessibilità dei contenuti Web (WCAG) richiedono un contrasto di almeno 4,5: 1.
Esistono anche linee guida per le disabilità motorie, uditive e cognitive.
Per assicurarsi di soddisfare questi standard, Stark è molto utile per controllare se i propri progetti sono accessibili o meno.
6. Copiare il lavoro di altri o seguire ciecamente le tendenze del design
“Trends are like junk food for designers. Following them produces cheap solutions that offer some initial payback but little value over the long haul. Trend-following designers date themselves quickly. The reward for following someone else’s design path? A gnawing sense of professional emptiness.”
Lo so, è capitato anche a me, ed è normale accada: è facile rimanere intrappolati nel magico mondo di Dribbble e in tutte le belle animazioni e sfumature, quindi dimenticare rapidamente gli obiettivi del nostro design.
Spesso mi è capitato di appassionarmi ad una particolare interazione o stile di design che ho trovato su Dribbble e ho cercato di farli funzionare nel mio design. Trovare ispirazione su Dribbble o altrove è bello e divertente, ma essere ispirato e copiare ciecamente un componente dell’interfaccia utente perché ha un aspetto nuovo non è la stessa cosa.
7. Reinventare la ruota
Una cosa che dico spesso ai miei studenti è «Non siate creativi».
È ovviamente una provocazione che utilizzo per far capire loro un concetto semplice, ma fondamentale: gli utenti si aspettano esperienze simili sul web.
Se il nostro sito, app o software funziona in modo diverso da quello a cui gli utenti si sono abituati, non sarà intuitivo e probabilmente saranno frustrati dall’esperienza.
Un esempio di ciò sono le icone, le quali hanno un significato ormai prestabilito.
Ad esempio “cerca” o “preferiti” sono rappresentate in modo simile nella stragrande maggioranza delle interfacce.
Utilizzando icone differenti per rappresentare queste azioni, corriamo il rischio di danneggiare l’esperienza utente e causare mal di testa agli utenti che cercano di utilizzare il nostro prodotto.
8. Concentrarsi su come appare e non su come funziona
Una cosa che ogni UI designer odia fare è “rompere” i propri componenti.
Rompere un componente significa essenzialmente inserire dei contnuti che rovinerebbero il layout o l’aspetto estetico dell’interfaccia.
Questo può essere scomodo da fare come designer, ma è una componente cruciale per progettare un prodotto flessibile, scalabile e di facile utilizzo.
Faccio un esempio: quando la card nel mockup che ho inviato alla produzione ha un titolo di tre parole sembrerà fantastica, ma cosa succede quando il titolo sarà più lungo e magari andrà su 2 o 3 righe?
Testa i progetti e fai un passo indietro durante la progettazione per assicurarti che l’interfaccia possa adattarsi a un’ampia varietà di casi d’uso, non solo quelli ideali.
9. Non progettare i differenti stati
Quando si progetta per lo sviluppo, gli stati mancanti creeranno una lacuna nell’esperienza o dovranno essere colmati dallo sviluppatore.
Questo può spesso creare incongruenze nel design.
Dobbiamo tenere conto di tutti i diversi stati possibili come errore, conferma, attivo, disabilitato, hover, vuoto, pieno, negativo, per citarne alcuni.
Se stessi progettando una wishlist ad esempio, avrai bisogno di considerare lo stato di quella pagina prima che un utente aggiungesse qualcosa alla lista dei desideri: lo stato vuoto. Senza questo stato, ci sarà una lacuna nell’esperienza.
10. Riprogettazione dei componenti nativi
Sfruttando i componenti già integrati nei sistemi oprativi, possiamo fornire agli utenti un’esperienza familiare ed evitare errori di input.
Indipendentemente da quanto siamo bravi come designer, può essere difficile giustificare la progettazione di un nuovo “date picker” da zero.
Anche se il nostro è oggettivamente migliore, l’utente deve comunque imparare ad utilizzare un nuovo componente quando ce n’è uno perfettamente integrato nel proprio dispositivo.
Questo eichiede inoltre ulteriore sviluppo e impegno di progettazione per creare un componente da zero.
I componenti nativi sono un gioco da ragazzi: usali per risparmiare tempo, fatica e ridurre l’attrito per gli utenti.
