Tanti modi di fare modal
Progettare e utilizzare finestre modali efficaci non è difficile, basta conoscerne scopo e peculiarità
- Hai presente la pagina del nuovo sprinter LS-19/80? Hanno già chiesto una modifica.
- Di già? Ahahahah! Cosa si sono dimenticati?
- Un pezzo fon-da-men-ta-le. Nella mail l’hanno proprio scritto così.
-Vabbè, cosa si sono scordati questa volta?
-Un testo. È una richiesta del legale che chiede di aggiungere una frase nel caso l’utente abbia già aderito in passato a un servizio simile.
-Ma l’hanno vista almeno tre volte. Abbiamo pure l’ok scritto.
-Che ti devo dire… è fon-da-men-ta-le… ahahahah.
-Vabbè. Aggiungiamo un modulo tipo questo?
-No. È troppo. E “loro” non vogliono che si veda troppo… vogliono una pop-up!
-COSA?!?! …a parte che popàp lo diceva mia nonna… ma poi come dovrebbe aprirsi?
-Con una CTA “scopri di più”? Un bel bottone!
- COSA?!?! …e comunque sarebbe sempre piuttosto evidente…
-EH NO!… dicono che non deve essere troppo visibile, così se un utente non lo legge… è meglio.
-COSA ? ! ? !
L’esempio che avete appena letto fa sorridere e credo sia bagaglio comune di tutti noi designer, project manager, product owner ecc.
Ma è un esempio non del tutto onesto. Infatti ho voluto raccontare l’episodio classico che rappresenta “il male” sotto forma di dipartimento Legale. Purtroppo nella triste realtà quotidiana anche alcuni project manager e (ahimè) taluni designer utilizzano le modali in modo estremamente incosciente.
Croce e delizia per i progettisti, le finestre modali sono spesso usate in modo indiscriminato e come panacea per errori di progettazione.
Vengono erroneamente utilizzate per inserire contenuti, anche complessi, che erano sfuggiti durante la stesura o che sono stati aggiunti dopo l’online.
In realtà, la modale, non è così difficile da “maneggiare”. Basta ricordare (o sapere) perché esiste: qual è il suo scopo nel variegato pentolone degli oggetti digitali?
#1 La finestra modale è una rottura di palle
Wikipedia, che non è la bibbia ma che spesso ci azzecca, dice questo:
Nella progettazione delle interfacce utente, una finestra modale è una finestra “figlia” che richiede all’utente di interagire con essa prima di ritornare ad operare con la finestra “madre”, impedendo la prosecuzione del flusso di lavoro sulla finestra principale dell’applicazione in esecuzione.
Questa definizione ci dice già tantissime cose.
Innanzitutto è una finestra, non una pagina. Quindi non è adatta a gestire contenuti troppo lunghi o complessi come ad esempio video o tool (ma del resto a chi verrebbe mai in mente…).
Secondariamente è una “figlia”, quindi è subordinata. Non contiene cose fon-da-men-ta-li!
Terza cosa, con una modale bisogna interagire. Questo significa che un utente non deve solo leggere, ma deve anche in qualche modo rispondere: quindi si crea un dialogo. Questo significa che un semplice link, ad esempio, non è sufficiente perché non rappresenta un’opzione. Del resto, le modali, le chiamano anche finestre di dialogo.
Ma l’ultima frase è la mia preferita: “…impedendo la prosecuzione del flusso…” Sentite come suona rassicurante?
La modale per l’utente è una rottura di palle, una cosa fastidiosa che lo interrompe.
Questo dovrebbe assicurarci l’uso centellinato e parsimonioso di questo oggetto. La modale non veicola contenuti, nel suo piccolo veicola problemi.
E noi dovremmo crearne il meno possibile, giusto?
#2 Le modali non si buttano a caso
L’abbiamo appena detto, le finestre modali assolvono a pochi e ben determinati scopi. In ogni caso bloccano l’azione dell’utente interrompendone il flusso di navigazione. Per questo motivo va ricordato che le modali sono parte integrante del flusso e come tali richiedono di essere inserite nella progettazione tanto quanto le pagine che le generano.
Uno degli errori più diffusi è quello di usare le modali in modo indiscriminato, ogni volta che si vuole aggiungere qualcosa di imprevisto. Ovvero ogni volta che abbiamo progettato male o ci siamo lasciati indietro dei pezzi.
Ma la modale non è la soluzione.
La soluzione è il buon design. Dobbiamo progettare i flussi in modo completo, simulando attraverso le journey la più ampia serie possibile di pattern.
In questo modo useremo le modali solo al momento giusto e, anche questo è fondamentale, eviteremo di dimenticarcene qualcuna per strada.
È una buona regola disegnare sempre i flussi di interazione end to end, specificando sempre i punti che richiedono l’ingresso di una modale.
#3 Una modale non fa primavera (neanche in Apple)
Non so se ve ne siete accorti ma stiamo parlando molto di flussi di interazione. Leggiamolo da un altro punto di vista: non stiamo parlando di contenuti.
Le modali sono oggetti tecnici, hanno uno scopo pratico. Non servono per veicolare contenuti, per quello ci sono le pagine. Lo so, a volte sembra una sottigliezza ma in realtà la differenza è tanto chiara quanto abissale: le modali dialogano, le pagine informano.
Nelle prime ci viene richiesta obbligatoriamente una scelta, nelle altre non ce n’è bisogno.
Possiamo quindi dire con serenità che le modali dovrebbero esistere solo all’interno di flussi di interazione (funnel, carrelli, form ecc.) e mai in pagine editoriali.
Diciamo che potrebbe essere una regola di massima.
Ovviamente ci sono casi in cui potremmo lasciar correre, soprattutto se chi usa le modali si chiama Apple…
Ma di base è sbagliato comunque. Nella gif qui sotto vedete una modale usata per mostrare un contenuto. Ma perché usare una modale? Non si poteva forse mettere tutto in pagina? L’utente fa un click in più per aprire (e uno in più per chiudere) un contenuto che poteva serenamente già stare lì, visibile e fruibile da subito.
Certo ci sono anche casi in cui ci è utile usare quella che definiamo tecnicamente una modale ma che ci serve anche per scopi informativi. Ma vanno considerate come eccezioni e contestualizzate in modo specifico.
Nel Car Configurator di FCA (in questo caso Fiat, ma l’engine è lo stesso per tutti i brand) sono state usate delle finestre modali sia per veicolare contenuti aggiuntivi che per gestire procedure del flusso di configurazione.
Nel caso della CTA “Dettagli” si apre una modale con immagine e testo, mentre con la CTA “Aggiungi” si apre una modale che ci avvisa che per poter proseguire sarà necessaria una modifica alla configurazione. Si noti che comunque, nel rispetto delle regole base, nella modale informativa è ripetuta la CTA “Aggiungi” che permette di proseguire direttamente dalla finestra, e proseguire verso gli step successivi.
#4 Le modali ci parlano
Ma quindi?
Quando possiamo usare queste benedette modali?
Beh, vi faccio rispondere da qualcuno che ne sa parecchio più di me…
“Quando qualcosa ha bisogno di essere sistemato, è meglio assicurarsi che l’utente lo sappia”
— Jakob Nielsen sulle finestre modali
Ok, fissiamo allora un paio di punti:
- Le modali non servono per veicolare contenuti;
- Le modali non vanno (o non andrebbero) utilizzate all’interno di pagine editoriali;
- Le modali vanno utilizzate all’interno di flussi di interazione;
- Le modali rappresentano un dialogo tra utente e flusso di interazione.
E ora aggiungiamo un ultimo punto: le modali servono a risolvere eventuali criticità o problematiche.
Quando progettiamo un flusso di interazione creiamo una sequenza di step che partono da un’esigenza e arrivano a un obiettivo. Durante il passaggio da uno step a quello successivo succede spesso che ci sia la necessità di avvisare l’utente di qualcosa.
Nielsen parla di “sistemare qualcosa”, a me piace concentrarmi sul concetto di feedback.
Quando un utente inizia un flusso compie un piccolo atto di fiducia verso noi designer (e verso gli sviluppatori) dando per scontato che riuscirà a finire quello che ha appena iniziato.
Sì, lo so, i flussi che progettate raggiungono tutti l’ultimo step, senza intoppi. Ne sono sicuro. Quello di cui certamente non possiamo essere sicuri è che lo raggiunga l’utente, perciò lo dobbiamo accompagnare passo passo durante tutto il flusso rassicurandolo e fornendo sempre feedback su come stiamo procedendo.
Senza esagerare ed essere assillanti, all’interno di un flusso abbiamo molti punti dove fornire feedback, dalla navigazione orizzontale ai messaggi inline…
…ma sicuramente le modali sono un’ottimo oggetto per dialogare con l’utente e tenerlo informato.
Quindi dopo aver cercato di dare uno scopo alle finestre modali e aver definito alcune loro caratteristiche e funzionalità, proviamo a definire anche alcune caratteristiche di UX e UI che possano renderle ancora più efficaci.
Cito qualche esempio:
- Una scelta fatta in un certo step modifica tutte (o alcune) delle scelte operate negli step precedenti.
- La selezione di un parametro richiede un costo aggiuntivo non previsto o non specificato in precedenza.
- La selezione di un parametro prevede l’accettazione di una o più clausole.
- La possibilità di modificare in parte una scelta.
- Una scelta multipla.
- La richiesta di una conferma specifica.
Perfetto!
Siamo siamo forse riusciti a dare uno scopo alle finestre modali e a evidenziare alcune loro caratteristiche e funzionalità peculiari. Proviamo adesso a definire anche alcune caratteristiche di UX e UI che possano renderle ancora più efficaci.
#5 Diamo sempre più di una scelta
La gestione delle azioni che si compiono in una modale è un argomento serio che va studiato e verificato ogni volta. Abbiamo detto che il sistema e l’utente dialogano grazie alle modali. Se pensiamo ad un dialogo dobbiamo pensare ad uno scambio di informazioni aperto, dove a ogni domanda possa corrispondere anche più di una scelta.
Se una modale non presenta scelte è inutile per il 95% dei casi.
Per spiegare meglio cosa intendo vi racconto un aneddoto simpatico capitatomi in pizzeria durante una cena natalizia tra colleghi.
A fine cena abbiamo ordinato un numero generico di amari, e da buoni italiani… chi voleva un amaro e chi un altro, chi voleva il ghiaccio e chi non lo voleva, ecc. La cameriera era andata nel pallone e, una volta ritornata aveva un vassoio strapieno di amari tutti diversi. Ma ne mancava uno, solo uno… un Montenegro.
L’aveva ordinato una mia collega ed era stata l’unica. Ma l’amaro era finito.
La cameriera, nel tentativo di fornire un servizio impeccabile, disse alla mia collega: “Manca solo il suo amaro, purtroppo lo abbiamo terminato.” E non aggiunse altro. Si girò e se ne andò.
La mia collega rimase lì con un’espressione come se avessero premuto il tasto pausa. Poi mi guardò interrogativa e scoppiammo a ridere.
L’errore è banale. Tutti ci aspettavamo un’alternativa che però non è arrivata. Fortunatamente a fine cena, in un periodo di feste e con un tavolo pieno di amari abbiamo trovato una soluzione comunque.
Ma cos’è successo?
Possiamo vederla così: abbiamo iniziato un flusso (ordinando gli amari) e a un certo punto si è verificato un problema (è finito il Montenegro).
Ok (pensa la cameriera), niente panico avvisiamo il cliente (cioè apriamo una modale).
A questo punto il flusso dovrebbe proseguire senza intoppi fino alla fine, ma la modale era sbagliata. Non c’è stata alternativa, né tantomeno dialogo, ma solo una frase monodirezionale che non portava a nessuna soluzione o addirittura ad uno stallo del flusso (cioè la mia collega a bocca asciutta!).
La modale è stata:
Frase: Purtroppo è finito il Montenegro.
CTA: Ok, ho capito.Ma avrebbe dovuto essere:
Frase: Purtroppo è finito il Montenegro.Vuoi altro?
CTA 1: Scelgo un altro amaro.
CTA 2: Ok, non voglio altro. (magari un ghost button)
Questo esempio è anche interessante per un altro motivo. È un classico caso in cui la modale è bloccante al 100% e quindi non deve avere la X di chiusura. In questo caso l’utente deve prendere una decisione: proseguire senza amaro o sceglierne un altro.
Cliccare sulla X non lo porterebbe da nessuna parte, se non a ripetere all’infinito il loop amaro finito>alert in modale>chiudo con la X.
#6 Usiamo la formattazione
Ok, con la UX in senso stretto abbiamo finito. Passiamo alla UI e a un paio di suggerimenti per migliorare ulteriormente l’efficacia delle modali.
Giuro che non c’è scritto da nessuna parte che il testo di una modale deve essere piatto, noioso e di difficile lettura.
Le modali non sono le finestre di sistema di Windows XP (poi sono passato a Apple e non so cosa succeda oggi sui PC…) e possiamo continuare a progettarle immaginando un dialogo. Possiamo quindi usare tutta la formattazione che vogliamo: titoli, bold, italic, colori ecc. ecc.
Il caso di Dribbble (qui sopra) è un esempio perfetto di uso di finestra modale con molta formattazione e grande efficacia.
Ha una grafica accattivante, un testo molto chiaro e ben formattato, interrompe un flusso in un momento fondamentale (devo accedere per votare) e ha diverse scelte possibili, ben visibili e comprensibili.
Quindi possiamo lavorare di creatività anche sulle modali. Possiamo creare momenti di dialogo accattivanti e che non risultino noiosi ma addirittura accattivanti.
Certo, la modale è un oggetto di servizio che compare in caso di criticità, ma può in ogni caso essere progettata per essere percepita come utile e interessante. Non diamoci limiti dove non ce ne sono.
#7 Usiamo la lightbox
Ultima rapidissima caratteristica che una modale deve avere: la visibilità.
Una modale deve interrompere il flusso, stabilire un dialogo e veicolare delle scelte. Ok, direi proprio che deve essere visibile.
Quindi usiamo la lightbox!
È una convenzione ormai. Non dovrei nemmeno dedicare due righe a questo argomento, eppure ci sono ancora siti che non la utilizzano.
Ad esempio, durante il flusso di acquisto di un biglietto sul sito trenitalia.comci sono momenti in cui appaiono tooltip e modali, ma senza lightbox.
L’usabilità non è immediata e l’esperienza utente rimane leggermente frustrante.
Le prime volte quasi non si vedono, poi ovviamente ci si fa l’abitudine e si gestisce il tutto comunque.
Nell’esempio di Trenitalia ci sono alcune idee interessanti come il tooltip che si apre sul checkbox se solo si passa sulla CTA prima di aver apposto il flag.
È una soluzione molto intelligente, ma è vanificata dalla scarsa visibilità.
Lo stesso lo si può dire per la modale successiva che si apre al top della pagina (mentre l’attenzione dell’utente è sul bottone rosso in basso) ed è una finestra bianca che appare su un sito bianco. Capite anche voi che l’efficacia è compromessa.
Bene. Facciamo un veloce riassunto di quello che abbiamo detto finora con qualche esempio pratico.
Ecco alcune finestre modali che forniscono feedback durante un ipotetico flusso di interazione.
Conclusione
Le modali sono oggetti super-utili se progettate con cura e seguendo alcune semplici regole. In caso contrario possono velocemente trasformarsi in veri e propri UX-boomerang e causare grande frustrazione nell’utente, fino addirittura ad essere nocive per la corretta finalizzazione del flusso stesso.
In ogni caso io cerco sempre di non dimenticare che il segreto di una buona progettazione è sempre legato alla “regola aurea del buonsenso”.
Le modali non fanno eccezione.
