Eppur si muove — UI animate e UX
Dare vita alla UI è dare quel di più che farà differenziare i vostri prodotti dagli altri. Ma, di preciso, come si fa? E come affronto il developer handoff?
Tante cose confluiscono nella progettazione e realizzazione di una UX coerente.
Tra i vari elementi, c’è il movimento. Transizioni, animazioni e microinterazioni sono tanto importanti quanto una chiara UI con annesso user flow.
Ed è subito panico.
Mi ricordo ancora quando passavo le ore a percorrere chilometri digitali mentre scrollavo pagine e pagine di Dribbble, ipnotizzato da quelle schermate con transizioni un sacco sensuali.
Gradienti che sfumavano. Pulsanti che si trasformavano in schermate. Icone animate. Transizioni fluide come poche.
«Le farò anche io!» mi dicevo.
Correvo al computer, prendevo delle schermate che avevo già preparato e…
Il nulla. Quello cosmico, proprio.
Ed eccolo, il panico.
«Come cavolo faccio?» mi dicevo, intasando i server di Google con le mie query di ricerca.
Un’anno dopo, credo di averne capito un pochino.
Interaction design != Motion design
È fondamentale capire il prima possibile questa differenza (carina la terminologia dev usata, vero?)
Animare più interfacce o gli elementi di una è diverso dal fare un’animazione.
Ok, sa molto di controsenso. Devo animare comunque, che differenze ci potranno essere?
Due importanti.
- Implementazione: un’interfaccia va sviluppata in codice — bisogna pensare che tutto quello che fate va poi passato al dev, quindi keep it real. E non tutto può essere fatto, certe animazioni sono proibitive. Se il vostro bottone pulsa o cambia colore, il dev è super happy. Se invece con una torsione 3D di 35,7° si trasforma in due cubi con texture diverse che poi svaniscono in una nuvola di fumo, bè — la quantistica computazionale è ancora molto lontana. E ho visto dev piangere. Sul serio.
- Significato: non potete aggiungere animazioni solo perchè sono belle così. Capisco l’hype ma siete pur sempre designer e dovete progettare un prodotto, non fare l’internship da Marina Abrahamovic. Semiotica — ogni elemento è portatore di significato. Un triangolo invece che un cerchio, in alto a destra invece che centrale a sinistra — animato o no. Se avete deciso di fare quella animazione è perchè pensate che possa esprimere meglio un concetto o un processo.
Il motion design invece non prevede nessuno di questi due step: le vostre animazioni verranno esportate in un comodo .mp4 o .svg come minimo e saranno piene di animazioni che potranno anche essere complesse e contorte. Nessuna implementazione, nessuna semiotica.
Saranno infatti questi i due mantra che dovranno guidarvi:
Si può implementare? Aggiunge qualcosa?
La risposta dovrà essere SÌ per entrambe le domande. È 1 o 0 — altrimenti, non state facendo interaction design ma motion design.
implementazione x semiotica == interaction design
Famolo
Chiarito il concetto di animazione, credo arrivi forse la seconda parte più importante.
Come faccio davvero il tutto?
E qui, grazie al 2017, il designer può essere sommerso davvero da una valanga di software — c’è il rischio di perdersi.
Qui, vi parlerò del mio workflow che sono riuscito a testare in diversi progetti. È solo uno spunto di una modalità di lavoro ma ognuno poi può adottare la sua unica modalità, in base a bisogni e contesti.
Brief
Qui si chiacchiera con gli sviluppatori. Avviene ancora a inizio progetto, quando ancora dovete fare tutto.
E la domanda essenziale è:
Come implementerete il progetto?
Fascile fascile.
Da questa domanda potrete sapere i linguaggi di programmazione, l’approccio di sviluppo usato, la strutturazione del loro lavoro. È essenziale a tutto il progetto.
Fate tutte le domande possibili e che vi servono, senza timore.
Chi domanda comanda.
Preparare le interfacce
Le interfacce le faccio in Sketch. Period. Per ora lo trovo uno strumento completo rispetto ad altri, forte dei numerosi plugins e delle varie implementazioni con altri servizi.
In questa fase è bene preoccuparsi di nominare tutti i livelli, le artboard e gli oggetti con cura e attenzione, usando gli stessi nomi per gli elementi con le medesime funzionalità, perchè servirà molto al momento dell’handoff ai dev.
L’animazione
I tool abbondano e non scherzo, ma quelli che uso cerco di tenerli circoscritti a una schiera non troppo ampia con vari livelli di complessità:
- transizioni semplici per prototipo;
- transizioni complesse;
- micro-interazioni.
Transizioni semplici
Per questo genere di transizioni, quindi un semplice spostarsi da una schermata all’altra, con al massimo dei minimi effetti visivi, loro due sono i vostri migliori amici: InVision e Flinto.
Supportano entrambi l’importazione di file .sketch con tutti gli artboards e gli oggetti modificabili e manipolabili e hanno una funzionalità di linking schermate molto buona.
InVision permette di disegnare delle aree trigger (quelle in blu) alle quali si può linkare un’altra schermata (quella di arrivo), selezionare il trigger e la modalità di transizione (sliding, popping up, fading, ecc). Flinto è simile.
Transizioni complesse
Innanzitutto, cosa si intende:
Sono tutte quelle animazioni costum, non preimpostate dal sistema, che prevedono che tu metta mano agli elementi dell’interfaccia.
Flinto permette di farlo: ha un Transition Manager molto completo che permette di lavorare sui singoli elementi della UI, regolarne la velocità e sceglierne il tipo di andamento della curva di transizione — basta cliccare il pulsante «Crea Nuova Transizione»
Rotazione (su assi X, Y, Z), opacità, dimensioni, posizione — potete manipolare singole variabili in una schermata intuitiva e dalla curva di apprendimento motlo rapida dato che ricorda molto quella di Sketch.
Le animazioni che avete creato ex novo potete riutilizzarle e pure invertirle.
Micro-interazioni
Non sono transizioni tra schermate ma sono comportamenti dei singoli elementi grafici: se un pulsante, quando ci passi sopra col mouse, ha una reazione, si parla di micro-interazione.
Quando lasci una review con uno slider a stelle le stelle rimbalzano? Micro-interazione.
singolo elemento di UI + risposta a interazione con utente = micro-interazione
Flinto è magia perchè ha pure un Behaviour Designer interno, che permette di associare a un trigger di vario genere una risposta. La costruzione di tale risposta fa usa di una sequenza di fotogrammi.
Il primo è lo Stato Iniziale, al quale seguono N Stati dove specifichiamo le tappe del comportamento.
Possiamo manipolare molte variabili o, addirittura, i vettori se previsti (quindi modificare curve e punti di bezier), creando delle micro-interazioni molto avanzate.
Un’altro modo per creare micro-interazioni ancora più avanzate e particolari (ma occhio all’implementazione!) è fare uso di Adobe AfterEffect.
È uno dei classici monster softwares che sforna mamma Adobe e che si occupa di effetti speciali in post-produzione ma che dei designer hanno trovato un sacco interessante da usare per manipolare le shapes e le icone delle loro UI.
Come interfaccia è meno intuitiva e richiede un po’ di tempo per il suo apprendimento — si possono manipolare diverse variabili, come in Flinto, ma qui si lavora su una timeline e usando i keyframes.
La timeline si occuperà di dirvi la successione spaziale degli eventi, mentre i keyframe diranno al programma lo stato A di inizio dell’animazione e lo stato B di conclusione, lasciandolo occuparsi di modificare la variabile negli spazi intermedi.
Potete regolare le curve di velocità dell’animazione ma dovrete anche occuparvi di simulare tutti i trigger, non avrete la possibilità di testare il prototipo (cosa che Flinto e InVision permettono di fare con dei servizi di mirroring) e come problema maggiore avrete la compatibilità.
AE funziona con file AI e PS.
LOL sorry not sorry.
E il 2001 è finito da un po’ e nessuno sano di mente ritiene saggio affrontare la progettazione di interfacce in Illustrator o Photoshop. Esiste un comodissimo script (Sketch2AE) che permette di importare in AE degli artboard selezionati ma ha ancora alcuni bug.
Un altro strumento ottimo, ma che ho utilizzato ancora poco, si chiama ProtoPie — gestisce i trigger, permette di combinare animazioni e transizioni sia di default che custom e ha un’app di mirroring.
Developer handoff
Una volta che avete fatto i Walt Disney e avete creato tutte le transizioni, bisogna consegnare il materiale ai dev.
Cosa gli diamo?
Potete consegnare GIF e video dei vostri lavori (tutti i programmi citati permettono l’esportazione di tali formati) ma, di solito, la reazione che ricevete è questa 👇🏻
Perchè non ci sono numeri e parametri precisi. È come se un ingegnere dicesse di costruire una casa dopo averne fatto un dipinto a olio sotto diverse prospettive.
Bello, ma lo psicanalista lo paghi tu.
Il modo migliore è creare uno Sheet di Google suddiviso così:
In A1 si trova il nome dell’elemento:
- btn se intendo che questa animazione vale per tutti gli elementi che si chiamano btn;
- btn/login se intendo solo gli elementi btn nella schermata di login;
- btn-login/login se intendo l’elemento btn singolo che serve a fare il login (e che ha il testo «login» su di esso) nella schermata login.
Da B in poi si trovano le variabili manipolate, con lo stato inziale in 2 e lo stato finale in 3.
La riga 4 presenta il tipo di curva di andamento dell’animazione (che tutti i software presentati permettono di visualizzare e copiare) mentre la 5 presenta la tipologia di trigger.
Il foglio lo compilo così con tutti gli elementi che ho animato e lo consegno ai dev assieme al documento con le schermate e il design system — è il passo più compilativo e noioso dell’intero processo ma fà un sacco bene al clima del team e al work flow del progetto.
Giuro.
È stata lunga ma ce l’abbiamo fatta.
La UX è buona se curata nei minimi dettagli e non concentrarsi anche su animazioni, interazioni e transizioni significa ignorare l’efficacia e importanza semiotica del movimento.
In caso il mio workflow non sia stato di vostro gusto,
qui sotto vi elenco altri software con cui potete animare, prototipare e conquistare il mondo.
Go on!
