Essere un UI/UX designer migliore
Diciamo le cose per come stanno: attualmente una buona percentuale del lavoro di UI/UX viene lasciato allo sviluppatore, che è in genere sprovvisto delle competenze necessarie per svolgerlo al meglio, non rientrando questo nel compito della programmazione.
Non c’è da meravigliarsi di ciò. Il designer non conosce i meccanismi che stanno dietro alle interazioni con la sua interfaccia, dato che non si occupa di scrivere codice. Inoltre molte altre necessità grafiche sorgono in una seconda fase, durante lo sviluppo, e la tentazione per lo sviluppatore di fare da sé e andare avanti senza attendere il responso del designer, è fortissima.
Quello che spesso non viene considerato dal designer sono i cambiamenti di stato, ad esempio. O i tempi di attesa. O i limiti e le peculiarità del sistema. O i feedback sonori (anche se questi ultimi non so se spettino proprio al designer, di sicuro la cosa peggiore da fare è lasciarli al developer, nella maggior parte dei casi).
Ultimamente ci è venuto in aiuto Google con il Material Design, creando un set di interfacce base esteticamente gradevoli, in modo che anche un messaggio di errore creato dallo sviluppatore in maniera improvvisata non sia così male.
Inoltre, il Material Design, ha colmato il vuoto lasciato quasi sempre nello definire gli stati dei pulsanti, che portava, a seconda dello sviluppatore, alla totale assenza di feedback nei pulsanti, o alla loro presenza spesso brutta.
Nonostante su questi aspetti il Material Design ci venga in aiuto, sarebbe estremamente limitante pensare che sia l’unico modo per riuscire a far collaborare bene designer e developer.
Analizzerò alcuni aspetti cercando di dare delle soluzioni pratiche.
Una delle cose più tralasciate è la varietà di dimensioni degli schermi. Ad esempio, cosa succede ad una grafica di questo tipo quando lo schermo è più grande o più piccolo?
L’intenzione è di mantenere la foto sempre quadrata, mostrare sopra le tre opzioni (Art, pets e food) ma farne vedere di più se lo schermo lo permette, fare estendere orizzontalmente la casella di testo occupando tutto lo spazio possibile ad esclusione dei margini destro e sinistro, ridurre o aumentare la dimensione del testo “Strumenti” e la lunghezza delle righe alla sua destra e alla sua sinistra e mostrare i tasti al suo interno anche con forme diverse, se necessario, tipo con icona sopra e testo sotto, affiancandole orizzontalmente.
Ma possiamo dare tutto questo per scontato?
Lo sviluppatore che ha ricevuto un file grafico statico di questo tipo si trova nella situazione di dover prendere tutte quelle scelte menzionate sopra da solo (oppure rompere di continuo la testa al designer per ogni singolo dubbio).
Le stesse problematiche vengono fuori sia in schermate complesse come quella sopra, che in schermate più semplici che all’apparenza sembrano autoesplicative.
Una classica splash screen stessa può avere diversi modi di essere interpretata. Dal modo più “ingegneristico” del prendere le distanze a quello più intuitivo del pensare che il logo debba trovarsi sempre al centro. In casi come questi è ormai risaputo che la seconda via sia quella giusta. Ma possiamo essere veramente certi che sia scontato per tutti?
Prendendo questa stessa immagine potremmo prendere diverse decisioni quando gli schermi cambiano notevolmente di grandezza. Oltre a mantenersi al centro, l’immagine potrebbe ingrandirsi e ridursi per occupare al meglio lo spazio. Oppure il testo potrebbe essere mostrato a fianco dell’icona nel caso di layout in landscape o schermi molto grandi. Oppure il testo potrebbe non essere mostrato in caso di schermi molto piccoli.
Sono in ogni caso scelte che non spettano al developer, ma che si trova continuamente a dover fare.
Per queste e altre problematiche, viene in aiuto Subform, uno strumento pensato proprio per questo. Dal video di presentazione si possono vedere i vari aspetti trattati:
Un altro punto quasi mai preso in considerazione sono i tempi di attesa medio/lunghi. Ogni tasto collegato ad una richiesta ad un server (come un caricamento o la ricezione di informazioni e/o contenuti multimediali) o ad una operazione complessa (come l’elaborazione di immagini) dovrebbe contemplare un feedback visivo e, dato che si tratta di un’attesa che impedisce all’utente di effettuare altre interazioni, dovrebbe essere studiata per intrattenere quanto più è possibile.
Le operazioni lunghe, ad oggi, sono ormai tutte asincrone, che significa in sostanza che l’interfaccia non ha più un blocco finché il processo non è stato completato, ma continua a darti la possibilità di interagire. Se da un lato è un bene, perché vedere lo schermo bloccarsi non è molto bello, dall’altro richiede più sforzi critici per confezionare il tutto al meglio.
L’utente può tornare indietro dopo aver premuto il pulsante? Se sì, significa che la schermata di conferma, al termine dell’operazione, potrebbe apparire in una schermata diversa da quella nel quale e stata generata e, quindi, fuori contesto. Oppure, nel caso l’utente possa ritornare in quella schermata e ripetere l’azione, le informazioni della richiesta precedente potrebbero essere sostituite da quelle della richiesta successiva se non ci si presta la dovuta attenzione.
Nel caso del caricamento di una lista, ad esempio, possiamo far cambiare tranquillamente schermata all’utente ed evitare di comunicargli il successo dell’operazione: tornerà da sé a controllarne l’esito quando e se lo vorrà.
Nel caso della pubblicazione di un post, però, l’utente ha bisogno di sapere che tutto è andato a buon fine e può anche voler guardare il suo post. In casi come questo, un messaggio di conferma è più che giusto e gradito.
Per venire incontro a questo tipo di problematiche si potrebbe adattare quella che in programmazione si chiama verifica a due step: a grafica ultimata, il developer indica al designer quali azioni possono richiedere tempi di attesa lunghi. Dopodiché, il designer elabora il comportamento da adottare nelle varie situazioni e riconsegna la grafica aggiornata.
In generale, chiedetevi sempre: “Come la impiego questa attesa?”.
Può sembrare cosa da poco, ma renderà gli utenti più felici (nell’utilizzare il prodotto, perlomeno).
Abbiamo poi diversi elementi che i vari sistemi mettono a disposizione e che vengono sfruttati pochissimo.
Nelle app per smartphone ci sono ad esempio le notifiche, che oltre a fungere da tipiche informazioni su azioni eseguite da altri che ti riguardano (ha commentato, ha pubblicato, ti ha invitato, ecc.) possono anche essere interattive mostrando pulsanti rapidi di risposta e più informative, mostrando anteprime di immagini o percentuali di processi. Ricollegandoci al caso analizzato prima, una notifica può mostrare lo stato di avanzamento nella pubblicazione di un post, esattamente come fa Facebook. Però, come sempre, non sta al developer decidere di farlo, essendo una scelta di design.
Ci sono inoltre i widget. Ci sono le azioni rapide implementate da Apple col force touch e su Android dalla versione 7.0 con appositi launcher.
Ci sono gli Android Wear e gli Apple Watch, a cui non pensa mai nessuno (anche se qui i tempi richiesti per tenerli in considerazione sono maggiori, e il pubblico raggiunto è limitato, volevo comunque menzionarli).
Nel web i maggiori browser offrono la possibilità di ricevere notifiche dai siti e dalle web app, anche se la funzione è relativamente recente.
Altra cosa da considerare sono invece i limiti. Per esempio su Android cambiare il font dell’app non può che avere risultati estetici disastrosi, se si utilizzano gli elementi standard.
Per riuscire a sfruttare al meglio questi fattori l’unico modo è tenersi costantemente aggiornati e discuterne. Eccezione fatta per le notifiche, che sono troppo importanti per non meritare uno studio apposito approfondito da parte di entrambi.
Un piccolo appunto va anche sulle risorse.
Cercate di mantenere una palette con tutti quanti i colori usati e condividetela con gli sviluppatori. Fate attenzione anche alle varie gradazioni di grigio utilizzate per i testi, i divisori e i background. Includete nella palette anche i valori alpha della trasparenza, utilizzando il formato ARGB (con tutti e quattro i valori che vanno da 0 a 255). Così facendo, anche lo sviluppatore potrà crearsi una tabella di riferimento che aiuterà a rendere il codice più mantenibile e pulito, e renderà estremamente più semplice modificare un colore qualora se ne verifichi l’esigenza.
Per quanto riguarda le immagini (icone ed elementi), il discorso è troppo complesso per essere trattato qui, e in continuo aggiornamento. Ci sono però molti articoli che ne parlano, oltre alle guide ufficiali delle varie piattaforme.
Vorrei però menzionare le immagini nine-patch, utilissime per realizzare elementi di interfaccia complessi. Sono supportate da Android, iOS e web. Questo slideshow ne fa una breve panoramica, mentre la mia intenzione è di trattarle in un articolo apposito, da linkare poi qui.
Concludo qui, vista la lunghezza raggiunta e avendo comunque trattato gli aspetti principali.
Mi piacerebbe sapere il punto di vista sia degli sviluppatori che dei designer sugli argomenti esposti. Pensate che qualcosa fra quelle menzionate vada lasciata al developer? Vi vengono in mente altri aspetti importanti dei quali non ho parlato?
Commentate dicendo la vostra ^^
