Design di dashboard SaaS: mostrare i dati senza sommergere l'utente

Una dashboard SaaS e la schermata iniziale di un prodotto: una vista sola che dice all'utente cosa sta succedendo e cosa richiede una decisione adesso. Stephen Few, autore del libro di riferimento sul formato, la definisce come le informazioni piu importanti per raggiungere un obiettivo, disposte su un unico schermo e leggibili con un colpo d'occhio. Le dashboard fatte bene ci riescono in cinque secondi. Quelle fatte male mostrano tutto cio che il database puo produrre e lasciano all'utente il compito di raccapezzarsi.

La seconda versione e la piu diffusa. Un team lancia un prodotto, i dati crescono e ogni stakeholder chiede solo un altro grafico. Dopo sei mesi la dashboard ha trenta widget, quattro filtri e uno scroll che non finisce mai. Gli utenti smettono di leggerla: aprono l'unico report di cui si fidano e ignorano il resto. Questo articolo parla delle decisioni di design che tengono una dashboard leggibile mentre i dati dietro aumentano.

Perche una dashboard affollata ti fa perdere utenti

Il sovraccarico di informazioni e il problema piu segnalato nelle dashboard, e ha una causa meccanica. La memoria di lavoro umana tiene pochi elementi alla volta. Nel 1956 George Miller fisso il numero a sette, piu o meno due; e un'osservazione sulla memoria, non una regola rigida di interfaccia, ma la direzione e quella giusta: oltre una certa soglia le persone smettono di confrontare gli elementi e iniziano a scorrerli senza vederli.

Una dashboard che mostra quaranta numeri non informa quaranta volte meglio di una che ne mostra sei. Informa peggio. L'occhio non ha un punto d'appoggio, la metrica importante pesa quanto quella inutile e l'utente spende attenzione per decidere dove guardare invece di decidere cosa fare. Il costo non e estetico. E un tempo piu lungo prima della prima azione, piu ticket di supporto che chiedono dove vedo X e una funzione che nessuno apre.

Perche aggiungere un filtro non risolve

Quando una dashboard sembra affollata, il riflesso e aggiungere controlli: un selettore di date, un menu per i segmenti, un interruttore per ogni team. I filtri aiutano l'utente esperto che sa gia cosa cerca. Non fanno niente per chi apre la schermata a freddo e deve capire in un colpo d'occhio se oggi e tutto a posto o e in fiamme. Hai spostato il lavoro sull'utente invece di farlo nel design. Piu controlli significano anche piu stato da tenere a mente, l'opposto di cio che serve a una schermata gia sovraccarica.

La stessa trappola vale per l'aggiungere una seconda dashboard, poi una terza. Ora l'utente deve ricordare quale schermata risponde a quale domanda. Il problema non e mai stato lo spazio. Era la gerarchia.

Cosa funziona davvero

Parti dalla sintesi, mostra il dettaglio su richiesta

La divulgazione progressiva (progressive disclosure) e il pattern piu forte in questo caso. Mostra prima i pochi numeri che contano e lascia che l'utente clicchi, espanda o approfondisca per il resto. Jakob Nielsen, che ha dato il nome al pattern, lo descrive come rimandare a una seconda schermata le opzioni avanzate o poco usate, cosi le principali ricevono tutta l'attenzione. Su una dashboard questo diventa una riga in alto con tre-cinque metriche chiave, ognuna delle quali apre una vista di dettaglio quando ci clicchi. Il fondatore ha lo stato in pochi secondi. L'analista ha comunque ogni livello, a un tocco di distanza.

Una dashboard, un compito

Decidi per chi e la schermata prima di disegnarla. Una dashboard pensata per un fondatore che segue la crescita e una pensata per un responsabile del supporto che smaltisce una coda non possono essere la stessa schermata con widget diversi appiccicati sopra. Le viste per ruolo riducono il numero di widget, perche quasi tutte le metriche sono irrilevanti per quasi tutti i ruoli. Se non sai dire qual e la singola domanda a cui una dashboard risponde, il bug e quello, e nessun layout lo sistema.

