Cosa fare (e non fare) se sei un UX/UI Designer

In almeno uno di questi errori siamo caduti tutti, chi per fretta, chi per ignoranza e chi per “estro creativo”. L’importante è conoscere e comprendere i propri errori per non commetterli in futuro migliorando così come professionisti e aiutando i colleghi nel proprio lavoro (i programmatori ringrazieranno).

Uniformità di comportamento

Uno dei suggerimenti principali che posso dare è di mantenere la stessa logica di comportamento in ogni parte del sito web, app e interfaccia che andrete a progettare.
Se, in una schermata, andrete ad inserire l’icona con i classici 3 puntini, con la funzione di aprire le opzioni, non potete usarla nello stesso progetto per fare una cosa diversa. Manderete in confusione i vostri utenti.
Se usate un semplice bottone per aprire la schermata successiva non potete subito dopo usare uno slide to confirm; magari perchè l’avete visto recentemente da qualche parte e vi piace molto l’effetto e volete subito integrarlo in un progetto già iniziato. Ci vuole uniformità non solo grafica ma anche funzionale.

Ogni scelta è importante

Bisogna essere consapevoli di ogni scelta grafica/funzionale e di cosa questo comporti.
Aggiungere un effetto visivo fuori standard su un bottone comporta magari, per il designer, poco tempo; ma bisogna essere consapevoli che c’è chi dovrà programmare e realizzare materialmente quello che è stato progettato.
Valutate bene la vostra scelta ponendovi alcune domande:

• L’effetto era previsto nelle specifiche?
• L’effetto aggiunge valore?
• L’effetto non appesantirà il progetto rendendolo poco compatibile con i vari dispositivi?

Negli effetti visivi il troppo stroppia

Il principio migliore da utilizzare per quanto riguarda gli effetti visivi è “Less is More“.
È sempre meglio progettare un design semplice e pulito con un solo effetto uniforme è ben fatto piuttosto di aggiungere 10 effetti pensati male.
Il rischio è di creare un progetto “anni novanta/duemila” simile a quello del famoso sito web cameronsworld o di rendere non fruibile il contenuto creando difficoltà di lettura, stancamento della vista e nei casi peggiori effetto nausea.

Progettare quello che è stato chiesto nelle specifiche

Le specifiche tecniche sono la base da cui ogni UX/UI designer inizia a sviluppare graficamente e funzionalmente il progetto.
Su queste specifiche sono stati calcolati tempi e costi ed è importante seguirle e capirle nella loro interezza. Finire prima del previsto un progetto e aggiungere per il proprio piacere ed ego dei componenti non previsti non aggiunge valore ma complicazioni ed ovviamente costi.

Non considerare la variabilità dei contenuti

È molto bello progettare un design pulito ed elegante con testi semplici, titoli brevi ed efficaci, sfondi fotografici con il testo sempre ben leggibile in sovraimpressione. Ma se c’è una cosa importantissima che va’ sempre considerata è la variabilità dei contenuti.
Lo spazio per un nome profilo “Mario Rossi” deve anche considerare la presenza possibile di un nome come “Massimiliano Giuseppe Santa Maria”.
La progettazione di un app o un sito web in lingua inglese deve anche prevedere la possibilità futura di traduzione della stessa app in altre lingue molto più complesse come ad esempio il tedesco (caratterizzato da parole composte molto lunghe).
Una fotografia variabile messa in uno sfondo potrebbe rendere non visibile gli elementi in overlay.
Se state progettando un app che ha una schermata di dettaglio con all’interno un immagine, un titolo e una descrizione dovete essere sicuri che questi elementi siano sempre presenti o in assenza di questa certezza calcolare il vuoto causato dalla possibile assenza di uno o più elementi o di inserire un placeholder e che questo non comporti un difetto di lettura o fruibilità.
Dovete trovare una soluzione visiva e funzionale alle possibili mancanze.

Modificare il progetto dopo che è passato alla fase di sviluppo

Una volta che il progetto è in mano al programmatore è troppo tardi per le modifiche. Se vi siete resi conto di aver commesso errori sarà compito dello sviluppatore risolvere, a maggior ragione se la motivazione è un cambio di idea creativo. Non fate nulla a meno di una richiesta esplicita. Il vostro file Figma/XD non deve subire modifiche non discusse dopo il passaggio alla fase di sviluppo. Essenzialmente: dovevate pensarci prima. Le fasi di lavoro non possono essere sovrapposte, come ho già scritto in un altro articolo di questo blog sui Project Manager.

Il rischio più banale di questo errore è di essere ignorati e quindi aver perso inutilmente tempo, il rischio peggiore è di risultare incompetenti agli occhi dei colleghi e collaboratori.