Cosa significa progettare una dashboard? 
Una riflessione sulla progettazione dell’esperienza utente di un cruscotto digitale.

La parola “dashboard”, in italiano traducibile in “cruscotto”, è una postazione che raccoglie una serie di dati, grafici e liste, capaci di fornire a colpo d’occhio informazioni chiare su andamenti o prestazioni.

Il cruscotto è già di per sé una buona metafora che descrive adeguatamente il modello che caratterizza la maggior parte delle dashboard digitali di oggi. Un cruscotto di un’automobile, tra le varie funzioni, ha quella di ospitare il quadro strumenti del veicolo, ma anche pulsantiere, autoradio, navigatore, uno o più vani portaoggetti, posacenere, porta per la ricarica del telefono, airbag e così via. Insomma, si tratta di un oggetto capace di veicolare non solo le informazioni sull’andamento e sullo stato del veicolo ma anche di rispondere alle esigenze più pratiche che possono emergere durante la guida di un veicolo.

Le dashboard digitali, così come i cruscotti, rispondono principalmente a certe funzioni: fornire in tempo reale l’andamento di dati di performance, lo stato di oggetti e di processi, nonché mettere a disposizione dell’utente delle funzionalità di carattere più “pratico” ed in parte operativo sui dati. Monitoraggio e azione sui dati, ecco due obiettivi principali di una dashboard.

In molti articoli vengono proposte una serie di linee guida per la progettazione di interfacce software funzionali, che offrono indicazioni su come raccontare il dato in maniera più chiara e comprensibile, su come rendere accessibili le dashboard da dispositivi diversi e responsive, su come creare strutture flessibili in grado di adattarsi ai diversi domini di utilizzo.
Per i più interessati a questi aspetti, al termine del post ci sono una serie di spunti vari relativi delle linee guida di dashboard.

Negli corso degli ultimi progetti di dashboard sviluppati con il mio team di lavoro, abbiamo cercato di approfondire i bisogni, le motivazioni, le frustrazioni, i vincoli e i “desiderata” degli utilizzatori di dashboard. Per quanto una dashboard possa avere una struttura “standard” e adattabile a vari domini, gli utenti finali rimangono sempre diversi tra loro. Hanno obiettivi differenti e richiedono funzionalità particolari, anche nello stesso settore e progetto. Lo scenario tipico è che la medesima dashboard è fruita da utilizzatori di ruolo diverso ai quali l’accesso alle informazioni e funzionalità è vincolato e strutturato in maniera differenziata, della serie “non tutti possono vedere tutto”. Ragion per cui risulta necessario avere un quadro preciso di tutti gli utilizzatori finali, analizzare i casi d’uso, definire i requisiti, nonché “proiettare” nuovi scenari di utilizzo e interazione.

D’altro canto è fondamentale avere anche una visione precisa del contesto di utilizzo della dashboard dati. Pensiamo ad esempio all’operatore che utilizza il tablet durante un intervento sul campo, in un cantiere magari. Cosa ha bisogno di vedere e cosa deve monitorare in quel preciso momento e luogo? Può un sistema prevedere un certo andamento a seguito di una specifica azione compiuta dall’operatore? Quali indicazioni è in grado di fornirgli?
Un altro esempio potrebbe essere invece il manager che gestisce e monitora dashboard diverse tra loro. Come potrebbero essere integrate in un unico sistema? Come sono gestite dall’utente? Quali sono gli altri attori che influiscono? Come posso condividere un certo dato?

In sintesi, la riflessione sulla progettazione delle dashboard si dirige verso un’attenta analisi sulle necessità degli utenti e sugli aspetti di interazione, ma anche sul reale contesto di fruizione. Il valore e il significato del dato viene trasmesso anche dalla rappresentazione dello stesso: l’applicazione di buone pratiche visuali proprie dell’infografica interattiva agevolano enormemente la comprensione del dato e aiutano a raccontare i fatti che accadono.