Rispetta il numero, ma raggruppa invece di tagliare

Punta a circa cinque-nove elementi in una singola vista. Trattalo come un campanello d'allarme, non come una legge: le opzioni a schermo non vanno memorizzate perche restano visibili, quindi l'obiettivo vero e raggruppare. Raccogli le metriche affini in sezioni con un'etichetta, cosi l'occhio legge tre gruppi da quattro invece di dodici tessere sparse. Un gruppo ben etichettato di numeri collegati si legge come un'unita sola: e cosi che metti piu dati su uno schermo senza aggiungere carico.

Costruisci una gerarchia visiva vera

Metti la metrica piu importante dove l'occhio arriva per primo, in alto a sinistra nei layout da sinistra a destra, e dalle piu dimensione e contrasto. Tutto cio che e secondario scende di peso. Usa il colore con misura: una palette dove ogni tessera e di un colore acceso diverso non ha gerarchia, perche quando tutto grida niente spicca. Tieni il colore saturo per l'unico stato che richiede un'azione, un superamento o un allarme, e lascia calmo il resto. E la stessa disciplina della calm UI: silenziosa di default, rumorosa solo dove se lo merita.

Fai in modo che ogni numero significhi qualcosa

Un numero da solo non e un'informazione. 1.240 iscrizioni non dice niente finche non sai se e in salita o in discesa, e rispetto a cosa. Accompagna ogni metrica chiave con un contesto: un confronto con il periodo precedente, una linea di obiettivo o una freccia di tendenza. Una metrica con una soglia, come 83% della quota con verde sopra l'80%, permette di giudicarla senza fare calcoli. Questa singola abitudine toglie piu confusione di qualsiasi scelta sul tipo di grafico.

Progetta gli stati vuoti e di caricamento

Le dashboard si vedono anche prima di avere dati: un account nuovo, una query lenta, un filtro che non restituisce niente. Se questi stati sono un ripensamento, la prima impressione del prodotto e una schermata che sembra rotta. Uno scheletro durante il caricamento, un chiaro ancora nessun dato con una riga su come ottenerne quando e vuoto, e un fallback veloce quando una query rallenta tengono l'utente orientato mentre i numeri arrivano.

Togli le metriche su cui nessuno agisce

Per ogni metrica sulla dashboard, fai una domanda: se questo numero cambiasse, qualcuno farebbe qualcosa di diverso. Se la risposta e no, e una vanity metric, e il suo posto e in un report che si tira fuori su richiesta, non sulla schermata che si guarda ogni giorno. Il totale delle iscrizioni di sempre fa piacere e non cambia nessuna decisione. Le iscrizioni di questa settimana rispetto alla scorsa cambiano se preoccuparsi o no. Tagliare il primo tipo e il modo piu rapido per liberare spazio e mettere a fuoco la schermata, ed e di solito il piu difficile, perche ognuna l'ha chiesta qualcuno.

Come appare nella pratica

Prendi uno strumento di supporto la cui vecchia dashboard aveva diciotto widget su un unico scroll. L'abbiamo ricostruita attorno a una domanda che il responsabile del supporto si fa davvero ogni mattina: la coda e sotto controllo. La nuova riga in alto mostra quattro numeri: ticket aperti, ticket che sforano lo SLA, tempo mediano di prima risposta e risolti di oggi. Gli sforamenti di SLA sono l'unico elemento rosso della schermata. Sotto la piega, tre sezioni etichettate contengono il dettaglio: carico per agente, ripartizione per tag e andamento degli ultimi quattordici giorni. Tutto cio che prima era un widget di primo livello ora e a un clic dentro una sezione. La schermata si legge in un colpo d'occhio e il dettaglio resta li per l'analista che lo vuole. I dati non si sono ridotti. E la gerarchia ad aver fatto il lavoro.

Niente di tutto questo e prima di tutto un problema di grafica. E un problema di editing. Una buona dashboard e soprattutto un insieme di decisioni su cosa non mostrare nella prima schermata. Movimento, colore e layout rafforzano quelle decisioni, ma vengono dopo.